Understanding self-assumption and scoped down policy of an AWS IAM role

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 running the aws sts assume-role command. 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.

“Least privilege” is a well-known principle of IAM. It grants only the required set of permissions to execute the tasks associated with a role.

IAM role 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.

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