Trusted Entitles and Cross-Account IAM Authentication

Multiple Account Strategy, Cross-Account IAM Roles, and Role Switching ““ Part two of this three part series.

In the second installment of our multi-part post on using multiple AWS accounts in your organization we’re going deeper into the technical side of creating cross-account roles for IAM authentication. In this post we’ll discuss Trusted Entities, IAM permission granularity, step-by-step directions to create a custom IAM role and role switching using the custom URL for the new role.

IAM roles can be used in several different ways:

1. Assigned to services like lambda, or to ec2 instances to allow permission to the instance without passing credentials
2. Assigned to user accounts to control what a user has access to
3. Allow access from other AWS accounts using Trusted Access
4. Control S3 access
5. And even more!

In this blog post we’ll be concerned primarily with points 2 and 3. We’re going to create an IAM role with specific privileges and allow another account to assume that role. Whether that account belongs to another organization (MSP, Consultant, etc.) or to another group within your own organization (Developers, DevOps, or even Finance and BizOps), the method for creating the role is the same.

The first thing we’ll need to determine is the account number for the role you want to grant privileges to.  That can be done in several ways – often it’s in the account sign-in URL {https://{your_account_number_or_alias}.signin.aws.amazon.com/console}, though in some cases your organization may be set up with an Account Alias which would then take the part of the account number in your sign-in URL. If your organization is set up with an alias, you can find the AWS Account ID in the lower left-hand corner of the IAM (Identity and Access Management) services page. 

Take note of this ID, as we’ll need it in later steps. This is the ID that we’re going to set as a Trusted Entity for the IAM role we’ll create. What is a Trusted Entity? A Trusted Entity is an object from outside of your AWS Account which is allowed to gain access to a resource within your account – in our case that
resource will be an IAM role, which will in turn grant them permissions within the account.

Depending on the duties of the user(s) you’ll be granting access to, you may want to have multiple IAM roles with specific and granular access configured for each. The first step in creating a new IAM Role is to select what type of trusted entity will be using the role – either an AWS Service, Another AWS Account, a Web Identity, or SAML federation.

We’re going to select “Another AWS Account” and enter the account ID we noted earlier. If the API or CLI are all that will be used, you can select “Require external ID” – however, if you anticipate this being used via the web console you will not select this option. You may also choose to select “Require MFA” for additional security.

This will require that the user switching roles be logged in to their console session with an MFA device. Next, we’ll attach permissions policies. If you’d like to use custom permissions you may create a new policy, or if you want to use default policies you can select them. Let’s walk through creating a custom policy.

IAM permissions can be configured either via guided GUI or by manually entering JSON. 

Let’s assume you’ve got a developer who needs access to trigger any Lambda function on the account, but should not have access to delete or create new functions. You may also want to allow them to update the function’s code. The below JSON is a simple example of a policy which would allow a user to list functions and tags, invoke functions, and update the code for all functions on the account.

        {
        "Version": "2012-10-17",
        "Statement": [
            {
            "Sid": "DeveloperLambdaFunction",
            "Action": [
                "lambda:Get*",
                "lambda:List*",
                "lambda:InvokeAsync",
                "lambda:InvokeFunction",
                "lambda:PublishVersion",
                "lambda:UpdateFunctionCode"
            ],
            "Effect": "Allow",
            "Resource": "*"
            }
        ] 
        }

This would still require someone like a DevOps Engineer, Project Owner, etc. to create new lambda functions. Alternatively, you could require that all functions be created and updated via CI/CD and remove the “lambda:UpdateFunctionCode” tag from the permissions, but that is outside the scope of this post. Click Review Policy, add a meaningful Name and Description and click Create Policy. Remember, you can assign up to 10 policies to a role.

Back in the Create Role window, you should be able to search for your newly created role after refreshing the window.

Select your role, and click Next: Tags. Add any tags you may want to use  – remember, tags are great for billing, logging and monitoring, among many other reasons. When you’ve added your tags, click Next: Review. Add a meaningful Role Name and Description and click Create Role.

After creating the role you will be returned to the list of all roles on your account. Click on the new role we just created, and you’ll be taken to the Role Summary page. On this screen you’ll find the URL which can be used to automatically switch roles.

When a user who is signed into the remote account clicks this link they will be taken to the Switch Role page, with the account and role pre-populated. Select whichever color you would prefer from the provided palette, enter a meaningful Display Name if you choose to, and click Switch Role.

That’s it! You’ve created a cross-account IAM policy and signed in from a remote account! Stay tuned for part 3, where we’ll discuss Master Billing accounts, tagging, and billing reports!

Take another peek at Part 1 >