AWS Identity and Access Management (IAM) is needed to make everything else work on AWS. Without knowledge of it everything else is much harder to set up. Unfortunately it’s a glaring blind spot for many people and is treated as purely a concern for infrastructure teams. This approach doesn’t allow for as fine grained access controls as there could be and makes it harder to debug what is going wrong with cloud deployments.

In this article I’ll talk about:

• IAM Groups, Users and Roles
• IAM policies and how they work with other IAM constructs
• AWS STS and how to assume a role

We will not be covering a whole bunch of topics that go along with IAM. This includes stuff like connecting IAM with SSO and active directory. All of those are necessary for a full production setup of AWS but they’ll have to come in the future. So with that out of the way let’s dive in!

AWS Roles and Users

First up we are going to talk about IAM users, groups and roles. These are core constructs for managing identity in AWS.

We’ll discuss IAM Users first because they are the most straightforward of the concepts. Unfortunately they really shouldn’t be used in production for reasons we will get into later. IAM Users are long-lived constructs for a person or service account to access AWS resources. By default they get access to nothing but that can be changed by adding an inline policy or role to the user.

The reason that users shouldn’t be used is that their long lived nature makes rotation hard. In production you are much better off assuming a role each time for a person or service account and having that tied into a single sign on organization. The details of how to do that will have to be in a future piece though.

A group is a collection of users. This can be used to share permissions between multiple users. In theory this would be useful for managing something like having a set of permissions for developers. In practice groups can only be used with IAM users so they aren’t actually all the widely used.

IAM Roles are temporary credentials that can be assumed. This assumption happens through AWS Secure Token Service (STS). Since IAM roles expire they should be the preferred form of permissions that are used since there is the lowest risk of a security breach from a role. IAM roles function in much the same way as groups in terms of permissions where you need to attach a policy or have an inline policy to actually do anything with them.

AWS Policies

Policies are what actually drives the permissions that exist for a user or role. You can attach multiple policies to a role so understanding how those permissions work together is important. The basics are that explicit overrides implicit and that denies over rule allows.

For the purposes of this essay we are only going to talk about identity policies. There are many other kinds of polcies that are attached to different resources (https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html).

There are two main kinds of identity policies. The first of those is inline policies. These are policies which are directly attached to a role or user and can’t be shared between roles and users. For the most part you want to use these sparingly because of the lack of portability. The other kind of policy is a managed policy which can be attached to different roles. The first of these are AWS managed policies that are created by AWS. The other kind is a custom policy which is the type of policy which you create yourself.

When we look at a policy you first will see a version that is almost always “2012-10-17”. Next up is the statements section. This is the action that the policy either allows or denies you. This is a list with the action, the resource and the effect along with an id called the Sid.

AWS STS

AWS STS allows you to assume a role, this grants access to resources across different accounts and environments. This is particularly useful in situations where a user needs to access resources that are not within their own account, such as when an administrator needs to access resources in a production account.

One way to assume a role is to use the Security Token Service (STS), which is a web service that provides temporary, limited-privilege credentials to users or services. With STS, users can request temporary credentials that allow them to access resources in other accounts.

One trick that can be useful when assuming a role is to use cross-account roles. With a cross-account role, you can grant permission to another AWS account to access resources in your account. This can be particularly useful when you need to share access to resources with another team or organization.

To assume a cross-account role, you first need to create a role in your account and specify the other AWS account as a trusted entity. Then, you can use the STS AssumeRole API to request temporary credentials that can be used to access the resources in the other account.

In addition to using cross-account roles, there are a few other tricks that can be useful when working with STS. For example, you can use the STS GetFederationToken API to create a federation token that can be used to access resources in multiple accounts. This can be useful when you need to access resources in several different accounts, as it allows you to get temporary credentials for all of the accounts in one API call.

Another trick is to use the STS AssumeRoleWithWebIdentity API, which allows you to use an identity provider (such as Amazon Cognito or Login with Amazon) to get temporary security credentials. This can be useful when you need to access resources in another account but don’t have an IAM user or role in that account.

Overall, STS offers a variety of powerful features and tricks that can make it easier to manage access to resources in the cloud. Whether you need to assume a role in another account, share access to resources with another team, or access resources in multiple accounts, STS can help you do it securely and efficiently.

Conclusion

In this essay we covered the basics of AWS IAM. This includes understanding users, groups and roles along with understanding policies. We also covered how to assume roles using AWS STS and how cross account access works with roles.

From here it’s worth digging into other sources of permissions in AWS including SCPs, security groups and ACLs. It’s also worth looking into SSO and how to integrate it into an AWS account or organization. Security on AWS is very broad and there are lots of different things that you need to know to fully understand it.