If you have been following along from the beginning, we have completed all of the examples in this book while signed in as a user with administrator privileges. While this is a convenient way to learn a new technology, you should never run a production system with administrator privileges. If part of the system were compromised, you want to ensure you limit access as much as possible.
This chapter is all about Identity and Access Management (IAM). IAM is how you manage users, groups, and permissions. In this chapter, I show you how to create users and groups. I also explain how IAM policies work and how to create them. IAM policies describe which resources a user can access and the operations they can perform on those resources. You will see that IAM gives you unprecedented control over access.
Finally, in the two exercises at the end of the chapter, we will create a framework for least privileged access and grant access to billing and support. Let’s get started.
Managing Users
Let’s begin by adding a few users to our AWS account. We added a single user back in Chapter 2 using the AWS Management Console. Now let’s add a few using PowerShell.
Note that Get-IAMUser only works for users. Toward the end of this chapter, we will talk about IAM roles. If you are writing code to get the current user, I suggest using Get-STSCallerIdentity. Get-STSCallerIdentity will work for both users and roles.
Now that we have a user created, we need to assign the user permissions. Before we do, let’s look at groups. Groups allow you to group related users together and assign them permissions as a unit. This process is usually less time-consuming and less error prone.
Managing Groups
When you apply permissions to individual users, it is very difficult to keep track of who has access to which resources. Grouping related users makes managing permissions much easier. Groups reduce the number of unique permissions sets you need to keep track of. (In the first exercise at the end of this chapter, we build a set of common groups as a starting point.)
Note that these two commands return different information. The Get-IAMGroups (plural) command returns a group object that does not include the group members. The Get-IAMGroup (singular) command returns a GetGroupResult object that includes the group and a collection of users.
At this point we have created a few users and groups and have added users to groups. But, our users still don’t have permission to do anything. In the next section, we will grant permission to our users.
Managing Policies
We use policies to grant permissions to users and groups. Policies are JSON statements that describe what API calls a user or group is allowed to call. You can grant or deny access to every API call. Before we get started, let’s do a quick review of JSON.
JSON Primer
This is a very brief introduction, but you can see that JSON can be used to represent very complex structures. I could write a whole book on JSON – and others have – but this is all we need to understand IAM policy statements.
Policy Actions
Actions determine which API calls are allowed or denied by a policy. Remember that PowerShell commands call API WebMethods. In other words, you can grant or deny access to each individual PowerShell command.
As you can see, IAM policies allow fine-grained control over access. In Exercise 9.1 we will develop a set of least privileged roles for EC2. Now let’s look at resources.
Policy Resources
So far, the policies we have written apply to all resources. When we granted access to S3 in the following example, we allowed the user to act on all objects in all buckets. Some services allow you to scope the access. In S3, we might want to allow access to a specific bucket or folder.
Policy Variables
Name | Description |
|---|---|
aws:CurrentTime | Date and time of the request |
aws:EpochTime | Date and time in Unix time format |
aws:TokenIssueTime | Date and time that temporary credentials were issued |
aws:principaltype | A value that indicates whether the principal is an account, user, federated, or assumed role (see the explanation that follows) |
aws:SecureTransport | Boolean representing whether the request was sent using SSL |
aws:SourceIp | The requester’s IP address, for use with IP address conditions |
aws:UserAgent | Information about the requester’s client application, for use with string conditions |
aws:userid | Unique ID for the current user |
aws:username | Username of the current user |
s3:prefix | Prefix passed in some S3 commands |
s3:max-keys | Max-Keys information passed in some S3 commands |
sns:Endpoint | Endpoint passed in some SNS calls |
sns:Protocol | Protocol passed in some SNS calls |
Unfortunately, not all services support resources. For example, S3 and IAM do, but EC2 does not. Luckily we can use conditions to control access to EC2 objects by tag. But, before we talk about conditions, let’s look at policy actions.
Policy Actions
Effect, resource, and action are required components of every policy statement. There are also numerous optional components. I’m not going to cover all of the options here, but I do want to discuss conditions. Conditions are very useful for controlling access to EC2. Let’s have a look.
Policy Conditions
Conditions allow you to write custom logic to determine if an action is allowed. This is a complex topic that could easily fill a chapter. I am only going to show you how to write conditions based on EC2 tags. You can read more about conditions in the IAM user guide.
Notice that I have included the optional version to tell AWS this policy requires the latest version of the policy language. Also notice the format of the resource ARN. Remember to replace the 123456789012 with your account number.
Now that we know how to write a policy, let’s associate it with a user and group using PowerShell.
Creating Policies with PowerShell
As you can see, IAM policies give you fine-grained control over access to AWS. You can be very specific about who has access to which resources. The details are all contained in the policy statement. In Exercise 9.1 we will create a common set of groups with least privileged policy defined. Before we end the section on policies, let’s spend a moment on managed policies.
Managed Policies
Up to this point, we have been creating policies by hand. In practice, this can get tedious. In addition, it is easy to make mistakes that grant more permission than you intend and compromise security. As you might expect, there are many common patterns that emerge. For example, most organizations have a team of system administrators and they grant them access to EC2, ECS, and so on, or network administrators that need access to VPC, Route 53, and so on.
Luckily, AWS has created a collection of managed policies that solve common problems. It is often much easier to use these policies rather than writing your own policies. In addition, you can create your own managed policies.
Why would you want to create a managed policy when you can attach a policy directly to a user? You can define a policy once and use it across many users, groups, and roles. This promotes consistent permissions across your security principals. In addition, managed policies support versioning so you can maintain a history of changes. Policies attached directly to a user do not support versioning.
Managing Roles
Remember from Chapter 2 that an IAM role can be used to associate a policy with an instance, rather than a user. This is just one example of a much more powerful concept. Roles allow you assign permission to AWS services, AWS accounts, SAML identities, and other resources. Let’s look a few examples.
Let’s define a few roles to understand how they work. Creating a new role is similar to the process we used to create a user or group, but we also need a second policy that defines what resources can assume the role. There are two policies required: the first describes who can use the role, and the second describes what the role can do.
Note that you have used Auto Scaling at some point in the past, you will likely get an error because this role already exists.
At this point it should be clear that AWS offers a robust permission model that gives you tremendous control over your identities. Of course, this can get confusing so let’s look at options to audit your IAM policies with PowerShell.
Auditing IAM Access
At this point you know how to manage permissions for user, groups, and roles. Before we close this chapter, I want to discuss a few miscellaneous IAM commands.
Miscellaneous IAM Commands
I want to discuss a few miscellaneous IAM commands that did not warrant their own section. Therefore, I included them all here.
Managing Password Policy
You can also get the current policy using Get-IAMAccountPasswordPolicy and remove the policy using Remove-IAMAccountPasswordPolicy.
Setting the Account Alias
Finally, you can get and set the account alias. Remember from Chapter 2 that the account alias is used to create an easy-to-remember sign-in URL.
You can also get the current alias using Get-IAMAccountAlias and remove the alias using Remove-IAMAccountAlias.
That brings us to the exercises. As you have seen, IAM gives you fine-grained control over access to AWS resources. You can be very specific about who has access to which resources. In Exercise 9.1 we create a set of common groups that provide least privileged access. In Exercise 9.2 we will learn how to permit access to billing and support.
Exercise 9.1: Creating Least Privileged Groups
Throughout this book we have been using a single account that has administrator access to all services. Obviously this is a bad idea in production. We only want to allow those permissions that each user needs. Let’s create a few common groups as a starting point.
Note: AWS supplies a series of managed policies called AWS Managed Policies for Job Functions . These policies define roles for common job functions. You should consider using them rather than creating your own policies and groups as I am doing in this example.
Let’s assume that our company is using AWS for development. The main users are software developers. We have a team of AWS experts who support the developers. In addition, the developers are supported by the traditional system administrators and network administrators. The system administrators support the operating system, and the network administrators are responsible for routing, load balancers, and network security.
In this exercise we created a group for each of the teams that uses AWS at our fictitious company. Obviously you will need to tweak these groups to fit your company’s needs, but I hope this will create a good framework to get you started. In the next exercise, we will grant access to billing and support to IAM users.
Exercise 9.2: Delegating Account Access To IAM Users
Back in Chapter 2, we discussed the difference between AWS account credentials and IAM users. Remember that the AWS account is the e-mail address you used to create your account. You almost never use this account, but there are a few times you need it. Two of these reasons are accessing your bill and getting support.
By default, you must log in using your AWS account credentials to see your bill or access support, but you can also grant access to IAM users. And, as you might expect, you can control exactly which users can access the billing and support features. Note that you have to pay extra for support.
You cannot enable IAM access to billing using PowerShell. You must sign into the AWS Management Console using your account credentials to enable it. The following steps show you how:
- 1.
Sign into the console using the e-mail address and password you used to create your account.
- 2.
Click your name on the menu bar at the top right of the screen.
- 3.
Click My Account from the drop-down menu.
- 4.
Scroll down until you see the section shown in Figure 9-1.
- 5.
Select both the Account Activity Page check box and the Usage Reports Page check box. Click the Activate Now button.
IAM access to the AWS web site
Next we have to create an IAM policy granting access to IAM users. Interestingly, you cannot configure billing and support from the IAM wizard. You must create the policy manually. Luckily we know exactly how to do that. Let’s create two groups: one for billing and one for support.
Now, whenever you want to grant a user access to billing or support, you simply add the user to the appropriate group.
Summary
In this chapter, we saw how IAM provides unprecedented control over access. We learned to create users and manage their passwords and access keys. Then, we learned to create groups and manage membership. We also learned to create roles for EC2 instances.
Next we learned to create policies and saw that IAM offers the granularity to enable least privileged access control over all of the AWS services. In the exercises we created a collection of groups for common IT roles and enabled access to billing and support. This is a great start for creating an enterprise access policy.
In the next chapter, we will focus on Simple Storage Service (S3). S3 is a highly resilient data solution for storing files. This is the data store AWS uses to keep snapshots and RDS backups, but you can use it to store anything you want.