GarrettBlinkhorn
commented
6 months ago I went ahead and upgraded my "digitickets/cli/aws" to 6.0.1 just to rule out any possible differences there. I can see that the formatting of the script has changed but the fundamental issue described above still persists.
Additionally, I've discovered a new bug in the latest version when making the STS call for temporary creds:
### Get temporary credentials from AWS STS
if ! eval "aws sts assume-role \
--role-arn ${ASSUME_ROLE_ARN} \
${AWS_CLI_EXTERNAL_ID_PARAM:-} \
--role-session-name ${ROLE_SESSION_NAME:-AssumingRole} \
--output json \
--debug
${AWS_CLI_PROFILE_PARAM:-} \
${AWS_CLI_REGION_PARAM:-} \
" \
>"${AWS_STS_JSON}" \
2>"${AWS_STS_ERROR_LOG}"; then
echo '{"error":"The call to AWS to get temporary credentials failed"}' >&2
exit 4
fiThe --debug is missing its \ which causes this command to fail and throw the error message described. Adding the \ locally resolved the issue here, though the core issue described above continues to persist.
rquadling
Versions
Expected Behavior
If I supply both a
profileand anassume_role_arnto the module, then the module should useprofileto retrieve a temporary set of credentials forassume_role_arn, then execute the desiredqueryusing the temporary credentials that were retrieved, not theprofileitself.In my case, I have a
profileconfigured for the account where I store my Terraform state/resources and I want to make a cross-account role assumption toassume_role_arnso that I can use this module to read some data from the target account.In
aws_cli_runner.sh, if the user passes theassume_role_arnthen the script uses theprofileparam alongside theassume_role_arnto retrieve a set of temporary credentials and store them asAWS_ENV_VARS.Problem
The
awscommand which executes theaws_cli_commandsalso includes theAWS_CLI_PROFILE_PARAMifprofileis provided, which it is in this case:This prevents the temporary credentials that were fetched earlier from actually being used, meaning that if both
profileandassume_role_arnare passed, then its not actually possible to use the credentials that were fetched to run theawscommand using theassume_role_arn.Additional Findings
profilethat handles the role assumption itself and pass that newprofilethen the command executes properly. If I pass this newprofilealongside the sameassume_role_arnthen the command executes properly as well, but credentials are being sourced from my local~/.aws/credentialsrather than the temporary ones that were fetched:Desired Outcome
Remediate the above so that when both a
profileand anassume_role_arnare passed, the script uses theprofileto fetch the temporary credentials necessary toassume_role_arnthen uses said credentials to execute thecli_query.In my case, I have data in
Account Athat I would like make read-only for other teams in other accounts. Those teams have unique aws profiles that they use inside of their own accounts. I want to create a ReadOnly role inAccount A, then allow other teams to use this role to read the data inAccount A.I would grant
AssumeRolerights on my ReadOnly role to the unique roles that pertain to each different team's specific profiles, so that they can use this module and those profiles to assume the ReadOnly role and execute the query inAccount A.In this way, I can control Read access to
Account Asimply by adding and removingAssumeRole ARNsto my ReadOnly role policy. Then consuming teams can use our existing IAM role structure and this module to read the relevant data.