Question

我有以下bash脚本尝试自动承担AWS角色（我显然删除了各种私有设置）：

#! /bin/bash
#
# Dependencies:
#   brew install jq
#
# Execute:
#   source aws-cli-assumerole.sh

unset AWS_SESSION_TOKEN
export AWS_ACCESS_KEY_ID=<user_access_key>
export AWS_SECRET_ACCESS_KEY=<user_secret_key>

temp_role=$(aws sts assume-role \
                    --role-arn "arn:aws:iam::<aws_account_number>:role/<role_name>" \
                    --role-session-name "<some_session_name>")

export AWS_ACCESS_KEY_ID=$(echo $temp_role | jq .Credentials.AccessKeyId)
export AWS_SECRET_ACCESS_KEY=$(echo $temp_role | jq .Credentials.SecretAccessKey)
export AWS_SESSION_TOKEN=$(echo $temp_role | jq .Credentials.SessionToken)

env | grep -i AWS_

我必须使用source执行此脚本，否则如果我使用标准bash或sh，则导出的环境变量在执行此脚本的父shell中不可用。

问题是，即使使用source它也不起作用;我的意思是：环境变量及其正确/更新的值显示在父shell中（如果我执行env | grep AWS_我可以看到正确的值）。

如果我然后尝试使用AWS CLI工具（例如aws s3 ls - 列出我认为该角色的特定帐户中的所有s3存储桶），它将报告该访问密钥无效。

但是，如果我手动复制并粘贴环境变量值并在父shell中重新导出它们（有效地使用已设置的完全相同的值覆盖它们），那么然后 AWS CLI命令会起作用 - 但我不知道为什么。有什么不同？

Answer 1

jq .Blah将返回引用的输出。

所以举个例子 export AWS_ACCESS_KEY_ID=$(echo $temp_role | jq .Credentials.AccessKeyId) 结果"KEY"代替您所需要的只是KEY，这就是您的xargs在评论中有效的原因。

如果对jq使用-r标志，则可以获得所需的结果 export AWS_ACCESS_KEY_ID=$(echo $temp_role | jq -r .Credentials.AccessKeyId)

Answer 2

承担AWS角色的另一种方式：

编写一个自动承担角色的个人资料。

aws configure --profile new-profile set arn:aws:iam::<aws_account_number>:role/<role_name>

要为新配置文件提供凭据，您必须使用以下行之一：

aws configure --profile new-profile set source_profile default
aws configure --profile new-profile set credential_sourceEc2InstanceMetadata
aws configure --profile new-profile set credential_source EcsContainer

我的个人电脑上的第1行是正确的，因为我使用了默认配置文件。当我使用AWS CodeBuild测试代码时，第3行是正确的。新配置文件使用了codepipeline-role的凭据。

之后，您可以使用新的个人资料，例如： aws --profile new-profile s3 ls s3://bucket-in-target-account

文档：https://docs.aws.amazon.com/cli/latest/topic/config-vars.html#using-aws-iam-roles

Env变量不在父shell中持久化

2 个答案: