Identity and Access Management - Amazon Web Services (AWS) Tutorial

AWS IAM, or Identity and Access Management is a service that allows you to manage access to your AWS resources. This includes access for internal and external users. IAM is important from a solution architecture perspective because it allows you to design secure access for your resources. Important entities in IAM include users, groups, policies, and roles. A user in AWS consists of a name and credentials, and is usually associated with a human user. You can group users to form user groups. This approach simplifies access management by assigning permissions to groups instead of assigning them to individual users. IAM also allows you to manage identities outside of AWS. If you already have your user identities configured in an external identity provider, you can use these with AWS. By doing so, you do not need to create IAM users in your AWS account. This can be an important architectural decision, as this will determine whether AWS or an external identity provider manages your identities. Microsoft Active Directory is a common identity provider used by customers. You can use identity providers that support OpenID Connect, also known as OIDC or Security Assertion Markup Language 2.0, also known as SAML. The next IAM entity is an IAM policy. A policy is a document that contains permissions. When associated with an identity or resource, it defines their permissions. For example, here is a policy that grants read permissions to S3 buckets. When this is assigned to a user, they will have get, list, and describe permissions on S3 buckets. When multiple policies are associated with a user, the resulting access is the cumulative effect of the policies. The next item entity is an IAM role. It is similar to an IAM user in that it is an identity with permissions. However, it is not uniquely associated with the user. Instead, it is intended to be assumed by anyone who needs it. Roles have policies associated with them that determine their permissions. Imagine you have an EC2 instance that needs access to an S3 bucket. AWS does not permit this access by default even if it is within your account. By attaching an IAM role with appropriate permissions to the EC2 instance, you can grant it access to the bucket. Here is another example. Let's say you have a Lambda function that needs to send notifications by publishing to an SNS topic. SNS is the notification service from AWS. By default, the Lambda function won't be able to access the topic. By attaching an IAM role to the Lambda function, you can grant it the necessary permissions to publish to the topic. You can also use IAM roles to grant access to other AWS accounts belonging to third parties to perform actions in your account. For example, you may want to grant access to a third party to upload objects to an S3 bucket in your account or you may want to share your logs with a third party for monitoring and analysis. Let's see how to do this. Let's say we need to grant access to a trusted third party to read information about our EC2 instances. Log in to the management console of the AWS account that will grant access to the trusted third party. Use the services menu at the top then go to Security, Identity, and Compliance and then go to the IAM service. Once you are here, click "Roles" on the left navigation pane and then click "Create role." Here, you can set the trusted entity type as an AWS account. Scroll down and select another AWS account and provide the AWS account ID of the trusted third party. For enhanced security, AWS recommends using a random string as the external ID. The third party must provide this external ID when assuming the role. For now, we'll skip this. You can also enforce that the third party use MFA or multi-factor authentication when assuming the role. For now, we'll skip this and click "Next." In the next step, you can add policies to grant permissions to the third party. I'm going to search for the policy named EC2ReadOnlyAccess. This is a preconfigured policy that grants read permissions to the EC2 service. Select the policy and click 'Next." Here, you can provide a name for the role. I'm going to call this as EC2ReadOnlyAccess. Review the configuration and click "Create role." The role has been created, and here is the ARN or the unique identifier for the role. Before a user can assume this role, it needs a few changes. Scroll down and under the "Trust Relationships" tab, you will find the trust policy of this role. It states that the assume role action is allowed for the root user of the trusted account. However, the role will be used by an IAM user of the trusted account not the root user. So we'll need to change this. Click "Edit trust policy" and replace the root with user followed by the user name of the IAM user in the trusted account. Scroll down and click "Update policy." This AWS account, that is the trusting account, is now fully configured. Let's now switch to the trusted account and see how to assume this role. Here in another browser tab, I'm logged in as the root user on the trusted account. IAM users who need to assume the role should be given the necessary permissions to perform the action. In other words, they need the assumed role permission. For this purpose, we'll need to create a new IAM policy that includes this permission. So on the trusted account, use the services dropdown menu, go to security, identity and compliance and then go to the IAM service. On the left navigation pane, click "Policies" and then click "Create policy." From the services dropdown, select the STS service, also known as the Security Token Service. It provides temporary access to trusted users. Under the right section, you will find the assume role action. You can assign this permission to the specific IAM role created in the trusting account by adding the role ARN here. Or you can allow this permission to all resources allowing the user to assume any role. We'll keep it simple and set it to all. Click "Next" and provide a name for the policy then scroll down and click "Create policy." The policy has been created and it should now be assigned to the IAM user, so they have the necessary permissions to assume roles. On the left navigation pane, click "Users" and then click on the desired username. Under the permissions tab, click "Add permissions" then select the option to attach policies directly and search for the policy you just created. Select the policy, click "Next", review your selections and then click "Add permissions." Now, we have the required configuration to allow the IAM user to assume the role. Let's test it. On another browser tab, I'm logged in as the IAM user. To assume a role, click your username in the top right-hand corner. Here, you will find the "Switch role" button. This option is only available when you are signed in as an IAM user. Root users do not see this option. Click "Switch role" and provide the account ID and the role name that you would like to assume. I'll go back to the browser tab where I'm logged in as the trusting AWS account. From here, I'll copy the AWS account ID and go back to this browser tab. I'll provide the account ID and the name of the role that I'd like to assume then I'll click "'Switch role." Now, I've switched or assumed the role. The role and account information is shown on the top right-hand corner. When I go to the EC2 service, I can view resources from the trusting account. As you can see, using IAM roles to grant access to third parties is more secure than sharing account credentials. Also, having a clear strategy for managing identities is important to the security of your AWS environment.