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:*”
}
}
}
]
}
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.
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.
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!
