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 >

How to Manage an Effective Digital Transformation in Changing Times

Tech leaders are facing new challenges in 2022: more pressure than ever to keep systems thriving in the midst of huge technical demand… and the threat of losing the skilled labor required to do it. In this exclusive series, we’ll share some key takeaways to help tech teams stay agile:

  • Why digital transformation is an insurance policy against attrition and change
  • How to identify and manage the technical debt that threatens employee productivity and fulfillment
  • How DevOps practices can liberate and improve tech teams
  • The playbook we use ourselves at MercuryWorks to create painless digital transformations for our enterprise clients
strategy planning for a custom application

No Comments

Leave a Comment

Your email address will not be published.