Polar 多账号 AWS Organizations 的 Terraform 治理实践：OU 分层、SCP 防护与 IAM 集中化

Polar 多账号 AWS Organizations 的 Terraform 治理实践OU 分层、SCP 防护与 IAM 集中化【免费下载链接】polarPolar — A billing platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/po/polar这篇技术指南以 Polar 开源仓库中的 terraform/organization/README.md 为骨架结合 terraform/organization 下的全部 Terraform 配置源码系统拆解 Polar 如何用单一organizationworkspace 管理整个 AWS Organizations 的 OU 分层、成员账户归位、SCP服务控制策略防护、IAM Identity Center 员工访问分层以及权限边界permission boundary的强制落地。读完本文你将掌握一套可直接借鉴的多账号 AWS 基础设施治理模板包括每条 SCP 的适用层级与生效条件、HCP Terraform 动态凭据的跨账户角色打通方式以及如何用 SCP 把权限边界做成不可被绕过的硬约束。一、Polar 的 AWS Organizations 整体布局Polar 将全部 AWS 账号收纳进一个 AWS Organizations由管理账户management account拥有组织控制面。该账户刻意保持精简只承担组织管理、账单、账户生命周期、委托管理员注册等必须从管理账户执行的任务而不承载任何应用负载。这个边界原则直接体现在 terraform/organization/main.tf 中组织以feature_set ALL创建并通过aws_service_access_principals开启了 account、guardduty、iam、malware-protection.guardduty、sso 五个服务的可信访问trusted access。README 给出的组织树如下AWS Organization ├── Management account: polar ├── Workloads │ ├── Production │ │ └── production │ ├── Sandbox │ │ └── sandbox │ └── Test │ └── test └── Security ├── identity └── securityWorkloads OU承载所有应用工作负载。Production对应公共生产环境Sandbox对应生产级production-class的沙箱环境Test对应预发布/测试环境。Security OU放置两个治理账户——identityIAM Identity Center 委托管理员与securityIAM 根访问与 GuardDuty 委托管理员由 terraform/security 单独管理。在源码层面这套树形结构由 terraform/organization/main.tf 的三个资源构造aws_organizations_organizational_unit.workloads挂在组织根root下aws_organizations_organizational_unit.workload用for_each遍历workload_organizational_unitsproduction/sandbox/test挂在 Workloads 下aws_organizations_account.workload用for_each遍历workload_accounts通过parent_id把每个成员账户放进对应的 OU。值得注意的三个工程细节check块防止跑错账户check management_account断言aws_organizations_organization.current.master_account_id local.management_account.id账号975049931254一旦从非管理账户执行 plan/applyTerraform 会直接报错提示必须从 Polar 管理账户运行main.tf。prevent_destroy双保险组织和每个成员账户都声明了prevent_destroy true从 IaC 层面杜绝误删组织或账户。import块接管存量资源组织本体o-hrbfnn1uf5与三个已存在的成员账户通过import块纳入 Terraform 管理而不是新建main.tf。identity与security账户分别定义在 identity_account.tf 与 security_account.tf 中它们的邮箱通过 variables.tf 中的identity_account_email、security_account_email传入均标记为sensitive true。二、Guardrails分层挂载的 SCP 防护体系README 给出了三条挂载规则本质上是策略分层适用于所有应用账户的 guardrails 挂到WorkloadsOU生产级 guardrails 同时挂到Production与Sandbox测试环境特有的 guardrails 挂到Test。全部 SCP 在 service_control_policies.tf 中以local.service_control_policies的 map 形式集中定义每个策略声明target_ids随后通过aws_organizations_policy.service_controltype SERVICE_CONTROL_POLICY创建、aws_organizations_policy_attachment.service_control用双层for展开成策略 × 目标的组合自动挂载。这种本地数据 自动展开的写法让新增一条 SCP 只需加一个 map 条目。2.1 MemberRootAccess挂在组织根上MemberRootAccess是唯一挂在组织根上的 SCPREADME 明确说明其语义拒绝所有成员账户中基于长期 root 凭据执行的动作同时放行由sts:AssumeRoot创建的任务级特权会话。其实现service_control_policies.tf非常精炼——一条 Deny 语句条件是Condition { ArnLike { aws:PrincipalArn arn:aws:iam::*:root } Null { aws:AssumedRoot true } }只有当主体是 root 且没有aws:AssumedRoot上下文键即不是通过sts:AssumeRoot生成的临时凭证时才生效因此集中式的特权 root 会话不受影响。2.2 WorkloadsBaseline所有工作负载账户的基线挂在WorkloadsOU 上包含两条 Deny 语句service_control_policies.tfDenyLeavingOrganization禁止organizations:LeaveOrganization防止成员账户叛逃出组织DenyDisablingAuditAndSecurityServices锁定 CloudTrail删 trail / 停日志、Config删 recorder / 停 delivery channel、GuardDuty删 detector / 与管理员解绑 / 停止监控成员、Security Hub删除邀请 / 禁用组织管理员 / 禁用服务等审计与安全服务的关闭动作。这条策略与permission_boundary模块内的DenyDisablingSecurityServices语句见 terraform/modules/permission_boundary/main.tf形成SCP 在外、权限边界在内的双层防护。2.3 ProductionClass生产级删除防护同时挂到Production与Sandbox两个 OUservice_control_policies.tf这是生产级 Production Sandbox这一治理理念的直接体现DenyKmsKeyDestruction禁止kms:DisableKey、kms:ScheduleKeyDeletion保护加密密钥不被停用或排期删除DenyStorageAndDatabaseDestruction禁止 S3 删桶、DynamoDB 删表、RDS 删集群/实例、ElastiCache 删集群/复制组、Secrets Manager 删密钥。2.4 TestEnvironment测试环境的成本护栏仅挂在TestOUservice_control_policies.tf禁止一切长期承诺型消费DynamoDB/EC2/ElastiCache/ES/OpenSearch/RDS 的PurchaseReserved*类预留实例购买、EC2 预留实例兑换以及savingsplans:CreateSavingsPlan。测试环境只允许按需使用防止产生无法回收的长期成本。2.5 RestrictRegions区域白名单挂在WorkloadsOU 上service_control_policies.tf将工作负载账户的使用区域限制为us-east-1与us-east-2。实现采用NotAction StringNotEquals对不在白名单清单内的动作若aws:RequestedRegion不是这两个区域则 Deny。注意它放行了budgets、ce成本探索、cloudfront、health、iam、organizations、route53、sts、support等全局性服务——这与 AWS 中这些服务不绑定区域、或必须跨区工作的特性保持一致。区域双区主区 备区的设定与 main.tf 中同时声明us-east-1默认 provider 与us_east_2别名 provider 相互印证。2.6 RequirePermissionsBoundary把权限边界变成硬约束挂在WorkloadsOU 上service_control_policies.tf这是 README 所述权限边界三种强制方式中的第三种也是最外层的一道闸门包含四条 Deny 语句RequireBoundaryOnRoleCreation新建 IAM Role 时若iam:PermissionsBoundary不是PolarPermissionBoundary且主体不在豁免清单内则拒绝创建RequireBoundaryOnUserCreation对新建 IAM User 做同样的强制DenyRemovingPermissionBoundary禁止Put/DeleteRole/UserPermissionsBoundary移除边界豁免主体除外ProtectBoundaryPolicy禁止对该策略本体做CreatePolicyVersion、DeletePolicy、DeletePolicyVersion、SetDefaultPolicyVersion防止边界策略被篡改或删除。豁免主体service_control_policies.tf包括OrganizationAccountAccessRole引导角色、terraform-cloud自动化角色、SSO 的AWSReservedSSO_PolarAdmin*会话角色以及 SSO 服务角色AWSServiceRoleForSSO。三、Terraform Ownership成员账户与 HCP Terraform 自动化README 指出Terraform 管理工作负载 OU 与成员账户归位但管理账户只通过 Organizations data source 校验、不作为aws_organizations_account资源管理——因为该资源管理的是成员账户而非管理账户本身。check management_account正是承担这一校验职责的实现。每个工作负载账户内还会创建一个名为terraform-cloud的 HCP Terraform 运行角色信任 HCP Terraform 的 AWS 动态凭据颁发者并作用域到对应的 workspaceproduction account - polar workspace sandbox account - sandbox workspace test account - test workspace这个映射定义在 terraform_cloud.tf 的local.terraform_cloud.workspaces中。具体创建逻辑分两步五个跨账户 providerproduction、sandbox、test、identity、security五个awsprovider 别名都通过assume_role指向目标账户内的OrganizationAccountAccessRole即 variables.tf 中的member_account_bootstrap_role_name默认值OrganizationAccountAccessRole实现管理账户发起、引导角色承接的跨账户引导模式terraform_cloud.tf五个terraform_cloud_run_role模块调用为每个账户创建terraform-cloud角色注入 HCP Terraform 组织名、项目名、workspace 名与托管策略AdministratorAccess并把对应的跨账户 provider 传入模块terraform_cloud.tf。工作区指向各自 AWS 角色的变量由 terraform/global 管理。也就是说organizationworkspace 负责造角色globalworkspace 负责把每个 workspace 指到角色上两个 root 各司其职。另外terraform.tf 固定了该 root 的后端与版本约束HCP Terraform 组织polar-sh、workspace 名为organizationAWS provider 要求~ 6.61Terraform 版本 1.5。四、Centralized root access集中式根凭据管理README 提到组织已启用 IAM trusted access并同时开启根凭据管理RootCredentialsManagement与特权根会话RootSessions两项能力security账户是这两个特性的委托管理员。对应实现就在 root_access.tfresource aws_iam_organizations_features root_access { enabled_features [RootCredentialsManagement, RootSessions] } resource aws_organizations_delegated_administrator root_access { account_id aws_organizations_account.security.id service_principal iam.amazonaws.com }这里有两个 README 特别强调的运维要点启用根凭据管理不会自动删除既有 root 凭据。需要逐一审计每个成员账户通过由IAMDeleteRootUserCredentialsAWS 托管 root-task 策略作用域的特权会话手动清除管理账户不受集中式根访问覆盖必须保留其独立加固的 root 凭据管理账户根凭据本身就是组织控制面的最后兜底。配合第一小节提到的MemberRootAccessSCP这套机制形成完整闭环日常 root 动作被 Deny紧急操作走sts:AssumeRoot生成的一次性任务级会话事后由安全团队按需回收。五、Staff accessIAM Identity Center 的三级访问体系员工访问统一收敛到 IAM Identity Center。identity_center.tf 定义了三个访问层级access tiers每个层级在每个目标账户下生成一个命名规则为PolarTierAccount的 permission set层级Permission set 命名托管策略是否附加权限边界授权组覆盖账户adminPolarAdminAccountAdministratorAccess否awsadminspolar.sh全部 6 个账户含 management 与 securityengineeringPolarEngineeringAccountPowerUserAccess是PolarPermissionBoundaryawsengineerspolar.sh、engineeringpolar.sh除 identity、security 外的默认账户集read_onlyPolarReadOnlyAccountReadOnlyAccess否awsaccesspolar.sh默认账户集上表中的默认账户集由local.staff_default_accounts setsubtract(keys(...), [identity, security])计算得出——工程师与只读用户不进入identity/security 这两个治理账户进一步缩小敏感面。从源码看这套体系由以下资源协同完成aws_ssoadmin_permission_set.account按account_permission_sets展开创建会话时长固定PT8Hidentity_center.tfaws_ssoadmin_managed_policy_attachment.account为每个 permission set 附加对应 AWS 托管策略identity_center.tf仅 engineering 层级的 permission set 通过aws_ssoadmin_permissions_boundary_attachment.account附加PolarPermissionBoundary客户托管策略identity_center.tf这是权限边界三种强制方式中的第一种aws_ssoadmin_account_assignment.account把每个权限集以GROUP主体形式指派到各目标账户identity_center.tf且depends_on权限边界的各账户模块确保边界先建好再分配权限。README 特别澄清了组成员资格的来源组归属来自 Google Workspace通过 ssosyncterraform/identity同步进 Identity Center不由本 root 管理。identity_center.tf中data aws_identitystore_groups all按显示名AWS Access、AWS Engineers、Engineering、AWS Read Only Access反查组 ID并在本地staff_group_ids中做空值兜底lookup(..., null)——即使某个组尚未同步进来也不会导致 apply 失败而只是跳过对应指派。六、Permission boundary三层强制下的最小特权引擎PolarPermissionBoundary由permission_boundary模块部署到每个账户用以封顶内部角色与用户的有效权限。README 给出了它的三种强制方式PolarEngineering*permission sets 直接附加边界——见上文第五小节创建角色的模块接收permissions_boundary_arn参数使应用角色与 CI 角色自动携带边界terraform-cloud自动化角色除外后者是组织级自动化所必需被显式豁免RequirePermissionsBoundarySCP 挂到WorkloadsOU强制新建角色/用户必须带边界并保护边界不被移除。在部署层面permission_boundary.tf 用同一个模块向 6 个账户management、production、sandbox、test、identity、security各部署一份策略。模块源码terraform/modules/permission_boundary/main.tf值得细读它定义的策略文档包含七类语句语句 Sid效果核心作用AllowAllByDefaultAllow*on*边界内先放行一切再逐条收紧DenyCreatingPrincipalsWithoutBoundaryDeny创建 Role/User 或附加边界时要求边界必须指向本策略DenyManagingRolesWithoutBoundaryDeny修改角色策略/信任策略时同样要求带边界阻断借角色提权DenyAssumingOrPassingNonPolarRolesDeny只允许sts:AssumeRole/iam:PassRole到polar-*命名角色DenyRemovingPermissionBoundaryDeny禁止删除角色/用户的权限边界DenyBoundaryPolicyMutationDeny禁止对边界策略本体做版本变更或删除DenyOrganizationTamperingDeny禁止任何organizations:*动作DenyDisablingSecurityServicesDeny与WorkloadsBaselineSCP 呼应禁止关闭审计与安全服务可以看到边界策略与 SCP 体系的语句高度同构删除审计服务、保护边界策略、防篡改等形成SCP 管组织级、边界管账户内的双保险。RequirePermissionsBoundarySCP 通过ArnNotLike条件要求iam:PermissionsBoundary必须精确等于arn:aws:iam::*:policy/PolarPermissionBoundary这就让第二条与第三条强制方式在组织层收敛为同一个策略名常量local.permission_boundary_policy_name PolarPermissionBoundary。README 还给出一个关键的应用顺序约束organizationworkspace 先在所有账户创建权限边界sandbox/test等引用边界的 workspace 必须在其之后 apply。这也解释了identity_center.tf中aws_ssoadmin_permissions_boundary_attachment与aws_ssoadmin_account_assignment都depends_on五个permission_boundary_*模块的原因——依赖声明把先边界、后授权的时序固化进了 IaC。七、结语一张可复用的多账号治理蓝图回顾整个 terraform/organization rootPolar 的多账号治理可以提炼为四条可迁移的原则OU 分层决定策略作用域Workloads 放基线、ProductionSandbox 放生产级防护、Test 放成本护栏、根上放最全局的 root 访问禁令策略挂载点本身就是环境边界的声明。SCP 只做禁止所有 SCP 都是 Deny 语义防退出组织、防删审计、防删数据、防买预留、防跨区、防绕边界不做正向授权——正向权限完全交给账户内的角色与权限边界。权限边界三层强制SSO 会话附加 角色创建模块注入 SCP 兜底三者叠加让最小特权从约定变成不可绕过的系统约束。自动化角色与人工访问分离terraform-cloud角色走 HCP Terraform 动态凭据并按 workspace 收敛员工走 Identity Center 按组授三类权限两套通道互不混淆。对于正在规划或重构多账号 AWS 架构的团队可以直接对照 service_control_policies.tf 的 map 结构裁剪出适合自己的策略集再借助check块与prevent_destroy为自己加上与 Polar 同款的防呆保护。【免费下载链接】polarPolar — A billing platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/po/polar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考