AWS IAM — Quick Dive/Quick Guide

AWS IAM Logo

At work I recently presented to a group of my peers on the subject of AWS IAM. I did so from the perspective of how we at Pluralsight use the service. Here you'll find an adapted version of that presentation. Let's dive right in!

What is IAM?

IAM is one of the many AWS services. It is an acronym for Identity and Access Management. As a key AWS service it helps you manage user identities and control access to your AWS resources. Those resources could be in: databases, EC2, S3, etc. It allows you to securely control who can access your resources, as well as what actions they can perform. For example, if we want a user to only be able to get data from a data store we can specify via an IAM policy that this user/role can only do that. Thereby, excluding the permissions of modifying and deleting. This is extremely powerful. It is based on the premise of least privilege.

Key Features and Concepts

1. Users and Groups

   • Represent people or applications that require access to AWS resources. Each user is assigned unique credentials to authenticate their identity.

2. Roles

   • Used to grant permissions to entities within AWS, meaning to services or external applications, rather than individual users.
   • Roles allow secure access to resources without sharing long-term credentials. When dealing with roles we don't have to rotate access keys or keep up with credentials when using them.
   • Users can assume a role that has permissions to do what they need. Roles can also assume roles.

3. Policies

   When we talk about IAM if users, groups, and roles are the bones, it could be argued that policies are the meat of IAM.

   • JSON documents that define the permissions associated with users, groups, or roles.
   • Policies determine what actions are allowed or denied on specific AWS resources.

4. Multi-Factor Authentication (MFA)

   • An extra layer of security by requiring users to provide additional authentication factors, such as a temporary code or push notification generated by a virtual or physical MFA device.

5. Access Keys

   • Used in IAM as credentials for programmatic access to AWS services through APIs or Software Development Kit (SDK).
   • They are either used by an application or an individual using a command line interface.

6. Fine-Grained Permissions

   • IAM offers granular control over permissions, allowing us to specify permissions at the individual API operation level for any resources and services in our account (or others). Example: I want this user/role to be able to list objects in the S3 bucket but I don't want them to be able to get anything from the bucket.
   • Super powerful, when used correctly. This is how AWS hands off security in the cloud, while they are responsible for the security of the cloud.

ARN Breakdown

ARNs are an essential part of provisioning those fine-grained permissions that were mentioned previously. It will also help to note that not all ARNs are created equal. By the following we'll learn how to assign permissions for resources using ARNs or adaptations of ARNs.

Policy Breakdown

Below is an example of a policy that you will see in the wild. It is quite liberal in some of its statements and the actions they allow. Policies have a Version and Statement. The Statement property is a list of JSON objects. Let's examine it more closely.

AWS IAM Policy One

• Statement 1

  • Allows all Get* actions (GetParameters and GetCommandInvocation) for Systems Manager on all resources in that service. It also allows all actions in Cloudformation on all resources in Cloudformation. When I say “all resources” I mean all resources in this account.

• Statement 2

  • Allows all actions for S3 on all objects in S3 that this account owns and that begin with cdk-. The * matches any string — wildcard.
  • Notice the differences in the ARN. It's missing the AWS region, account number, and the resource denotation. S3 being a global service is the reason.

• Statement 3

  • Allows all actions for ECR on all resources in ECR — in this account.

  These statements have a "Sid" property. This property is optional and stands for statement ID. You can use it to help you quickly identify what the intentions for the statement are.

  Let's look at how we can drill down and achieve granularity with our provisions.



AWS IAM Policy Two

The above policy contains one statement that allows the user/role that it is assigned to to GetSecretValue in Secrets Manager for all secrets that begin with profile/ and my-super-secret-credentials. The * denotes that any string after would be considered as well. Next we'll review a basic trust policy.

AWS IAM Trust Policy

It is mentioned above that roles can assume roles. A trust policy is how that is achieved. You see that this policy has one statement with two additions when compared with the two statements that were previously covered. Those additions are Principal and Condition.

A Principal can be another AWS account or a CICD service (Github, Gitlab, etc.). In this example the Principal is a trusted federated identity provider — specifically Bitbucket.

Let's further examine the Federated property of the Principal object in this policy's statement. We can see an ARN (given to us by AWS) for the Bitbucket OIDC provider.

It allows this Bitbucket account's workspace pipeline the ability to assume the role that the trust policy is attached to. That means that this particular Bitbucket account will have, upon role assumption, the permissions allowed by the particular role that it assumes. Pretty cool, huh!?

Now let's talk about the Condition. This condition has an audience audthat refers to the intended recipient of the ID token that will be given it. The audience is a claim within the ID token that specifies the client or service for which the token is intended. Audience claims serve as a security measure to ensure that ID tokens are only consumed by the intended recipient. The recipient in this case being the following resource:ari:cloud:bitbuckt::workspace/9bb9a27q-19vi-4b3d-87fc-17898aa256611. This too is has the format of an AWS resource number. Notice how it begins with ari versus arn. It belongs to cloud. The service isbitbucket. Apparently there is no account number is referenced and there is no specified region, as bitbucket is global. The workspace however does have a universally unique identifier (UUID).

How can IAM be leveraged?

Well, we've covered some things but AWS can be integrated with and used in conjunction with other identity providers. You can use SSO or the new IAM Identity Center. Roles are the preferred method to use when dealing with users at scale. At Pluralsight, we use a third party to manage users versus doing so through IAM. This helps to avoid the burden of managing a host of credentials for the respective users/groups and allows for easier on- and off-boarding. It helps when managing thousands of users to use this approach to role-based access management.

Other than for humans, this can also be applied to third-party services like the various CICD tools. Having roles that assume roles may seem redundant but it creates layers of security and easier governance for least privilege.

Thanks for reading!