What’s a Stage Check?

A stage check is something I’m borrowing from the world of aviation. Yes, as a new pilot I can’t shut up about flying — it’s worse than CrossFit or being a vegan (but not worse than being a vegan CrossFitter).

We use stage checks to make sure a student is ready to move on to the next phase of lessons. In my case my instructor would usually have another instructor test my knowledge and flying skills. It’s a great safety-minded approach to make sure nothing critical slips through the cracks, which is very easy when you are working one-on-one with someone.

In our case I will insert this around every 8-10 labs as an excuse to take a step back, review what we’ve done and why, and give you a chance to double check everything before moving forward.

I’ll also use these to cover concepts and information that don’t fit in a lab, but are important for what we are doing next. This week that will be a brief discussion of accounts and regions.

Labs You Should Have Completed

• https://slaw.securosis.com/p/creating-aws-lab-account

• https://slaw.securosis.com/p/create-secure-first-admin-user

• https://slaw.securosis.com/p/turn-cloudtrail

• https://slaw.securosis.com/p/timmys-first-cloudformation

• https://slaw.securosis.com/p/follow-money

• https://slaw.securosis.com/p/create-first-aws-iam-role

• https://slaw.securosis.com/p/write-simple-iam-policy

Video Review

What We Did and Why

Zooming out is a chance to take a step back and review not only what we’ve done, but why. The goal is to put the individual labs together to build a bigger picture, and show how they work together as parts of a whole.

Here is everything we did and why:

• We started with our longest lab, where we created our AWS account and secured our root account with MFA. As a reminder, the root account is the email you use to sign up with AWS, and it has full and complete control over your AWS account. If anyone gains access to your root account they effectively own your AWS account.

• To reduce the day-to-day risk of having to use a root account, we created an administrative IAM user and added MFA to this user account. We talked about the difference between an entity and an identity. An entity is “the thing”, and an identity is how it is represented in a given namespace. For your root account the namespace is all of AWS. For the admin IAM user the namespace is your AWS account (identified by the 12-digit account ID, which we’ll talk more about later). At the end of this lab we had an admin user we can use without exposing our root account. I always create an admin IAM user if I’m using a single account or if the AWS account will be a management account for an AWS Organization, even though we generally try to minimize IAM users. That way I can always get back in to fix things without using the root account, in case something else breaks.

• Then we turned on CloudTrail, which provides management plane logs. This logs all API activity in our AWS account, critical for both security and operations. We set up CloudTrail to record from all regions in our account, and to save the files into an S3 bucket. CloudTrail always keeps 90 days of data, but saving the logs to S3 means we have durable logs as far back as we want to store them.

  • At this point we have our secure account, our first admin user, and logs. Not a bad start for less than an hour of work.

• In our next lab we shifted gears a bit and learned how to use CloudFormation, Amazon’s built-in Infrastructure as Code (IaC) tool. You ran a template in your account, which created a Simple Notification Service topic called “SecurityAlerts”. Thus we killed two birds with one stone: we learned how to use IaC and set up a place to send security alerts.

• Which means, of course, it was time to create that first security alert. Since I’m trying to do all this for as little money as possible, we created a billing alert to warn us if our bill reached $25. This can help avoid mistakes, and detect common attacks like cryptocurrency mining. I really like to set this early in all my accounts — I’ve learned the hard way that it’s very easy to turn things on in cloud without realizing their financial impact. At the end of the lab we subscribed our email to the SecurityAlerts SNS topic.

• After that I wanted to round out our discussion of IAM fundamentals. We discussed the concept of a persona: a way to take on a different role for a session. Then we used one in action by creating an AWS IAM role for the EC2 service. This showed us how roles in AWS are containers for permissions, with two types of policies. A permission policy defines what a role can do, and a trust policy defines who or what can use a role. We created a role which EC2 instances can use, and gave it permission to talk to the SSM service, which we will use later to manage instances. Even AWS tools and services need roles to talk to other AWS tools and services.

• We finished this training block by writing our first IAM policy and learning about entitlements. A policy is a set of permissions, and when we attach that policy to a user or role, that creates an entitlement. We learned about the basic identity-based policy types (inline and managed) and wrote a simple customer-managed policy to allow read and write access to our CloudTrail S3 bucket. When we use this in later labs we will remove the “write” (PutObject) permission to learn how to remove excessive permissions — we generally don’t want anyone other than AWS writing into our log directory.

Everything we did was to set up basic account security and cover concepts we’ll need as we move beyond a single AWS account, to create an Organization with a bunch of accounts. If I was only going to work within this one account I would add some additional things, like GuardDuty. But these labs are designed to teach you how to operate at scale, so it’s better to set those up after we have an Organization, since we configure them differently when working with a collection of accounts.

At this point you have a secure account with administrative access, logging, and billing alerts. We also learned about the three key primitives for AWS IAM: users, roles, and policies.

Lesson: AWS Regions

I keep telling you to use the us-west-2 Oregon region, but we haven’t spent much time on the concept yet.

Regions are separate geographic areas, each hosting multiple data centers. Each region is isolated and independent, ensuring fault tolerance and stability. Choosing the right region is important for latency, data residency, and compliance.

There are three primary reasons we use regions:

• Resilience: If one region has a service interruption it should not affect other regions. The exception is us-east-1, because that’s where global services run (see the end of this post).

• Security: Regions are isolated, so a security issue in one region should be isolated from other regions. This limits the “blast radius”. Note that IAM is global, and the source of most breaches, so regions doesn’t help much with those attacks.

• Compliance: Regions are geographically isolated and built around the world so you can meet data residency requirements. If you collect data from customers in Europe and use a Europe region, the data stays in Europe, which makes compliance with local laws easier.

When AWS says “isolated and independent” they mean it. There are 17 default regions (always on when you create an account) and 12 more you can enable. Regions contain the datacenters where everything in AWS runs. Resources you create in one region cannot interact with other regions unless you change configuration settings to tie them together.

For example you may remember that when we created our billing alert there was a screen where we could click on a dropdown and just pick our SNS topic.

If we created our billing alert in us-east-1 instead, that dropdown wouldn’t show anything because our SNS topic lives in us-west-2. We also talked about this in our CloudTrail lab: we weren’t creating just one trail, but a trail in every region of the account, which just happened to send its logs to a single S3 bucket.

It’s really no different than having a bunch of datacenters you control yourself. Stuff in the datacenter is all connected, but you have to pay more money and link things up to work across datacenters.

As we move deeper into these labs, it will be very important to understand which region you are working in, and when and how to connect things between regions. When we start using the CLI and APIs you’ll see that we need to set things up to connect to the API endpoint for both the region and service we want.

One caveat is that AWS has some services labeled “Global”, which means they work in every region. IAM is the most obvious example — AWS would lose pretty much every customer if we had to recreate our IAM in every region.

The secret is that nearly every global service runs in us-east-1 (Virginia). This doesn’t affect us day-to-day, but on very rare occasions AWS has a service issue with us-east-1 with cascading effects across regions.

Alrighty people, you should be all set with your account and ready to build an Organization. CAN YOU FEEL THE POWER!?!

Sorry. I watch too many superhero movies. Have a great week, and see you soon.

-Rich