Unwanted Credential printing when using role-chaining

[victor-smg]

Describe the bug

1. Use Github OIDC provider to assume role basic role ROLE_1
2. Use role-chaining to assume a specific role ROLE_2 with extended permission for a specific workflow

Code example:

- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::${{ vars.ACCOUNT_ID }}:role/ROLE_1
    aws-region: eu-central-1
    role-session-name: SESSION_NAME
- name: Assume execution role
  uses: aws-actions/configure-aws-credentials@v4
  with:
    aws-region: eu-central-1
    role-to-assume: "arn:aws:iam::${{ vars.ACCOUNT_ID }}:role/ROLE_2"
    role-session-name: SESSION_NAME
    role-chaining: true
    output-credentials: false

This pattern is working as expected, however in the runner logs, github output aws credentials, despite having explicitly set output-credentials to false

Example of output:
Step: Configure AWS credentials

Run aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::XXX/ROLE_1
    aws-region: eu-central-1
    role-session-name: SESSION_NAME
    audience: sts.amazonaws.com
  env:
    AWS_REGION: eu-central-1
    GITHUB_REPO_NAME: xxxxx
    TERRAFORM_CLI_PATH: /home/runner/_work/_temp/xxxxx
  
Assuming role with OIDC
Authenticated as assumedRoleId ARARESOGVZRDSR:SESSION_NAME

Step: Assume execution role

Run aws-actions/configure-aws-credentials@v4
  with:
    aws-region: eu-central-1
    role-to-assume: arn:aws:iam::XXX/ROLE_2
    role-session-name: SESSION_NAME
    role-chaining: true
    output-credentials: false
    audience: sts.amazonaws.com
  env:
    AWS_REGION: eu-central-1
    GITHUB_REPO_NAME: xxxxx
    TERRAFORM_CLI_PATH: /home/runner/_work/_temp/xxxxx
    AWS_DEFAULT_REGION: eu-central-1
    AWS_ACCESS_KEY_ID: ***
    AWS_SECRET_ACCESS_KEY: ***
    AWS_SESSION_TOKEN: ***
  
Assuming role with user credentials
Authenticated as assumedRoleId ARARESOGVZRDSR:SESSION_NAME

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

The second step should not print those variables:

AWS_ACCESS_KEY_ID: ***
AWS_SECRET_ACCESS_KEY: ***
AWS_SESSION_TOKEN: ***

Current Behavior

Github runner prints those credentials, and do so in every other steps inside the job:

AWS_ACCESS_KEY_ID: ***
AWS_SECRET_ACCESS_KEY: ***
AWS_SESSION_TOKEN: ***

Reproduction Steps

• Have OIDC provider setup
• Have ROLE_1 that can be assume via OIDC
• Have ROLE_1 with those permissions:

Statement = [
      {
        Effect = "Allow"
        Action = "sts:AssumeRole"
        Resource = [
          "arn:aws:iam::${var.account_id}:role/ROLE_2",
        ]
      },
      {
        Effect   = "Allow",
        Action   = "sts:TagSession",
        Resource = "*"
      }
 ]

• Have ROLE_2 with those permissions:

Statement = [
      {
        Effect = "Allow"
        Principal = {
          AWS = "arn:aws:iam::${var.account_id}:role/ROLE_1"
        }
        Action = [
          "sts:AssumeRole",
          "sts:TagSession"
        ]
      }
    ]

• Use those steps in your job

- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::${{ vars.ACCOUNT_ID }}:role/ROLE_1
    aws-region: eu-central-1
    role-session-name: SESSION_NAME
- name: Assume execution role
  uses: aws-actions/configure-aws-credentials@v4
  with:
    aws-region: eu-central-1
    role-to-assume: "arn:aws:iam::${{ vars.ACCOUNT_ID }}:role/ROLE_2"
    role-session-name: SESSION_NAME
    role-chaining: true
    output-credentials: false

Possible Solution

No response

Additional Information/Context

The goal of this pattern is to have minimal access on the role assumable via OIDC, and required role-chaining that need to be explicit in the CI workflow to extend permission via dedicated role for the use case

[gruuya]

Given that

configure-aws-credentials/README.md

Line 114 in b92d0d9

| output-credentials | When set, outputs fetched credentials as action step output. (Outputs access-key-id, secret-access-key, session-token, and expiration). Defaults to false. | No |

I think the above example is expected, since output-credentials is false, and the action just does the default thing which is to export the keys to GitHub env. Note that this is slightly semantically confusing, since the word output there refers to step output and not env output.

Still I see a related problem here, and that is that regardless of the value of output-credentials the keys are exported to GitHub env

configure-aws-credentials/src/helpers.ts

Lines 42 to 75 in b92d0d9

	export function exportCredentials(creds?: Partial<Credentials>, outputCredentials?: boolean) {
	if (creds?.AccessKeyId) {
	core.setSecret(creds.AccessKeyId);
	core.exportVariable('AWS_ACCESS_KEY_ID', creds.AccessKeyId);
	}
	if (creds?.SecretAccessKey) {
	core.setSecret(creds.SecretAccessKey);
	core.exportVariable('AWS_SECRET_ACCESS_KEY', creds.SecretAccessKey);
	}
	if (creds?.SessionToken) {
	core.setSecret(creds.SessionToken);
	core.exportVariable('AWS_SESSION_TOKEN', creds.SessionToken);
	} else if (process.env.AWS_SESSION_TOKEN) {
	// clear session token from previous credentials action
	core.exportVariable('AWS_SESSION_TOKEN', '');
	}
	if (outputCredentials) {
	if (creds?.AccessKeyId) {
	core.setOutput('aws-access-key-id', creds.AccessKeyId);
	}
	if (creds?.SecretAccessKey) {
	core.setOutput('aws-secret-access-key', creds.SecretAccessKey);
	}
	if (creds?.SessionToken) {
	core.setOutput('aws-session-token', creds.SessionToken);
	}
	if (creds?.Expiration) {
	core.setOutput('aws-expiration', creds.Expiration);
	}
	}
	}

The original asking issue, and well as my own intuition/need would be that setting output-credentials to true will not "pollute" GitHub env, but instead allow individual steps to selectively use the creds from the step output in an opt-in fashion.

The fix seems trivial, but I'm wondering whether that is ok to revise?

[lehmanmj]

Hi victor-smg, the output-credentials flag actually controls whether or not the credentials are exported as outputs from the step. Credentials are always exported as environment variables, and environment variables are always printed with each step.

If you want to unset the environment variables, you could run a step like this after assuming the second role.

[github-actions]

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.