Per-secret configuration overrides for AWS Secrets are ignored

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

When trying to override the AWS_ROLE_ARN variable specified for a specific secret, the override is always ignored.

Steps to reproduce

This needs an integration with AWS, so there's some prerequisites to set up Gitlab as a trusted source by sts.amazonaws.com. You then need a minimum of two AWS roles that your pipeline runner is able to assume with it's identity as a gitlab runner associated to your repository.

stages:
  - test

variables:
  AWS_ROLE_ARN: 'arn:aws:iam::<account-id>:role/gitlab/role-1'
  AWS_REGION: eu-west-2

test:
  stage: test
  id_tokens:
    AWS_ID_TOKEN:
      aud: https://gitlab.com
    SECOND_TOKEN:
      aud: https://gitlab.com
  secrets:
    MY_SECRET:
      aws_secrets_manager:
        secret_id: 'my/secret/variable'
        region: 'eu-west-2'
        role_arn: 'arn:aws:iam::<account-id>:role/gitlab/role-2'
        role_session_name: 'ignored-config'
      token: $SECOND_TOKEN
      file: false
  script:
    - echo $MY_SECRET

What is the current bug behavior?

In the example yaml provided, the secret is attempted to be resolved by role-1 as specified in the AWS_ROLE_ARN variable, rather than role-2 as specified in the role_arn field.

What is the expected correct behavior?

The gitlab documentation of per-secret overrides specifies that the role specified in the role_arn field should be used instead of the variable specified in the AWS_ROLE_ARN for this secret.

Output of checks

This bug happens on GitLab.com

Possible fixes

I am wondering if this could be using the AWS cli under the hood, which specifies that: AWS_ROLE_ARN: If defined, this environment variable overrides the value for the profile setting role_arn. You can't specify a role session name as a command line parameter.

So perhaps this is overriding the intended behaviour?

Edited by 🤖 GitLab Bot 🤖