Support setting AWS_ROLE_ARN via env var for aws-cli/setup

[bobziuchkovski]

Checklist

• All new jobs, commands, executors, parameters have descriptions
• Examples have been added for any significant new features
• README has been updated, if necessary

Motivation, issues

Reduce boilerplate config when using OIDC roles. We set AWS_ROLE_ARN but currently have to set the following where OIDC roles are used:

steps:
 - aws-cli/setup:
      role_arn: "${AWS_ROLE_ARN}"

With this change, it would be possible to use aws-cli/setup directly as below, assuming $AWS_ROLE_ARN is set.

steps:
  - aws-cli/setup

At a glance, it looks like this orb tries to support many of the same aws-cli ENV vars where it makes sense. In this case, AWS_ROLE_ARN is also an AWS CLI env var, so that aspect matches existing behavior.

That said, the AWS_ROLE_ARN param is usually used in conjunction with AWS_WEB_IDENTITY_TOKEN_FILE env var to implicitly use web identity creds, whereas the orb explicitly assumes the web identity and pulls the resulting access key/creds from it. So the behavior diverges a bit there.

Supporting AWS_ROLE_ARN would be a nice touch for usability/DRYing config, though.

Description

For the aws-cli/setup command, default the role_arn param to $AWS_ROLE_ARN.

[marboledacci]

To approve this, add information about the default value in the description. It's important to tell this is going to be a default, specially because the existence of that parameter decides whether or not to use OIDC auth. If someone doesn't want to use OIDC and they have that environment variable, they would have to set it manually to an empty string.
It's also important to let people know that the default exist so they can use it.

[bobziuchkovski]

Good feedback, thanks!

I tried to document the new behavior as explicitly as possible and added an additional disable_oidc param akin to disable_aws_install that can be used in case someone wants to explicitly set AWS_ROLE_ARN without using oidc auth. I figured that's probably a bit cleaner than expecting someone to set role_arn: '', though the latter would still work given how the conditionals are structured.

[bobziuchkovski]

I dropped the reference to role_session_name here because it's being provided by default already (default value is $CIRCLE_JOB with unsupported chars replaced and truncated to 64 chars)

[marboledacci]

With the tests I realized something, the role ARN is going to be empty only on the script. For the workflow this implementation is always setting a value, making the parameter you created the only way to decide if the OIDC is being used. So by default this will try to always use OIDC, unless the parameter is set.
This means this PR is a big impact in the way the orb is used, adding something very small. I won't discard it, but this would need something more significant to justify a big release.

[bobziuchkovski]

Sorry for the slow reply. I was trying to make sense of what was going on.

It's odd to me because the error message for all of the failed integration tests is Invalid length for parameter RoleArn, value: 0, valid min length: 20, which as you pointed out indicates the conditional for and <<parameters.role_session_name>> and <<parameters.role_arn>> was evaluating to true, despite the value itself being an empty string.

That surprises me because the CircleCI docs on logic statements has empty strings being considered falsy.

I added an additional condition to check that the param is explicitly not equal to an empty string to try to resolve this. Unfortunately I'm lacking the referenced CPE_ORBS_AWS and CPE-OIDC contexts on my end to fully reproduce the integration tests, or else I'd try to do so and get everything passing without bugging you with the follow-up tweaks. 😅

I might still try to sort through replicating those contexts on my end, though. I agree that I don't want this change to cause any material issues for anyone else.

[marboledacci]

The role_arn will never be an empty string, because the condition is evaluated before the value is expanded. For the when, role_arn is always ${AWS_ROLE_ARN} not the value on the context, which is evaluated later. That's why this is problematic to implement just like this.

[bobziuchkovski]

The role_arn will never be an empty string, because the condition is evaluated before the value is expanded. For the when, role_arn is always ${AWS_ROLE_ARN} not the value on the context, which is evaluated later. That's why this is problematic to implement just like this.

Ahhh, so it's evaluation timing. Thanks for that clarification!

[bobziuchkovski]

I think the latest commit would technically address this issue.

However, I understand entirely if you'd prefer to forgo this change altogether. I'll admit that this feels a little fiddly at this point. The behavior overall does match the updated description ("If role_arn is set, either explicitly or by the value of $AWS_ROLE_ARN, this command will attempt to use OIDC auth..."), but it's kind of wonky to still attempt to execute the role assumption step and then exit from the script.