临时安全凭证 - 如何在给定角色名称和 AWS 账户 ID 的情况下获得访问权限？答案

【问题标题】：Temporary Security Credentials - How to get access, given a role name & AWS account id?临时安全凭证 - 如何在给定角色名称和 AWS 账户 ID 的情况下获得访问权限？
【发布时间】：2020-03-05 16:11:57
【问题描述】：

AWS 文档提供了多种方法，here。

在我们的环境中，我们有多个 AWS 账户。

使用场景是在 AWS 账户之间切换并从笔记本电脑运行 AWS cli 命令，作为自动化的一部分。

在特定 AWS 账户上运行 AWS cli 命令之前，我们需要获取该账户的临时凭证，给定账户 ID。

访问（通过切换）多个 AWS 账户有助于我们实现自动化。

基本上我们想运行一些像./some_aws_sdk_tool.py role_name aws_account_name 这样的工具，假设role_name 来获取凭据。

我想用我的单个 AWS 账户（个人）对此进行测试。

1) 配置我的 AWS 账户以创建此类 role_name 的步骤是什么？

2) 使用some_aws_sdk_tool.py 获取特定aws_account_name 的临时凭证的方法是什么？能够运行 AWS CLI 命令 n 分钟..

【问题讨论】：

您可以在一个主账户中拥有一组凭证，而您在其他账户中拥有 IAM 角色。您授予主账户中的 IAM 委托人在其他账户中担任相关 IAM 角色的权限。该过程为您提供了具有在其他帐户中操作所需权限的临时凭据。
@jarmod 的声明是正确的做法。

标签： amazon-web-services aws-sdk aws-cli

【解决方案1】：

您想在您的代码中还是使用 AWS CLI 执行此操作？

如果您使用 CLI，最简单的方法是在您的 AWS 凭证文件中创建配置文件，如 here 所述。每个配置文件都标识一个角色 ARN 和允许担任该角色的源登录信息。

或者，您可以运行sts assume-role 命令，解析结果并设置环境变量：

aws sts assume-role --role-arn 'arn:aws:iam::123456789012:role/Example' --role-session-name 'some_unique_but_relevant_string'

{
    "Credentials": {
        "AccessKeyId": "ASIAXXXXXXXXXXXXXXXX",
        "SecretAccessKey": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
        "SessionToken": "XXXXXXXXXXXXXXX//////////XXX...XXXXX",
        "Expiration": "2020-03-05T20:57:45Z"
    },
    "AssumedRoleUser": {
        "AssumedRoleId": "AROAXXXXXXXXXXXXXXXXX:some_unique_but_relevant_string",
        "Arn": "arn:aws:sts::123456789012:assumed-role/Example/some_unique_but_relevant_string"
    }
}

如果您想在程序中执行此操作，可以使用如下代码：

sts_client = boto3.client('sts')

role_arn = "..."
session_name = "some_unique_but_relevant_value"

response = sts_client.assume_role(
    RoleArn=role_arn,
    RoleSessionName=session_name
)
creds = response['Credentials']

actual_client = boto3.client('SERVICE',
    aws_access_key_id=creds['AccessKeyId']
    aws_secret_access_key=creds['SecretAccessKey']
    aws_session_token=creds['SessionToken'])

【讨论】：

AWS CLI 或 SDK 都适合我。两者都将允许自动化
这个角色arn:aws:iam::123456789012:role/Example 看起来如何，就策略（访问）而言？因为这个角色应该允许读取/写入该 aws 帐户中的每个资源？
@overexchange - 这是你想要允许的任何东西。如果您想要完全访问权限，您可以附加 AdministratorAccess 托管策略。更重要的是您允许谁担任该角色，这通常是该角色的信任策略和附加到父帐户中的用户/角色的 sts:AssumeRole 策略的组合。

【解决方案2】：

这是不可能的。您只能在第一次创建密钥时看到它，AWS 永远不会再向您显示它。 See more here.

Okta 等一些 Identity Manager 允许您在 CLI 上担任角色，因此您不必直接处理凭据。您只需为用户分配一个角色，他将能够在第一次登录后直接担任该角色。

【讨论】：

在我以前的公司，我使用 boto aws sdk python 工具（他们写的）来检索和存储~/.aws/credentials 中的访问密钥，我们做了类似的事情：./get_aws_key.py account_name。 AWS 中的所有设置都是通过 okta 访问的。作为用户，我们为每个 AWS 账户设置了两个角色（只读和 rw）。
所以您不是从 AWS 检索密钥，而是从其他来源检索密钥。无论如何，这不是一个好习惯。
1) 我们如何自动执行访问多个 AWS 账户以跨账户运行 AWS CLI 命令的过程？因为我们在运行 AWS CLI 之前需要凭证......不管使用 okta 等工具。 2) 为什么这不是一个好习惯？
1) 每个用户都应对自己的一组凭据负责。您无需授予用户对资源的权限，但可以告诉他们可以承担哪些角色。因此，他只需将角色 arn 添加到本地 aws cli 配置中，他就可以在调用 CLI 时担任该角色。您可以在 AWS IAM 上拥有该用户，也可以使用 okta 之类的身份管理器。 2）因为您不应该将敏感信息捆绑在一起。