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.

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:*"
                }
            }
        }
    ]
}

  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 }}

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

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 

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

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:*"
                }
            }
        }
    ]
}

• Scoped down policy

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.

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"
        }
    ]
}

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

HAPPY ASSUMING!