写点什么

AWS Organizations 管理众多账号再也不是难题

2019 年 10 月 28 日

AWS Organizations管理众多账号再也不是难题

Organizations 简述

AWS Organizations 可为多个 AWS 账户提供基于策略的管理。借助 AWS Organizations,您可以创建账户组,然后将策略应用于这些组。Organizations 支持您针对多个账户集中管理策略,无需使用自定义脚本和手动操作流程。


使用 AWS Organizations,您可以创建服务控制策略 (SCP),从而集中控制多个 AWS 账户对 AWS 服务的使用。Organizations 支持您通过 包括 API,SDK 和 Console 界面创建新账户。Organizations 还有助于简化多个账户的计费模式,即您可以通过整合账单(Consolidated Billing)为您组织中的所有账户设置一种付费方式。所有 AWS 客户都可以使用 AWS Organizations,且无需额外付费。要注意的是任意的 AWS 账户只能存在一个 Organization 中.



AWS Organizations 关键性概念

在正式接触 AWS Organizations 之前我们必须要先弄清楚其中的关键性名词和概念


Organization – 组织

• 组织是指一系列 AWS 账户,您可以将其整理为一个层次结构并进行集中式管理


AWS account – 账户

• AWS 账户是您 AWS 资源的容器,例如: Amazon S3 存储桶、 Amazon EC2 实例等


• 通过 AWS Identity and Access Management (IAM) 规则 (users, roles) 管理 AWS 资源


• AWS Organizations 中最小的管理单元


Master account – 主账户

• 在组织中为所有账户付款的账户


• 管理您的组织的 Hub(中心)节点


Organizational unit (OU) – 组织单元

• 组织单元是组织内的一组 AWS 账户


• 把 AWS 账户添加到逻辑组中,账号管理更方便


• AWS 账户和组织单元 OU 可以是另外一个组织单元 OU 的成员


• 一个 AWS 账户可以是多个组织单元 OU 的成员


Administrative root – 管理根

• 管理根是整理 AWS 账户的起始点,也是整个组织层次架构中的最顶层的容器。


Organization control policy (OCP) – 组织控制策略

• 含有一个或多个语句的配置,这些语句用于定义您要应用于某组 AWS 账户的控制策略


• 不同应用场景使用不同的组织控制策略


下图可以帮助您更直观的理解这些概念之间的关系:



下面我会更详细的介绍以上提出的这些概念:


Account 加入 Organization 的方式

1. 从 Organization 中创建新账户

  • 新的 AWS 账户只能通过主账户来创建

  • 在创建账户的过程中,您可以配置下面的信息


Ø 电子邮件地址 (必须)

Ø 账户名称 (必须)

Ø IAM 角色名称 (可选 – 默认的名称是 OrganizationAccountAccessRole)

§ 为主账户通过 AssumeRole 方式访问当前账户开启信任权限

§ 权限设置为完全控制

Ø IAM 访问账单 (可选) 。注意! IAM 用户仍然需要相关的 IAM 权限才可以访问账单


  • 新 AWS 账户


Ø 自动成为您组织的一部分

Ø 可以从组织中删除,但是可以通过策略让其没有执行 Leave Organization 的权限


2. 让已有账户加入 Organization

  • 邀请只能通过主账户发起

  • v 被邀请的 AWS 账户可以选择接受或者拒绝邀请


Ø 默认的行为是拒绝

Ø 可以通过 IAM 权限来控制


  • 当邀请被接受


Ø 这个 AWS 账户就成为组织的一个成员

Ø 可应用的 OCP 规则会被自动引用到这个账户


  • 被邀请的 AWS 账户可以被从组织中移除,但是可以通过策略让其没有执行 Leave Organization 的权限


AWS Account 的逻辑组(OU)

• 把 AWS 账户添加到逻辑组中,账号管理更方便


• AWS 账户和组织单元 OU 可以是另外一个组织单元 OU 的成员


• 一个 AWS 账户可以是多个组织单元 OU 的成员


如下图所示:



OCP(Organization Control Policy)


  • 描述要应用的控制策略

  • 不同的使用场景有不同的应用控制策略 OCP

  • 应用控制策略 OCP 可以被附加到


Ø 组织(Organization)

Ø 组织单元(OU)

Ø AWS 账户(Account)


  • OCP 拥有继承属性(AWS 账户, 组织单元 OU, 组织)


Ø Policy 是继承关系的,也就是说 OU 会继承 organization 的 policy,而 AWS Account 会继承 OU 的 policy

Ø Account 的 policy 会跟随其移动,如果这个 Account 从一个 OU 移动到另一个 OU,那么属于这个 Account 的 Policy 也会移动。但是它不会再接收之前 OU 的 Policy,而是会接收新 OU 的 Policy


OCP support in V1:Service Control Policies(SCPs)

  • 允许您对 AWS 服务 API 进行访问控制


Ø 定义一个允许访问的 API 列表 – 白名单

Ø 定义一个禁止访问的 API 列表 – 黑名单


  • 服务控制策略无法被本地管理员覆盖

  • 对于 IAM 用户和角色,最终生效的权限是服务控制策略和相关的 IAM 权限的交集

  • 必要但不充分,本地用户拥有某行为权限,必须要同时拥有 SCP 权限和 IAM 权限

  • IAM 规则模拟器对 SCP 有感知

  • SCP 的控制权限大于本地 administrator 的权限


下图是使用白名单和使用黑名单写 SCP 的案例:



SCP 使用的是 IAM policy 的语法,和 IAM Policy 一样,但是有以下两点不同


• Resource 必须是”*”


• 没有 condition


一定注意,允许最终用户行为的话,必须要 SCP 和 IAM Permission 同时拥有。下图所示,如果在 SCP 允许 S3 和 EC2,但是在 IAM Permission 允许 EC2 和 SQS。那么最终用户只能拥有 EC2 的权限



简单化的账单管理

• 单个付款账户为所有账户付款


• 组织内所有的 AWS 账户的资源被核算到统一的账单中并应用相关的阶梯价


• 所有已存在的整合账单家族将会被迁移到组织的账单模式中


Organization 不同的管理级别

您可以在创建新组织的时候选择不同的管理级别


账单模式(Billing mode)

• 和当前的整合账单模式向下兼容 (CB)


• 从整合账单家族中创建的的组织自动被设置为账单模式


完全控制模式(Full-control mode)

• 账单模式中的所有功能


• 开启所有类型的 OCP 管理功能


• 从账单模式转换成完全控制模式需要得到组织中所有 AWS 账户同意


动手利用 AWS Organizations 来管理您的组织

下面我就给大家演示一下,使用 AWS Organizations 服务如何能做到快速,方便,准确的来管理您的多个账户


进入 AWS Organizations 服务

进入 AWS Organizations 服务的方式,可以通过在 service 上搜索的方式进入,或者通过在 Account 菜单下点击 My Organization 进入。在 Service 的下拉菜单中没有这项服务。


服务栏搜索:



账号栏下拉:



创建新的 Organization


在 AWS Organizations 服务界面上选择创建组织,选择希望创建的组织的种类,这里我演示时选择 Full Control 模式,如果希望仅进行账单整合(Consolidated Billing),那么选择右边的“Enable Only Consolidated Billing”。无论是哪种模式,账单都会是整合的。区别只在于 Master Account 能不能对加入的账号进行控制



注意:现在 Consolidated Billing 功能已经迁移到 AWS Organization 下了,如果点击主账号下的 My Account-> Consolidated Billing,可以看到该提示,并且点击 View Linked accounts 也是直接就会跳转到 AWS Organization 界面



创建完毕之后,会出现组织架构管理界面,前面带星号的账号就是 Master Account



添加新 Account 到 Organization 下

在创建完 Organization 之后,添加账号到 Organization 下有两种方式


• 直接添加账户


• 邀请其他账户加入



1. 直接添加账户(Account)


填写你希望添加的账号的全名和邮箱,并分配一个 IAM Role,这个 IAM Role 是用来给予这个新 Account 一个 full administrative control 的权限



大约等待几秒钟,Account 即可创建。对比如果是要自己在 AWS 网页创建账号,速度上提升了非常多。不过创建时没有设置密码,需要用户登录时在控制台点击忘记密码来重置。



在 Global 根账号控制台登录新创建的账号,因为不知道密码,所以需要点击忘记密码来重置。随后会在注册邮箱收到重置密码的链接,点击重置密码之后,重新登录即可




登录账户之后,可以看到这个新账号已经可以工作,并且 Consolidated Billing 功能是默认开启的。并指示该账户已经在一个 Organization 下了。



2. 邀请其他账户(Account)加入

点击 Invite account 来邀请其他账号加入,添加账号号码或者邮箱,并点击邀请即可



在界面右侧,点击 Invitations 可以看到已经邀请的账号的信息



此时在被邀请的账号的注册邮箱中会收到来自 Master Account 的邀请邮件,如果希望接受这个邀请加入 Organization。那么可以选择点击邮件中的链接或者直接进入自己账号下的 Organization 界面接受也可以。




在 Invitation 界面中可以看见 Organization 的 ID,邀请人的 Account 以及申请控制的类型,最后还有申请加入时的留言(Notes)



最后回到主账号下,可以看见包括 Master Account,主动创建的 Account 以及受邀请加入的 Account 的信息



从 Organization 删除 Account

有两种方式可以从 Organization 下面删除加入的 Account:


  1. Master Account 主动从 Organization 删除 Account,点击单个或多个 Account,点击删除即可



  1. 加入 Organization 的 Account 脱离 Organization,在该 Account 下选择 My Organization,可以看见其加入的 Organization 信息以及选择离开该 Organization



利用 OU(Organization Unit)来管理多个 Account

开始时 Organization 下是没有任何 OU 的,需要用户自己手动去添加。每一级 OU 又可以添加自己下一级的 OU,从而形成一个树状结构



你可以创建一个多级 OU 组织,包括一个根 OU,两个一级 OU 和两个二级 OU



所有的 Account 默认都在根 OU 下,你可以选择一个或者多个 Account,并把他们移动到任意 OU 下。目前只能移动 Account 到 OU,不能从 OU 主动加 Account



针对不同的 OU 可以开启不同的 Policy 来控 OU 下面的 Account,不过要开启这个 feature,必须首先在 Root OU 下启动这个功能



利用 Policy(Service Control Policy)来管理 Account 的行为

在使用 Policy 开管理 Account 时,始终记住两个原则:


1. Policy 是继承关系,并且可以随 Account 移动

• Policy 是继承关系的,也就是说 OU 会继承 organization 的 policy,而 AWS Account 会继承 OU 的 policy


• Account 的 Policy 会跟随其移动,如果这个 Account 从一个 OU 移动到另一个 OU,那么属于这个 Account 的 Policy 也会移动。但是它不会再接收之前 OU 的 Policy,而是会接收新 OU 的 Policy


2. 最终 Account 下的 User 的行为是 SCP 和 IAM Permission 共同决定的

一定注意,允许最终用户行为的话,必须要 SCP 和 IAM Permission 同时拥有。下图所示,如果在 SCP 允许 S3 和 EC2,但是在 IAM Permission 允许 EC2 和 SQS。那么最终用户只能拥有 EC2 的权限



Service Control Policy 在 Policies 下面可以进行设置,默认情况就有一个什么权限都有的 FullAWSAccess Policy 并且是 attach 到 Root OU 的。这也就意味着默认情况下,只有有 Account 加入这个 Organization,那么这个 Account 就拥有操作所有 AWS 服务的权限。如果希望修改 SCP,那么可以点击右侧的 Policy editor 进行修改



SCP 的格式和 IAM Policy 格式一致,但有下面两点不同。在修改完或创建完 Policy 之后,可以 attach 给任何 OU 或 Account


• Resource 必须是”*”


• 没有 condition


点击 Policies 界面下左上角的 Create Policy 可以从头创建一个 SCP,你既可以选择使用 Policy generator 帮助你生成一个新的 SCP,也可以从你已经创建的一个 SCP 中进行复制。在创建时,你可以选择白名单模式或者黑名单模式



这里我选择白名单模式,创建一个名为“SCP_Allow_access_VPC_subnet”的 SCP,仅允许 Account 创建和查看 VPC 和 Subnet,其余动作都禁止



将创建的 SCP 分配给 OU,进而这个 SCP 会传递给下面添加的 Account



在 SCP 配置界面下,将原来的 FullAWSAccess 策略解除,添加新创建的“SCP_Allow_access_VPC_subnet”策略。这个时候问题就来了,因为这个 Account 会继承所在 OU 的 SCP,而所在 OU 又会继承上层 OU 的 SCP。所以其实目前来说,这个 Phoenix Yao 的 Account 是会拥有两个 SCP,包括拥有所有权限的“FullAWSAccess”和限制权限的“SCP_Allow_access_VPC_subnet”



在这种情况下会怎么样呢?其实和 IAM Policy 一样,SCP 只会允许最小权限,所以当你用 Phoenix Yao 账号打开 VPC 界面时,会发现你无法查看除了 VPC 和 Subnet 的任何信息。另外,注意一下,这个 Policy 生效有时候需要一些时间,不是马上能看到结果。



我们再来看下 IAM policy 和 SCP 一起作用的结果。使用 Phoenix Yao 这个 root 账号创建一个 User,并赋予其除了查看 Subnet 其余动作都可以做的 IAM Policy。



将这个 Policy 绑定到新创建的 IAM User 的 IAM Permission 中



将 SCP 恢复成“FullAWSAccess”以单独测试 IAM Permission 是否生效,发现已经生效。



最后将 SCP 和 IAM Permission 一起使用。得到的结果应该是取最小权限,即只能查看 VPC 的情况



使用 AWS Organizations 时的最佳实践

下面介绍一些在使用 AWS Organizations 服务时的最佳实践:



    给予 Organization 最小权限

    • 对所有 AWS 组织行为设置相对应的 IAM 权限


    • 您也可以把 AWS 组织相关的元素(组织,组织单元,AWS 账户)作为 IAM 规则的资源进行管理


    • 您可以把管理您组织的权限通过 IAM role 功能委托给一个在其他 AWS 账号中的 IAM 用户


    • 所有的组织管理行为可以通过 AWS CloudTrail 服务记录


    作者介绍:


    姚远


    姚远,AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广。现致力于网络和DevOps相关领域的研究。在加入AWS之前,在思科中国担任系统工程师,负责方案咨询和架构设计,在企业私有云和基础网络方面有丰富经验。
    复制代码


    本文转载自 AWS 技术博客。


    原文链接:https://amazonaws-china.com/cn/blogs/china/aws-organizations-manage-account/


    2019 年 10 月 28 日 08:00281

    欲了解 AWS 的更多信息,请访问【AWS 技术专区】

    评论

    发布
    暂无评论
    发现更多内容

    架构师训练营第六周作业

    zamkai

    面试软件测试所需要掌握的7个技能

    华为云开发者社区

    sql 面试 测试

    999页阿里P7Java学习笔记在互联网上火了,完整版开放下载

    Crud的程序员

    Java java程序员

    Spring Cloud Gateway (六) 自定义 Global Filter

    Java 网关 SpringcloudGateway

    如何利用状态同步开发一款游戏

    Isa 婷婷

    node.js 游戏开发 24小时自助游戏厅 联机游戏

    腾讯 TcaplusDB 核心引擎技术揭秘——存储篇

    TcaplusDB

    数据库 nosql

    light-rtc: 理念与实践

    阿里云视频云

    架构 音视频 WebRTC RTC

    移动设备管理平台的搭建(基于STF/ATXServer2)

    行者AI

    人工智能

    软件测试--前后端数据交互

    测试人生路

    软件测试

    优化了MYSQL大量写入问题,老板奖励了1000块给我

    华为云开发者社区

    MySQL sql 写入

    引起故障的原因

    jorden wang

    Flink 双流 Join 的3种操作示例

    Apache Flink

    flink 流计算

    腾讯TcaplusDB核心引擎技术揭秘——存储篇

    TcaplusDB

    数据库 nosql 原理

    2021 第一份唠嗑

    大头虾

    40亿条/秒!Flink流批一体在阿里双11首次落地的背后

    Apache Flink

    flink 流计算

    打造新一代企业数据驱动体系

    DorisDB

    数据库 大数据 数据分析 数字化转型 OLAP

    基于 Flink+Iceberg 构建企业级实时数据湖

    Apache Flink

    大数据 flink 流计算

    Flink SQL 实战:HBase 的结合应用

    Apache Flink

    flink

    深层互联带领自动旅游讲解耳麦进入“非入耳”时代

    DT极客

    免费下载来自阿里巴巴 双11 的《云原生大规模应用落地指南》

    阿里巴巴云原生

    阿里巴巴 阿里云 开发者 云原生 k8s

    主从哨兵集群终于给你说明白了

    moon聊技术

    数据库 redis

    内存分页不就够了?为什么还要分段?还有段页式?

    yes的练级攻略

    操作系统 内存管理

    阿里拆中台?从架构师角度解读中台

    javaba韩老师

    架构 中台战略 TOGAF 中台的前世今生 中台的由来

    基于GaussDB(DWS)的全文检索特性,了解一下?

    华为云开发者社区

    数据库 数据仓库 数据

    字节内部MySQL宝典意外流出!极致经典,堪称数据库的天花板

    比伯

    Java 编程 架构 面试 技术宅

    如何通过 Serverless 轻松识别验证码?

    阿里巴巴云原生

    人工智能 阿里云 Serverless 云原生 数据采集

    2020年不容错过的10本大咖之作 | 你最Pick哪一本?

    博文视点Broadview

    LeetCode题解:264. 丑数 II,三指针,JavaScript,详细注释

    Lee Chen

    算法 LeetCode 前端进阶训练营

    干了三年的Java,你竟然还不会MySQL性能优化

    华为云开发者社区

    Java MySQL sql

    「每日一题」抖音面试题:请阐述vue数据绑定的实现原理

    Java架构师迁哥

    “区块链+有机蔬菜”农产品溯源项目落地

    CECBC区块链专委会

    农业发展 农业

    演讲经验交流会|ArchSummit 上海站

    演讲经验交流会|ArchSummit 上海站

    AWS Organizations管理众多账号再也不是难题-InfoQ