AWS Bootcamp and Summit
So the first thing to know is that I do not currently work in any way shape or form with AWS. I haven’t used the platform for anything remotely useful for probably around 2 years now.
In that case you may be wondering what i was thinking when I put myself forward to attend a Bootcamp and then spend the day at the AWS Summit in London. The answer is simple — Personal Development.
It is rare that I get time to send some time playing and poking about with things that are not in some way directly related to what I do day to day. As I’m away from home most of the week any spare time I do have when I’m there is spent trying to sort out things around my house or the other demands on my time such as family and friends etc.
Kainos are also great at allowing you to set your own development direction and will facilitate that as best they can and I have a goal to up skill in AWS/Azure which this fed in to.
So on to the actual topic then. The Bootcamp and Summit were spread over 2 days. The Bootcamp came first.
Bootcamp — Securing Cloud Workloads with DevOps Automation
Thankfully no angry Drill Sergeant shouting at us here but a great opportunity to see how to leverage a few of the services available from AWS to take code from a check in to Master potentially right the way through to production without actually having to grant any developer access to the CD/CI pipeline infrastructure or services.
The training was delivered by Qwiklabs and inspite of a few issues with some of the environments at different points in the labs everything went pretty smoothly.
The labs for this used Jenkins as the CI server to drive various AWS services in order to test the application logic and configuration against preconfigured security tests to ensure that it would be deployed as expected, to the infrastructure expected and utilise the expected configuration.
Jenkins was used to perform initial tests against changes that we made to the files in the git repo, packages these up and ship them to an S3 bucket where we had also configured CodeDeploy to pull the packages from. The purpose of many of the labs was to show how responsibility can be segregated in to different teams and how the permissions can be blended to ensure that no one team or individual has more access than is required for the role assigned to them.
We also saw how to configure AutoScaling Groups with Simple Workflow to build out logic that would ensure than changes that were not ready did not make it to production. This ensured that no EC2 instance could be added to our Autoscaling Group if it did not pass the tests or criteria that we had set to ensure that it had been adequately secured. Again the benefit here was that these decisions and workflows are Automated — no human interaction was required at any stage here.
The next section was around programatic access control, leveraging IAM policies and the Secure Token service to restrict the level of access that applications would have to the AWS resources. This access could be time bound and allocated on demand, further limiting the security footprint of the environment.
Finally we had a run through of interacting with AWS Key Management Service (KMS). Here we learned how to secure our application secrets and where the keys are held. First we simply interacted directly with the KMS to encrypt and decrypt simple text, to get a better understanding of how it works and what restrictions etc that model would bring. One thing to note here) is that you can change the encryption context on an individual record basis. This is good as it adds an additional layer of obfuscation to the decryption process — however you will need to consider how you store this as well as the decryption key.
The next step here was to store encrypted data along with the key in DynamoDB. The key was also encrypted using the Customer Master Key which is stored in KMS. The benefit of this is that there is now need to store any plaintext representation of your data or key anywhere in the environment. The unencrypted key is no longer in memory either as this is removed as part of the process.
The bootcamp itself was much similar to training described by Daryl Porter in his previous blog — a copy/paste/follow along with limited scope for playing around with the various components too much. It did encourage you to think about how you could possibly extend and improve upon the labs in the real world but nothing outside of that. The major benefit that I felt it gave me was that it was a starting point. AWS has over 100 available services, which can all interact and be used in conjunction with each other to build, manage and maintain unbelievable systems. Getting started with this can seem daunting and it can be hard to know where to start. The bootcamp very easily took us through how the tools mentioned above can be linked together to enhance the security of your platform and also ensuring the robustness of your pipelines.
So while it was not very in-depth, understandable given it was a single day, it did help to point me in the right direction as to the tools I should be looking to leverage, and how.
Of course it was completely based on the AWS Service offerings but there are some ideas that I feel could be applied to many projects that we currently have in flight, or brought in to new projects that we are about to begin, even if they are not on AWS.
I have some of the code that we used available if anyone would like it, however the labs and slides for the training are not available for me to share unfortunately.
AWS Summit
It was my first time attending the AWS Summit and i have to say i was impressed. It wasn’t as big as some conferences that I had attended and some of the sessions I had wanted to attend clashed so some decisions had to be made on the fly. I did manage to slack-cast most of it to a dedicated channel despite some technical difficulties.
The format of the day was AWS and its customers — every talk was a mixture of an AWS employee and then a related customer story. Again this was great as it helped to get some real world examples of how the multitude of services on offer from AWS are being leveraged by companies with all sorts of backgrounds from startups to large organisations and the challenges they have experienced along the way..
As I have discovered at these conferences everyone is banging the DevOps drum, or at least some variant of it — be it DevOps, SecDevOps, TestDevSecOps etc etc. Some of the stories and revelations did seem to me to be a bit old hat for 2016 but then that may be my opinion. Everyone already knows the benefits that this kind of thinking can bring to your organisation and so it isn’t really necessary to explain it over an over again. It is good to see that we are doing things right, or at least are trying to!
Another theme here was transition from large monolithic service architecture to a more agile micro services architecture and how the AWS platform helped customers such as The Trainline achieve this as well as the benefits that it brings. I think that this particular theme was brought up in every talk that I went to and it is interesting to me as it can be used to chart the move from provisioning servers, through to containers and ultimately using services such as Lambda to run workloads.
Security was also a major topic here, with many examples of how the various tools can be used to harden workloads and environments beyond what is achievable on your own infrastructure. With lots of it baked in to AWS itself and requiring little management overhead. Unfortunately I didn’t get to the security talks given the aforementioned clashes however some colleagues did and I’m looking forward to their thoughts on it.
As I mentioned right at the start the main benefit that I got from attending the Summit was getting visibility of the multitude of services that are available on AWS and seeing real world examples where they have been used and tied together.
Resources:
https://github.com/awslabs/lambda-refarch-webapp — Serverless Reference Architecture
https://aws.amazon.com/architecture/ — AWS Architectural Guidance