Understanding self-assumption and scoped-down policy in AWS IAM
Tags: aws, iam, security, githubactions
Published: 2024-07-08 21:13:55

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9e3k60zid5nx0s4f1ab5.jpg)

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3k9ejfqdxu3cde6y9txs.jpg)

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/h1qkptmbke6r8jxftxhe.jpg)

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!