Expose unique response identifier for web identity credentials

[ianonavy]

All opinions my own.

For organizations that use GitHub Actions and audit events with CloudTrail, it is useful to have joinable metadata to link specific GitHub Actions jobs to CloudTrail events. This allows security auditors to verify end-to-end the population of AWS operations invoked by a particular GitHub Actions workflow run attempt. I propose one of two approaches:

Approach 1: Allow configuration of masking policy for AWS Access Key ID

The AWS_ACCESS_KEY_ID is unique to a particular invocation of configure-aws-credentials as well as unique to a particular AssumeRoleWithWebIdentity event in CloudTrail. Since the access key IDs are temporary and the secret access keys are masked, one option might be to allow users to disable access key ID mapping such that they can be logged for traceability.

Example use case:

    - name: Configure AWS credentials from Test account
      uses: aws-actions/configure-aws-credentials@v1
      with:
        role-to-assume: arn:aws:iam::111111111111:role/my-github-actions-role-test
        aws-region: us-east-1
        mask-access-key-id: false

The API and implementation would probably be similar to the existing one for the AWS account ID.

Approach 2: Expose raw assume role ID

Assuming that assume role IDs are indeed unique to a particular AssumeRoleWithWebIdentity request, then adding data.AssumedRoleUser.AssumedRoleId the outputs of this action would allow end users to log it.

Example use case:

    - name: Configure AWS credentials from Test account
      uses: aws-actions/configure-aws-credentials@v1
      with:
        role-to-assume: arn:aws:iam::111111111111:role/my-github-actions-role-test
        aws-region: us-east-1
        output-assumed-role-id: true

We also considered using the configurable role-session-name, but we'd rather not rely on user-controlled inputs. In my opinion, the default behavior of the action should be to produce auditable metadata that can be emitted in logs on the GitHub Actions side.

[peterwoodworth]

Thanks for the request @ianonavy,

I'm interested in hearing more about this:

We also considered using the configurable role-session-name, but we'd rather not rely on user-controlled inputs. In my opinion, the default behavior of the action should be to produce auditable metadata that can be emitted in logs on the GitHub Actions side.

Does this mean that you think of the two approaches that you suggested, that the new functionality we introduce should be the default? I'm curious in what the goal with using role-session-name would be in this use case, and what the limitations are in achieving that goal.

I'm also interested in hearing from more people in if the first approach, the second approach, or a different approach entirely would be preferred. Or if we should do both approaches proposed!

[ianonavy]

Does this mean that you think of the two approaches that you suggested, that the new functionality we introduce should be the default? I'm curious in what the goal with using role-session-name would be in this use case, and what the limitations are in achieving that goal.

The goal overall is to reliably join data (including logs) from the GitHub Actions API with data from CloudTrail. We want to be able to query GitHub for information about each unique invocation of configure-aws-credentials, and then be able to associate that invocation uniquely to an sts:AssumeRoleWithWebIdentity event in CloudTrail. Right now we are trying to do that with logs since GitHub does not appear to offer any API for storing audit or tracing metadata at this time (happy to be corrected!)

Since the value of role-session-name is automatically logged, we could try to use it to link events from both GitHub and CloudTrail. The issue is the values are not guaranteed to be unique since they are controlled by the user. role-session-name is a convenient extra check, but it is not a reliable unique identifier for joining events. We need an identifier that is unique to the session and generated on the AWS side. The ones I identified were access key ID and assumed role ID.

I'm also interested in hearing from more people in if the first approach, the second approach, or a different approach entirely would be preferred. Or if we should do both approaches proposed!

I suppose after thinking about it, neither approach fully achieves the goal of the request. We'd rather not have to require our developers to do anything in particular to produce an auditable log. Ideally, they simply call the action "as is" and security auditors can join events between the GitHub API and CloudTrail. With that in mind, I propose another, way simpler approach:

Approach 3: log assumed role ID

Add a line like this after line 118 in index.js:

core.info(`Authenticated as assumedRoleId ${data.AssumedRoleUser.AssumedRoleId}`)

There seems to be precedent in other actions to log unique values relating to an authentication for informational purposes. I think adding this log line would add tremendous value to teams using GitHub Actions to make changes in AWS with very little cost.

The drawback of the original two approaches I suggested is that they rely on developers to log the unique session identifier on their own each time. It would be easy to forget that log step and break the chain of metadata needed to join GitHub Actions event data with CloudTrail, so this third approach would make it impossible for a developer to block the linkage.

I hope this helps clarify what we are trying to accomplish, and I am open to other suggestions on how we can achieve the goal. :)

[peterwoodworth]

Thanks for the helpful reply @ianonavy,

would add tremendous value to teams using GitHub Actions to make changes in AWS with very little cost.

I'm curious what you think the cost would be. Personally I'm a bit concerned that if we were to do this then people might think we're logging sensitive information by default. Because of this, I don't think I'd want to log this by default and instead would want to have a setting in the workflow file. However, we can think about logging this by default when we release our next major version, which is something we're starting to work on. We would be able to do this if there's nothing sensitive about the role's unique id or the session name

[mike-dodge-eq]

Slightly old post, but some good references around AK sensitivity. It's fairly often exposed, whether through things like Cloudtrail or even through pre-signed URLs, so some precedent of it:
https://security.stackexchange.com/questions/187992/is-an-aws-access-key-id-a-secret

[ianonavy]

I'm curious what you think the cost would be. Personally I'm a bit concerned that if we were to do this then people might think we're logging sensitive information by default. Because of this, I don't think I'd want to log this by default and instead would want to have a setting in the workflow file. However, we can think about logging this by default when we release our next major version, which is something we're starting to work on. We would be able to do this if there's nothing sensitive about the role's unique id or the session name

Given the assumed role ID refers to temporary credentials and there is no way to perform any operations with just the role ID, I don't think there is any material risk to log it by default. I personally believe the cost for the end user is negligible—it's just a few bytes of log data per invocation.

👋 @peterwoodworth is a PR welcome? We keep getting requests for this feature internally to improve some security reports

[peterwoodworth]

@ivan-santos-eq PRs are very welcome! Let me know if you need anything from my end

[aidansteele]

+1 to this feature request. I'd find it helpful if there was an option to unmask the access key ID.

@ianonavy the assumed role ID isn't really unique. It is just ${RoleId}:${RoleSessionName}, where ${RoleId} is the value (beginning with AROA) reachable by running aws iam get-role --role-name ${RoleName} --query 'Role.RoleId'. So it won't achieve the desired outcome of being able to correlate GHA workflow jobs with actions in CloudTrail.

Technically access key IDs aren't unique either, but they achieve the desired outcome 99.99% (number made up) of the time.

[peterwoodworth]

Unique identifier is now shown in workflow logs in v3