Understanding self-assumption and scoped-down policy in AWS IAM

AWS IAM is a fundamental service for all 200+ AWS services, as it enables interaction with AWS principals. An AWS IAM role consists of two components: a policy and a trust relationship. The trust relationship handles authentication, while the policy is for authorization.

Image description

The trust relationship has rules specifying which AWS principals are allowed to assume the role. What is assume the role? In a nutshell, entities can use AWS STS to assume the role by calling the aws sts assume-role. If an entity is able to assume the role, it can execute the actions specified in the attached policy. Therefore it’s important to follow best practices and choose suitable patterns when implementing IAM.

  • Self-assumption

Have you ever encountered a scenario where an IAM role assumes itself? It may sound awkward, yet it’s real. An IAM role needs to be explicitly allowed to assume itself as it doesn’t have self-assumption capabilities by default. It is to improve consistency and visibility of a role’s privileges.

To elaborate, I have an IAM role GHAction-Role with AssumeRoleWithWebIdentity to authenticate GithubActions in AWS and a github action respectively.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "GithubOidcAuth", "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" }, "Action": [ "sts:AssumeRole", "sts:AssumeRoleWithWebIdentity" ], "Condition": { "StringLike": { "token.actions.githubusercontent.com:sub": "repo:harik8/services:*" } } } ]
}
Enter fullscreen mode
Exit fullscreen mode
 STS: runs-on: ubuntu-latest needs: [CI] steps: - name: Git clone the repository uses: actions/checkout@v4 - name: configure aws credentials uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: ${{ vars.IAM_ROLE_ARN }} # ARN of the GHAction-Role aws-region: ${{ vars.AWS_REGION }}
Enter fullscreen mode
Exit fullscreen mode

Output of above action.

Run aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::123456789012:role/GHAction-Role aws-region: eu-north-1 audience: sts.amazonaws.com
Assuming role with OIDC
Authenticated as assumedRoleId AROASIGA2HTHJOXZFKTPL:GitHubActions
Enter fullscreen mode
Exit fullscreen mode

The GitHub workflow is able to assume the role using WebIdentity. However, if the GitHub workflow tries to perform sts:AssumeRole against the GHAction-Role, it will encounter an issue.

aws sts assume-role --role-arn arn:aws:iam::123456789012:role/GHAction-Role --role-session-name GitHubActions 
Enter fullscreen mode
Exit fullscreen mode
An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:sts::12345678912:assumed-role/GHAction-Role/GitHubActions is not authorized to perform: sts:AssumeRole on resource: arn:aws:sts::12345678912:assumed-role/GHAction-Role/GitHubActions
Enter fullscreen mode
Exit fullscreen mode

The trust policy of the GHAction-Role doesn’t currently allow it to assume the role. To resolve this, the GHAction-Role needs to be able to assume itself. Therefore, the GHAction-Role‘s ARN arn:aws:iam::123456789012:role/GHAction-Role should be added to the trust policy to permit this action as shown below.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "GithubOidcAuth", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:role/GHAction-Role", "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" }, "Action": [ "sts:AssumeRole", "sts:AssumeRoleWithWebIdentity" ], "Condition": { "StringLike": { "token.actions.githubusercontent.com:sub": "repo:harik8/services:*" } } } ]
}
Enter fullscreen mode
Exit fullscreen mode
  • Scoped down policy

Image description

If a given GitHub Action runs more than one job and requires different permissions for each, using a single GHAction-Role with maximum permissions is not a good design practice as it violates IAM’s principle of least privilege. This is where scoped-down policies come into play.

A scoped-down policy refers to a policy that grants the minimum set of permissions required for a user, group, or role to perform their necessary tasks.

Instead of having one generic role, GHAction-Role, with all required policies attached, we should create a specific role for each job with the necessary least privileges. For example, we would have roles like GHAction-Role-S3, GHAction-Role-EC2, and GHAction-Role-EKS. These roles would be assumed by GHAction-Role.

Image description

So, the trust policy for the above roles will look like this:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "GHAction-S3", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:role/GHAction-Role" }, "Action": "sts:AssumeRole" } ]
}
Enter fullscreen mode
Exit fullscreen mode

Even though self-assumption is suitable for certain use cases. Scoped-down policies generally provide more secure, control and manageable permissions.

HAPPY ASSUMING!


Discover more from Coursity

Subscribe to get the latest posts sent to your email.

Leave a Comment

Your email address will not be published. Required fields are marked *

Discover more from Coursity

Subscribe now to keep reading and get access to the full archive.

Continue reading

Scroll to Top