Forward container credential variables to the AWS CLI

[AgustinRamiroDiaz]

Fixes #2455.

Under implicit role, the AWS CLI block runs aws with an environment that contains only AWS_DEFAULT_REGION, PATH and HOME — aws-cli.ts builds envVars from scratch and executeFile() sets env rather than merging it. The CLI therefore has no way to discover the role on any platform that exposes it through the environment, and fails with NoCredentials (exit 253).

This forwards the variables the CLI needs for that discovery when, and only when, we fall back to the implicit role:

• AWS_CONTAINER_CREDENTIALS_RELATIVE_URI, AWS_CONTAINER_CREDENTIALS_FULL_URI, AWS_CONTAINER_AUTHORIZATION_TOKEN, AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE — ECS and Fargate task roles
• AWS_ROLE_ARN, AWS_ROLE_SESSION_NAME, AWS_WEB_IDENTITY_TOKEN_FILE — EKS IRSA / Pod Identity

Additional Notes

Why it has not surfaced before. On EC2 the CLI reaches the instance role over IMDS at a fixed link-local address and needs nothing from the environment, which is the deployment shape the feature is documented against. Fargate has no IMDS credential provider, so the scrub is fatal there. The asymmetry is confusing in practice: SDK-based AWS blocks work on the same task role, because they run in-process where the variables are intact — only the CLI blocks fail.

Scope. Deliberately narrow. Only the implicit-role branch is touched, only variables that are already in process.env are forwarded, and nothing is forwarded when explicit credentials are supplied (they take precedence in the chain anyway, but keeping the environment minimal seemed better than relying on that). A variable absent from process.env is not added, so non-container deployments are byte-for-byte unchanged.

Possibly worth a follow-up, not done here: azure-cli.ts and the Google Cloud CLI wrapper go through the same executeFile() and so have the same blind spot for managed identity / workload identity. I have not tested either, so I have left them alone.

Testing Checklist

• I tested the feature thoroughly, including edge cases
• I verified all affected areas still work as expected
• Automated tests were added/updated if necessary
• Changes are backwards compatible with any existing data, otherwise a migration script is provided

Tested on a real ECS Fargate deployment of 0.6.25 (engine as its own service, task role attached, OPS_AWS_ENABLE_IMPLICIT_ROLE=true). Inside the engine container, reproducing the environment the block builds:

$ env -i PATH=$PATH HOME=$HOME AWS_DEFAULT_REGION=us-east-1 \
    aws compute-optimizer get-ec2-instance-recommendations
aws: [ERROR]: An error occurred (NoCredentials): Unable to locate credentials.

$ env -i PATH=/tmp/bin:$PATH HOME=$HOME AWS_DEFAULT_REGION=us-east-1 \
    aws compute-optimizer get-ec2-instance-recommendations
{ "instanceRecommendations": [ { "currentInstanceType": "t3.large", "finding": "OPTIMIZED", ... } ] }

where /tmp/bin/aws is a wrapper that re-exports AWS_CONTAINER_CREDENTIALS_RELATIVE_URI and execs the real binary — the same variable this PR forwards.

Unit tests: two added (forwarding under implicit role; no forwarding with explicit credentials), and the existing cases pin the unchanged behaviour. The suite clears these variables around each test so a developer machine that has them set cannot leak into the assertions. packages/blocks/aws: 176 tests, all passing.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud