How to deal with cross-account access in AWS IAM

When I was preparing for my AWS Developer exam, something that I could barely wrap my head over was IAM. AWS IAM, Identity & Access Management, is the core of the whole AWS architecture and it is presented in the either first or second chapter in every AWS tutorial. At the first glance, it looks easy. But after passing my exam and having done some hands-on management work for the whole organization of the company, I realized it is maybe the most complicated product AWS provides.

Its complexity comes from several angles or layers if you think about it, one of that is it is actually based on some simple terms and designs, but when all of them come together, the situation always becomes chaotic.

I believe one of the problems current tutorials or online courses have is they forget to make you prepared for so many “they look similar, but they don’t mean the same thing” terms and concepts, thus whenever your brain tends to extract the information from the materials, you automatically map or blur something with another. It might take you a long road before you finally realize the fallacy your instinct brings in.

So my suggestion to you, if you’re learning AWS, or doing DevOps on AWS, is to give yourself a sufficient amount of time to play around IAM environment, fully understand every basic and critical concept (for example, read the User Guide like this multiple times) before starting working on an actual task, and… I am going to talk about one interesting and quite essential operation in IAM.

One popular scenario for using IAM in real life is delegating cross-account access. If one IAM user is going to read data from an S3 bucket in the same account, the user can simply be granted the S3 Read permission.

However, things are different if the user wants to access resources that are in a different account. It’s a bad practice to create a new IAM user in the account that target resources belong to, and it requires users to switch accounts, log out and log in again.

John wants to have access to a bucket in account B, but it doesn’t work

AWS encourages uses to use cross-account delegation for this situation. Simply speaking, the whole process works like this:

With the help of AssumeRole policy added to John in account A and a role in account B, now John is able to read data from that bucket.

As the diagram shows, John in account A would like to read data in an S3 bucket in account B. Imagine a role is a costume for a user to wear or a game character you’d need to choose at the beginning of a game. It’s the same in IAM world. To be able to use that S3 bucket, you need to wear a certain costume.

But what role is that? Okay, first of all, create that role in account B, if it doesn’t exist. This role should: 1) specify the trust relationship with account A; 2) attach permission of S3 Read; 3) specify that S3 bucket as the target.

Now the work on the account B side is done. What else is on the side of account A?

IAM user John should have certain permission to assume the newly created role in account B. That’s done by clicking Add permissions for user John, and add this as the inline policy, you can either use Visual Editor or JSON to do that.

{   
  "Version": "2012-10-17",   
  "Statement": {     
    "Effect": "Allow",     
    "Action": "sts:AssumeRole",     
    "Resource": "arn:aws:iam::Account-B-ID:role/S3Read" 
  } 
}

After doing that, the trust relationship is completely built.

Let’s look at a real-world example:

For better service observability, your organization wants to create a Grafana workspace for monitoring metrics, logs, and traces. AWS has a managed Grafana product called Amazon Managed Service for Grafana, which offers a handy setup. You want to use the Grafana workspace to monitor data sources from the whole organization, which is a fair requirement. You create the workspace in a newly created, dedicated AWS account only for observability use, however, AWS currently only helps you set up fully-scope data source policies only if the workspace is created in your root account.

For centralized observability, multiple data sources ingest data to Grafana in a dedicated member account

You realize you have to customize policies yourself to ingest data from different data sources from different accounts to this observability account.

This is exactly how the access delegation in IAM comes into the picture. Here is a guidance example.

• In the service account, create a role called GrafanaDataSourceRole, define the observability account as the trusted entity. Attach policy to allow certain actions, i.e. CloudWatch Read and List permission.
• In the observability account, create a role called AmazonGrafanaServiceRole with AssumeRole permission and attach it to the Grafana service.