Many people focus (often wrongly) on the new risks of cloud computing, but I am far more interested in leveraging cloud computing to improve security.
I am deep into creating the advanced material for our Cloud Security Fundamentals class at Black Hat and want to toss out one of the tidbits we will cover. This is a bit more than a sneak peek, so if you plan to attend the class, don’t read this or you might get bored.
A couple parts of this process are useful for more than security, so I will break it up into a few shorter pieces, each as self-contained as possible. The process is very easy once you piece it together but I had a very hard time finding necessary instructions, and there are a few tricks that really racked my analyst brain. But this isn’t about SEO – I want to make it easier for future IT pros to find what they are looking for.
In this example we will automate hooking into cloud servers (‘instances’) and securely deploying a configuration management tool, including automated distribution of security credentials. Specifically, we will use Amazon EC2, S3, IAM, and OpsCode Chef; and configure them to handle completely unattended installation and configuration. This is designed to cover both manually launching instances and autoscaling.
With very minor modification you can use this process for Amazon VPC. With more work you could also use it for different public and private cloud providers, but in those cases the weakest link will typically be IAM. There are a few ways you can bridge that gap if necessary – I don’t know them all, but I do know they exist.
First, let’s define what I mean by cloud security policy compliance. That is a broad term, and in this case I am specifically referring to automating the process of hooking servers into a configuration management infrastructure and enforcing policies. By using a programmatic configuration management system like Chef we can enforce baseline security policies across the infrastructure and validate that they are in use.
For example, you can enforce that all servers are properly hardened at the operating system level, with the latest patches, and that all applications are configured according to corporate standards.
The overall process is:
- Bootstrap all new instances into the configuration management infrastructure.
- Push policies to the servers, including initial and update policies.
- Validate that policies deployed.
- Continuously scan the environment for rogue systems.
- Isolate, integrate, or remove the rogue systems.
The example we will cover in the next few posts only covers the first couple steps in detail. I have the rest mapped out but may not get it all ready in time for Black Hat – first I need to dust off some programming skills, and I learned a long time ago never to promise a release date.
All of this is insanely cool, and only the very basics of Software Defined Security.
Here is specifically what we will cover:
cloud-initto bootstrap new Amazon EC2 instances.
- Use Amazon IAM roles to provide Temporary rotating security credentials to the instance to access the initial configuration file and digital certificate for Chef.
- Automatic installation of Chef, using the provided credentials.
- Instances will use the configuration file and digital certificate to connect to a Chef server running in EC2.
- The Chef server is locked down to only accept connections from specified Security Groups.
- S3 is configured to only allow read access of the credentials from instances with the assigned IAM role.
- The tools in use and how to configure them manually.
I will start with how IAM roles work and how to configure them, next how to lock down access using IAM and Security Groups, then how to build the
cloud-init script with details on the command-line tools it installs and configures, and finally how it connects securely back up S3 for credentials.
Okay, let’s roll up our sleeves and get started…