Security

Okay, part 3! At this point, I’m assuming that you have already familiarised yourself with part 1 and part 2 of the series. As a quick recap, part 1 focused on why we would consider using GPG Keys in general. Part 2 focused on how to generate GPG keys along with some recommended practices on splitting out our master (Certification) key, from our specific purpose-driven keys. This post (part 3) focuses on using those keys as part of our usual development workflow using Git. We’ll be assuming that GitHub is our end target, as GitHub supports commit signature verification using GPG Keys.

Have a need to update a legacy application to use cloud concepts such as retry, circuit breaker or other features? Then the ambassador or sidecar patterns may be for you! Join Peter and Chris as they continue their journey exploring Cloud Design Patterns. In this session, they discuss the Sidecar and Ambassador Patterns.

Hopefully by now you’ve had a chance to read part 1 of this series, which explains why you may be interested in using GPG keys to sign your commits. Congratulations on getting to the second part! In part two, we’re going to focus on how I worked through setting up GPG in my Windows environment, and generating a set of keys for use. There were some challenges/hurdles along the way, and we’ll talk through those too!

For a while now, I’ve been using GPG Keys to sign my Git Commits to prove that my commits on GitHub are genuine and from me. Over the last few weeks, I’ve been inspired by a couple of colleagues (Kudos to Adrian and Julie if you’re reading this) to dig out my YubiKey and use these for my key signing activities. While there are several blog posts on the topic already, I encountered a number of roadblocks along the way. The intent of this blog post is to be the first of a series, where we’ll explore what GPG is, why it may be valuable to you and how you can get going using them. We’ll then take this forwards an additional step, and show how you can use YubiKeys as a second factor of verification and the benefits of this approach. By no means am I the world’s expert in cryptography, and some of these topics, but I wanted to document my own understanding for posterity, as I’ll inevitably need to repeat/review the process in the future. I hope that this may be useful to you.

You may have joined Peter and Chris in some of their previous episodes such as the API Economy, The Backends for Frontends & Strangler Pattern, or The Anti-Corruption Layer, Gateway Aggregation and Gateway Routing patterns. They’ll will be continuing our journey talking about API Cloud Design Patterns, as they talk about the Gatekeeper and Valet Key Patterns in this episode of Cloud with Chris. This is another episode in the series of Architecting for the Cloud, one pattern at a time.

When building solutions in the cloud, security is often a pillar that we hear come up in the requirements discussion. But how does that translate into the real world? Particularly defending against DDOS attacks? Check out this episode, where Cam Adams joins Chris and talks about some of the recent work that he has been doing, helping customers defend against this.

In this episode, we get back to a requirements based topic, and an area that will significantly impact the design of our resulting solution architecture. That topic is security! It’s one of the hot topics that organisations want to discuss when moving to the cloud. So I’m pleased to be joined in this episode by another colleague, Andrew Nathan, who has a wealth of knowledge in the cyber security space.