David Clinton
Outline
Securing Amazon EC2 Instances
All the tutorials in this course:
- Introduction to EC2 Security
- The Basics
- Controlling External (Application) Access
- Controlling Internal (Administration) Connectivity
In this tutorial we're going to explore the security groups you attach directly to instances to act like firewalls, the VPC architecture whose design emulates the way you might configure routing on a physical network, and the IAM rules that can also be associated with instances - only they'll act in a way that's closer to a file system permission set than a firewall.
All of those tools let you filter and control access to your resources, and there's no doubt there's some redundancy and even the potential for conflict in the system. But between them, you'll certainly have everything you could need to effectively secure the instances running on your AWS account.
Let me illustrate how all that works. Here's your EC2 instance. It's going to have a security group that, by default, blocks all incoming requests. You could, for instance, open up the TCP port 22 for SSH connections, and perhaps port 443 for HTTPS web traffic. No matter what else you might open up at the subnet or IAM layers, those are the only two classes of request that will ever get through to your instance.
But you could also design a VPC - or, Virtual Private Cloud - with, say, one private and one public subnet. You might place backend database instances in the private subnet. Since that subnet doesn't have an internet gateway, nothing from the public internet will make it through. That makes sense because there's no reason to permit remote client sessions on your database: it's only meant to serve data to your frontend web servers. Your web server, on the other hand, would live in the public subnet. That subnet will have an internet gateway, but it might also have network ACL attached with it's own extra restrictions.
As we'll soon see, we can also connect multiple security groups to each other. That would allow instances in subnets or VPCs that have no direct access, to nevertheless talk to each other. A bit later, we'll get a quick look at VPC design topologies - using tools like Bastion Hosts or NAT gateways - that can also permit very specific, controlled connections across otherwise restricted space.
The third security element we're going to learn about is the IAM role. In the context of our sample deployment here, imagine that an application running on our instance needs access to data that's sitting happily in an S3 bucket. Even if it's only data reads you're after, you'll still need a way to get in.
Well, there are three approaches to solving this problem, and two of them are awful. The first approach is to make the contents of your S3 bucket public. I hope you can see how, for most use-cases, that's not a great idea at all. The second approach is to give your instance access the same way you get it when you're working on your laptop. In other words, you could copy your AWS credentials to the instance. The problem here is that that'll probably involve hard-coding security credentials into generated-infrastructure code. You laptop is one thing, because configuring the AWS CLI is a one-time manual process. But instances are often launched from templates, and you never want credentials incorporated into templates.
Which brings us to IAM roles. When we eventually get to that point, you'll watch me create an IAM policy that permits access to an S3 bucket. When I add that policy to an IAM role, and then incorporate that role into an instance profile, any application running on an instance launched with the profile will have automatic access to the bucket - without the need to compromise on security best practices. But that's getting way ahead of ourselves. Let's begin with security groups.