aws账户 iam用户
My last post compared different infrastructure tools for creating users and letting them assume roles for cross-account access. I received a few questions about the underlying problem that those scripts were trying to solve, so this post delves a bit deeper into the realm of user management.
我的上一篇文章比较了用于创建用户并使他们承担跨帐户访问角色的各种基础结构工具。 我收到了有关这些脚本试图解决的基本问题的一些问题，因此本文将更深入地探讨用户管理领域。
The underlying problem: how do you manage multiple AWS deployments? The typical example is development/qa/production, but developer sandboxes — in which developers have the freedom to experiment with services without fear of impacting anyone else — are perhaps even more relevant. The standard answer to this problem is to create multiple AWS accounts, and with the release of AWS Organizations in 2017 it became much easier to implement: in addition to simplifying billing, Organizations gives the master account more control over the children via Service Control Policies.
潜在问题：如何管理多个AWS部署？ 典型的示例是开发/质量保证/生产，但是开发人员沙箱(其中开发人员可以自由地尝试服务而不必担心会影响其他任何人)可能更有意义。 解决此问题的标准答案是创建多个AWS账户，并且随着2017年发布的AWS Organizations变得更加容易实现：除了简化计费之外，Organizations还通过Service Control Policies为主账户提供了对子账户的更多控制权。
But if you use multiple accounts, how do you manage users in those accounts? One not-very-good answer is to create separate users in each account. This quickly becomes a management nightmare, both for the organization and your users. For the organization, you need to add users to the appropriate accounts, manage their permissions, and remove them if they leave the company; this can be solved with automation. But for users, it’s harder to solve: I’ve watched coworkers cycle through a list of accounts/passwords until they found the right one for the task they were about to do. And inevitably, if you’re working with multiple accounts you end up with an “oops!” where you did something in the wrong account.
但是，如果您使用多个帐户，如何管理这些帐户中的用户？ 一个不太好的答案是在每个帐户中创建单独的用户。 对于组织和用户而言，这很快就成为管理的噩梦。 对于组织，您需要将用户添加到适当的帐户，管理其权限，并在他们离开公司后将其删除； 这可以通过自动化解决。 但是对于用户而言，这更难解决：我已经看到同事在一个帐户/密码列表中循环浏览，直到他们找到适合他们要执行的任务的帐户/密码为止。 不可避免地，如果您使用多个帐户，则结果会很糟糕！ 您在错误的帐户中做了什么。
A better solution is Amazon’s Single Sign-On service, also introduced in 2017. With this service, you can manage a single set of users and grant them varying permissions in different AWS accounts. The users sign in via the SSO portal and select their destination account; they can either get temporary credentials for CLI/SDK access, or be redirected to the AWS Console for that account. In addition, you can use SSO as a portal for web applications such as Office365 or your own SAML-based applications. And you can use a corporate Active Directory server as the user database, which is something that larger organizations will like (disclosure: I haven’t configured AD integration, so can’t say how easy or difficult it is).
更好的解决方案是于2017 年推出的Amazon Single Sign-On服务。使用此服务，您可以管理一组用户，并在不同的AWS账户中向他们授予不同的权限。 用户通过SSO门户登录并选择其目标帐户； 他们可以获取用于CLI / SDK访问的临时凭证，也可以重定向到该帐户的AWS控制台。 此外，您可以将SSO用作Web应用程序(如Office365)或您自己的基于SAML的应用程序的门户。 而且，您可以使用企业Active Directory服务器作为用户数据库，大型组织会喜欢这种数据库(公开：我尚未配置AD集成，因此无法说它的难易程度)。
When I first wrote this post, I pointed out that SSO did not support TOTP for multi-factor authentication. This changed in October 2019, and you can now use any MFA token provider with SSO that you could use with IAM. However, my second concern remains: SSO is not scriptable (at least as-of this writing) via either CloudFormation or Terraform. So you have to enter your users and configure their permissions manually. And SSO “permission sets” translate directly to IAM roles, so you’ll end up with a mix of scripted and unscripted roles, losing the benefit of source-control for your infrastructure.
当我第一次写这篇文章时，我指出SSO不支持TOTP进行多因素身份验证。 这种情况在2019年10月发生了变化，现在您可以将可以与IAM一起使用的任何MFA令牌提供商与SSO一起使用。 但是，我的第二个问题仍然是：SSO不能通过CloudFormation或Terraform编写脚本(至少在撰写本文时)。 因此，您必须输入用户并手动配置其权限。 SSO“权限集”直接转换为IAM角色，因此您最终将混合使用脚本化和非脚本化角色，从而失去基础结构源代码控制的好处。
With all that said, I still think that SSO is a good choice for many organizations. But I prefer the following architecture, in which all users are defined in the organization’s master account, and have the ability to assume roles in the child accounts (note: each account has a made-up account ID that’s used in subsequent examples):
综上所述，我仍然认为SSO是许多组织的不错选择。 但是我更喜欢以下架构，在该架构中，所有用户都在组织的主帐户中定义，并且能够在子帐户中扮演角色(请注意：每个帐户都有一个在后续示例中使用的虚构帐户ID)：
Let’s start by looking at roles. The sandbox account might have only a single role, SandboxUser, which grants administrator access. By comparison, the production account might have multiple roles, granting different levels of access to different sets of resources. For example, you could define a FooMonitoring role that (among other things) grants permission to describe EC2 instances that have an Application tag with the value Foo.
让我们从角色开始。 沙箱帐户可能只有一个角色SandboxUser ，它授予管理员访问权限。 相比之下，生产帐户可能具有多个角色，从而授予对不同资源集的不同级别的访问权限。 例如，您可以定义一个FooMonitoring角色，该角色(除其他事项外)授予权限来描述具有Application标记且值为Foo EC2实例。
The one thing that all roles will have in common is a trust relationship that allows them to be assumed by users in the master account:
所有角色的共同点是，信任关系使主帐户中的用户可以承担这些角色：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::012345678901:root"
},
"Action": "sts:AssumeRole"
}
]
}This trust relationship means the role can be assumed by any user in the organizational master account who is allowed the sts:AssumeRole action. This privilege is granted via policies in the master account, and in keeping with AWS best practice, those policies should be attached to groups rather than individual users.
这种信任关系意味着该角色可由允许sts:AssumeRole操作的组织主帐户中的任何用户承担。 该特权是通过主账户中的策略授予的，并且与AWS最佳实践一致，这些策略应附加到组而不是单个用户。
As a concrete example, let’s assume that we have an application named Alfie (I’m getting tired of Foo and Bar). The developers who work on that application should have different levels of access to the resources used by that application depending on environment: full access in development, access for deployments in QA, and read-only access in production. Each level of access will require a role in the relevant account; the specifics of these roles are beyond the scope of this post.
举一个具体的例子，假设我们有一个名为Alfie的应用程序(我对Foo和Bar感到厌倦)。 处理该应用程序的开发人员应根据环境对该应用程序使用的资源具有不同级别的访问权限：开发中的完全访问权限，QA中的部署访问权限以及生产中的只读访问权限。 每个访问级别都将在相关帐户中扮演一个角色； 这些角色的细节超出了本文的范围。
After creating the roles, we’d then create an alfie-developers group in the master account, assign the developers to that group, and give it a permissions policy that looks like the following:
创建角色后，我们将在主帐户中创建一个alfie-developers组，将开发人员分配给该组，并为其提供一个权限策略，如下所示：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::123456789012:role/AlfieReadOnly",
"arn:aws:iam::234567890123:role/AlfieDeployment",
"arn:aws:iam::345678901234:role/AlfieFullAccess"
]
}
]
}All well and good, but how do your users work in this environment?
一切顺利，但是您的用户如何在这种环境下工作？
As long as you stick with the AWS Console, it’s easy to switch roles.
只要您坚持使用AWS控制台，就可以轻松切换角色 。
From the command line it’s a little more difficult. The simplest option is to update your AWS configuration files, stored in $HOME/.aws. There are two files, credentials and config, and while in practice you can specify assumable roles in either, the docs are very explicit that the former is only for actual credentials. Assuming that you ran aws configure, it will look like this:
从命令行开始要困难一些。 最简单的选项是更新存储在$HOME/.aws AWS配置文件 。 有两个文件， credentials和config ，虽然在实践中您可以在两个文件中指定可能的角色，但是文档非常明确，前者仅用于实际凭证。 假设您运行了aws configure ，它将如下所示：
[default]
aws_access_key_id = AKIAEXAMPLEXXXXXXXXX
aws_secret_access_key = EXAMPLExxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxIn the second file, config, you can specify multiple profiles (you also have a default profile in this file, where you can specify your default region):
在第二个文件config ，您可以指定多个配置文件(此文件中还有一个默认配置文件，您可以在其中指定默认区域)：
[default]
region = us-east-1
[profile alfie-development]
role_arn = arn:aws:iam::345678901234:role/AlfieFullAccess
source_profile = default
[profile alfie-qa]
role_arn = arn:aws:iam::234567890123:role/AlfieDeployment
source_profile = default
[profile alfie-production]
role_arn = arn:aws:iam::123456789012:role/AlfieReadOnly
source_profile = defaultWith these profiles configured, you can use the --profile command-line parameter to specify which role you want to assume for a particular action:
配置了这些概要文件后，可以使用--profile命令行参数来指定您要为特定操作承担的角色：
aws s3 ls --profile alfie-developmentThis is somewhat onerous, and it isn’t available for programs that you write. As an alternative, you can use the AWS_PROFILE environment variable to configure your profile:
这有点麻烦，并且不适用于您编写的程序。 或者，您可以使用AWS_PROFILE环境变量来配置您的配置文件：
export AWS_PROFILE=alfie-developmentaws s3 lsThere is one final caveat: an assumed role has a limited duration, by default one hour. With the commend line tools and a configured profile, you should never run into this, because each invocation assumes its own role. But in the Console, you may get an “access denied” error, or a popup message telling you to reload. Doing so will refresh your role and you can keep going for another hour.
最后一个警告：假定角色的时限有限，默认为一小时。 使用推荐的命令行工具和配置的概要文件，您永远都不会遇到这种情况，因为每个调用都承担自己的角色。 但是在控制台中，您可能会收到“访问被拒绝”错误或弹出消息，提示您重新加载。 这样做会刷新您的角色，您可以再继续工作一个小时。
To wrap up: you may consider switching roles to be a lot of work. But in practice, developers get used to doing it in short order, and prefer not having to juggle credentials. And a more important benefit is that you can then introduce special roles for destructive operations, such as shutting down an RDS instance.
总结：您可能会认为切换角色需要很多工作。 但是在实践中，开发人员习惯于短时间执行此操作，并且宁愿不必摆弄凭据。 而且，更重要的好处是您可以为破坏性操作引入特殊角色，例如关闭RDS实例。
This post was originally written for the Chariot Solutions Blog by Keith Gregory, Chariot’s AWS Practice Lead. You can read the original post here.
这篇文章最初是 由 Chariot的AWS实践主管 Keith Gregory 为 Chariot解决方案博客 撰写的 。 您可以在 此处 阅读 原始帖子 。
Starting an AWS project? Chariot Solutions is a certified Consulting Partner for AWS. You can count on us for professional services that help you map out the most efficient route to cloud adoption, modernization, app development and deployment, IoT, machine learning, data and analytics. Read more about our AWS offerings at Chariot, or contact us to see how we can help with your project.
开始一个AWS项目吗？ Chariot Solutions是AWS的认证咨询合作伙伴。 您可以依靠我们提供的专业服务，这些服务可以帮助您规划出最有效的方法来实现云采用，现代化，应用程序开发和部署，物联网，机器学习，数据和分析。 在Chariot上 了解 有关我们的AWS产品的 更多 信息，或 与我们联系 以了解我们如何为您的项目提供帮助。
翻译自: https://medium.com/swlh/managing-aws-users-and-roles-in-a-multi-account-organization-1d82666b252
aws账户 iam用户