多云身份管控平台构建——第一篇 基于 RBAC&ABAC 实现 Auth0 与亚马逊云控制台的权限集成

{"value":"越来越多的企业在迁移上云旅程中都会面临多云的选择。不管是出于主动原因希望融合多云的服务优势，还是出于被动原因需要适应公司的业务并购，抑或是因为上云过程中需要实现混合云架构的打通，构建多云的统一身份权限管控平台往往是这些企业需要解决的问题。\n\n构建这一平台，不仅要实现单点登录，还要考虑统一身份管控、统一权限管控和云上用户行为审计；并且企业内人员的多组织管理模型通常与云上基于角色的 IAM 管理模型存在较大差异，这进一步增加了构建跨云身份管理平台的难度。\n\n本博客从企业客户的实际需求和技术难点出发，分别阐述了使用\n\n- RBAC — 基于角色的权限管控\n- ABAC — 基于属性的权限管控\n- 动态策略生成 \n\n这三种思路实现企业统一身份管控平台，并与公有云控制台 (Web console) 实现身份和权限的打通；以及三种思路各自的适用场景；并在此基础上给出了基于 Auth0 构建该平台，完成与亚马逊云控制台集成，实现统一登录与授权的具体实现代码样例。\n\n受篇幅所限，我们把博客分成两部分，本篇讲述 RBAC 和 ABAC 的实现方法；第二篇讲述动态策略生成的实现方法。\n\n[多云身份管控平台构建——第二篇 基于动态策略实现Auth0与亚马逊云控制台的权限集成](https://aws.amazon.com/cn/blogs/china/construction-of-multi-cloud-identity-management-and-control-platform-the-first-article-realizes-the-permission-integration-of-auth0-and-amazon-cloud-console-based-on-rbac-abac/)\n\n\n#### **1.统一身份管控平台概述**\n\n\n##### **1.1 构建需求**\n\n下图展示了一个实际案例中企业对统一身份管控平台的需求：\n\n\n\n1. 企业构建统一的身份、权限管控平台，并提供唯一入口对外访问\n2. 用户访问统一身份管控平台时，自动跳转至企业 iDaaS 系统，完成身份认证\n3. 认证成功后，进入企业的权限管理系统，获取相应的权限信息\n4. 用户选择需要登录的公有云链接，携带用户及权限信息，实现对公有云控制台的无缝跳转和权限控制。\n\n\n##### **1.2 技术挑战**\n\n\n企业的 iDaaS 系统通常会采用人员的多组织关系模型。如下图左半部分所述的企业实际场景：\n\n- 企业员工可以同时归属到多个项目，并在项目中担任不同角色\n- 同一个员工在不同项目中可以担任不同角色。如在 Project1 中担任 Manager，负责 iDaaS 系统中用户创建和权限分配；在 Project2 中担任 Owner，负责公有云资源的创建和管理；在 Project3 中担任 Readonly 角色，对公有云资源具有只读权限。\n\n下图右半部分以 Amazon IAM 为例简要展示了公有云的 IAM 权限管理模型：IAM 通过 policy 控制对云资源可以实施的动作，并通过条件对资源、行为主体、请求类型等进行细粒度限制；然后将 policy 挂接到 Role 上实现权限与行为主体的映射。\n\n可以看到，公有云的 IAM 管理模型虽然具有用户、组和角色的划分，但账号内通常不会支持多级人员管理；而且 SSO 一般是通过 IDP 的用户属性到公有云 IAM 角色的映射实现权限打通，如何使用扁平的角色管理模型实现多组织层级的资源权限管控是当前面临的主要技术难点。\n\n\n\n\n#### **2. 思路一：基于角色的权限管理模型 RBAC**\n\n\n##### **2.1 方案概述**\n\n\n基于 RBAC 的方案是对企业 iDaaS 中的每一个项目 x 角色的组合在云中都对应一个指定的 role。因此云中 IAM 角色的数量将与企业 iDaaS 中项目 x 角色的数量相等。如下图，使用 RBAC，就是对企业中的每个项目都在 Amazon IAM 中创建三个角色（Manager，Owner，Readonly），并为每个角色维护单独的权限策略。该方案的特点是通过静态角色完成设置，实现方法简单直接，非常适合项目和角色数量有限的场景；但随着项目和角色数量的增加，维护众多的的权限策略将逐渐成为噩梦。并且每账户的 IAM 角色数量通常具有上限，例如亚马逊云的目前上限为每账户允许创建最多5000个角色.\n\n\n\n\n##### **2.2 基于 SAML2.0 的 Auth0 与亚马逊云控制台权限集成**\n\n\n亚马逊云提供了 Cognito 用于支持数百万用户规模的管理、以及与第三方社交身份提供商的联合认证，并提供多种方式帮助用户从应用来控制对亚马逊云资源的访问，有关 Cognitor 的文档和博客已经非常丰富。本博客从通用方案的角度出发，选择了第三方产品 Auth0 来演示如何通过 SAML2.0 与亚马逊云控制台实现统一身份权限管理。本文对 Auth0 与 Amazon IAM 间如何交换 SAML Metadata 构建信任关系不再赘述，重点讨论如何建立 Auth0 的用户与 IAM 角色的映射关系：\n\n- 首先，确定 Auth0 的用户如何与 IAM 角色实现映射：\n在 RBAC 中我们使用用户所属项目以及在项目中担任的角色这两个组合属性来与 IAM 角色进行映射。\n- 然后：扩展 Auth0 的用户属性：\n缺省状态下，Auth0 用户不具备项目、角色等属性，但提供了 user_metadata 属性实现对用户定义的灵活扩展，演示中我们对该用户添加 project、role 这两个属性如下图：\n\n\n\n- 其次：在 Auth0 中创建 Rule，构建 Auth0 用户属性与 IAM 角色的映射关系\n\n\n\n创建客户化的规则（上图中 sharonTest）用于实现 Auth0 的属性与 IAM role 的映射，如下 Javascript 代码示例：\n\n```\\n\\tfunction (user, context, callback) {\\nvar awsRoles = {\\n'project1-readonly': 'arn:aws:iam::{{ACCOUNTID}}:role/auth0saml,arn:aws:iam::{{ACCOUNTID}}:saml-provider/auth0saml',// Amazon中创建的基于SAML2.0联合认证的角色，用于控制project1-manager对资源的访问\\n'project2-manager': 'arn:aws:iam::{{ACCOUNTID}}:role/auth0saml-readonly,arn:aws:iam::{{ACCOUNTID}}:saml-provider/auth0saml' // Amazon中创建的基于SAML2.0联合认证的角色，用于控制project2-readonly对资源的访问\\n};\\n\\nvar userattribute = user.user_metadata.project+'-'+user.user_metadata.access_role;\\nuser.awsRole = awsRoles[userattribute]; // 根据用户当前所在的groups属性从awsRoles中匹配对应的角色\\nuser.awsRoleSession = user.name;\\n\\ncontext.samlConfiguration.mappings = { 'https://aws.amazon.com/SAML/Attributes/Role': 'awsRole',\\n'https://aws.amazon.com/SAML/Attributes/RoleSessionName': 'awsRoleSession'\\n};\\n callback(null, user, context);\\n}\\n```\n\n- 最后，登录 Auth0 提供的 IDP URL，身份认证通过后即可跳转到亚马逊云控制台界面\n\n如下，为在 Auth0 中构建的基于 0 的 application 提供的 IDP Login URL\n\n\n\n输入用户名密码，在 Auth0 完成身份验证后，自动跳转至亚马逊云控制台。\n\n从以上实践可以看到，采用 RBAC 的权限管理模型，关键是如何实现 IDP 中的用户属性与 IAM 角色的映射。集成起来简单快速，适合匹配角色数量较少的场景使用。\n\n\n#### **3. 思路二：基于属性的权限管理模型 ABAC**\n\n\n##### **3.1 方案概述**\n\n\n在某些场景，每个项目所使用的资源类型都是相同的，只是不同项目对应不同的资源实例。比如所有项目都只能使用 EC2和 RDS 服务，只是每个项目使用不同的服务实例。对这类同质的项目，就非常适合使用基于 ABAC 的权限管理模型，通过设定资源的 Tag 和用户主体的 Tag，使用 IAM 策略中的条件限制进行权限管控。这样可以大幅减少角色的定义工作。\n\n\n##### **3.2 基于 SAML2.0 的 Auth0 与亚马逊云控制台权限集成**\n\n与 Auth0 结合实现 ABAC 权限管理模型的方式如下所示：\n\n- 首先，在 Auth0 中创建 Rule，在 SAML 断言中携带 session Tag，将用户的属性作为会话标签进行传递：\n下面的实例代码展示 Auth0 通过 SAML 断言将 project 和 role 两个属性作为会话标签传递给 IAM 的 PrincipalTag\n\n```\\n \\tfunction(user, context, callback) {\\n ......\\n context.samlConfiguration.mappings = {\\n 'https://aws.amazon.com/SAML/Attributes/Role': 'awsRole',\\n 'https://aws.amazon.com/SAML/Attributes/RoleSessionName': 'awsRoleSession',\\n 'https://aws.amazon.com/SAML/Attributes/PrincipalTag:project': user.user_metadata.project,\\n 'https://aws.amazon.com/SAML/Attributes/PrincipalTag:access_role': user.user_metadata.project\\n };\\n callback(null, user, context);\\n}\\n```\n\n- 然后，在 IAM role 中构建相应的权限\n下面的示例代码以管控 secretsmanager 资源为例，展示了权限控制的思路。构建一个 role，该 role 包含的 policy 覆盖项目中所有使用的资源，并且为每个资源都定义不同角色（如下包含了 manager 和 readonly 两个角色）对应的权限。\n\nSAML 断言中携带的的两个 session Tag 将分别对应 IAM 角色主体中的 amazon:PrincipalTag/Project 和 amazon:PrincipalTag/access-role 两个主体标签。同时我们需要对亚马逊云 中的资源都按照项目属性打上 amazon:ResourceTag/project 标签。\n\n这样在 policy 的 condition 部分就会根据主体标签（access-role）以及主体标签（project）和资源标签的匹配关系获得所需的权限策略。\n\n```\\n \\t\\"Statement\\": [ \\n{ \\n \\"Sid\\": \\"AllActionsSecretsManager\\", \\n \\"Effect\\": \\"Allow\\", \\n \\"Action\\": \\"secretsmanager:*\\", \\n \\"Resource\\": \\"*\\", \\n \\"Condition\\": { \\n \\"StringEquals\\":{ \\n \\"aws:ResourceTag/project\\": \\"\${aws:PrincipalTag/project}\\", \\n \\"aws:PrincipalTag/access-role\\": \\"manager\\"\\n\\t\\t\\t}\\n\\t\\t}\\n},\\n{\\n \\"Sid\\": \\"ReadActionSecretsManager\\", \\n \\"Effect\\": \\"Allow\\", \\n \\"Action\\": [ \\"secretsmanager:Describe*\\", \\n\\t\\"secretsmanager:Get*\\",\\n\\t \\"secretsmanager:List*\\" ],\\n \\"Resource\\": \\"*\\", \\n \\"Condition\\": { \\n \\"StringEquals\\":{ \\n \\"aws:ResourceTag/project\\": \\"\${aws:PrincipalTag/project}\\", \\n \\"aws:PrincipalTag/access-role\\": \\"readonly\\"\\n \\t\\t}\\n } \\n}\\n]\\n```\n\n基于 ABAC 的权限模型极大程度简化了 policy 的维护数量，尤其适用于多租户模式下对资源类型使用相对固定的场景。我们只需要一套 policy，使用资源标签和主体标签构建匹配规则就可以覆盖所有权限管控需求，并可以扩展至任意数量的项目。\n\n但 ABAC 也有自己的限制。比如 IAM 角色的附加托管策略数量具有上限， 每个托管策略的字符大小也具有上限，对构建较为复杂的策略时可能会受到相应的限制；并且 ABAC 依赖资源标签进行细粒度的资源隔离，这就需要对资源都打上标签且要求标签准确 ，这对有些不提供 ResourceTag 的资源（如 S3 prefix）ABAC 的方式就会受限。\n\n针对 RBAC 和 ABAC 的使用场景局限，我们同时推出了子妹篇《多云身份管控平台构建 — 第二篇 基于动态策略实现Auth0与亚马逊云控制台的权限集成》提供更为通用的解决思路。\n\n\n#### **本篇作者**\n\n\n\n\n\n#### **倪惠青**\n\n\nAmazon 解决方案架构师，负责基于 Amazon 云计算方案架构的咨询和设计，在国内推广 Amazon 云平台技术和各种解决方案。在加入 Amazon 之前曾在 Oracle，Microsoft 工作多年，负责企业公有云方案咨询和架构设计，在基础架构及大数据方面有丰富经验。","render":"<p>越来越多的企业在迁移上云旅程中都会面临多云的选择。不管是出于主动原因希望融合多云的服务优势，还是出于被动原因需要适应公司的业务并购，抑或是因为上云过程中需要实现混合云架构的打通，构建多云的统一身份权限管控平台往往是这些企业需要解决的问题。</p>\n<p>构建这一平台，不仅要实现单点登录，还要考虑统一身份管控、统一权限管控和云上用户行为审计；并且企业内人员的多组织管理模型通常与云上基于角色的 IAM 管理模型存在较大差异，这进一步增加了构建跨云身份管理平台的难度。</p>\n<p>本博客从企业客户的实际需求和技术难点出发，分别阐述了使用</p>\n<ul>\\n<li>RBAC — 基于角色的权限管控</li>\n<li>ABAC — 基于属性的权限管控</li>\n<li>动态策略生成</li>\n</ul>\\n<p>这三种思路实现企业统一身份管控平台，并与公有云控制台 (Web console) 实现身份和权限的打通；以及三种思路各自的适用场景；并在此基础上给出了基于 Auth0 构建该平台，完成与亚马逊云控制台集成，实现统一登录与授权的具体实现代码样例。</p>\n<p>受篇幅所限，我们把博客分成两部分，本篇讲述 RBAC 和 ABAC 的实现方法；第二篇讲述动态策略生成的实现方法。</p>\n<p><a href=\\"https://aws.amazon.com/cn/blogs/china/construction-of-multi-cloud-identity-management-and-control-platform-the-first-article-realizes-the-permission-integration-of-auth0-and-amazon-cloud-console-based-on-rbac-abac/\\" target=\\"_blank\\">多云身份管控平台构建——第二篇 基于动态策略实现Auth0与亚马逊云控制台的权限集成</a></p>\\n<h4><a id=\\"1_17\\"></a><strong>1.统一身份管控平台概述</strong></h4>\\n<h5><a id=\\"11__20\\"></a><strong>1.1 构建需求</strong></h5>\\n<p>下图展示了一个实际案例中企业对统一身份管控平台的需求：</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/f8ebc7a50e404381b2597d1ef33a0a92_image.png\\" alt=\\"image.png\\" /></p>\n<ol>\\n<li>企业构建统一的身份、权限管控平台，并提供唯一入口对外访问</li>\n<li>用户访问统一身份管控平台时，自动跳转至企业 iDaaS 系统，完成身份认证</li>\n<li>认证成功后，进入企业的权限管理系统，获取相应的权限信息</li>\n<li>用户选择需要登录的公有云链接，携带用户及权限信息，实现对公有云控制台的无缝跳转和权限控制。</li>\n</ol>\\n<h5><a id=\\"12__32\\"></a><strong>1.2 技术挑战</strong></h5>\\n<p>企业的 iDaaS 系统通常会采用人员的多组织关系模型。如下图左半部分所述的企业实际场景：</p>\n<ul>\\n<li>企业员工可以同时归属到多个项目，并在项目中担任不同角色</li>\n<li>同一个员工在不同项目中可以担任不同角色。如在 Project1 中担任 Manager，负责 iDaaS 系统中用户创建和权限分配；在 Project2 中担任 Owner，负责公有云资源的创建和管理；在 Project3 中担任 Readonly 角色，对公有云资源具有只读权限。</li>\n</ul>\\n<p>下图右半部分以 Amazon IAM 为例简要展示了公有云的 IAM 权限管理模型：IAM 通过 policy 控制对云资源可以实施的动作，并通过条件对资源、行为主体、请求类型等进行细粒度限制；然后将 policy 挂接到 Role 上实现权限与行为主体的映射。</p>\n<p>可以看到，公有云的 IAM 管理模型虽然具有用户、组和角色的划分，但账号内通常不会支持多级人员管理；而且 SSO 一般是通过 IDP 的用户属性到公有云 IAM 角色的映射实现权限打通，如何使用扁平的角色管理模型实现多组织层级的资源权限管控是当前面临的主要技术难点。</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/ea9ca14b42794b6b8df88ad878e7d18c_image.png\\" alt=\\"image.png\\" /></p>\n<h4><a id=\\"2__RBAC_47\\"></a><strong>2. 思路一：基于角色的权限管理模型 RBAC</strong></h4>\\n<h5><a id=\\"21__50\\"></a><strong>2.1 方案概述</strong></h5>\\n<p>基于 RBAC 的方案是对企业 iDaaS 中的每一个项目 x 角色的组合在云中都对应一个指定的 role。因此云中 IAM 角色的数量将与企业 iDaaS 中项目 x 角色的数量相等。如下图，使用 RBAC，就是对企业中的每个项目都在 Amazon IAM 中创建三个角色（Manager，Owner，Readonly），并为每个角色维护单独的权限策略。该方案的特点是通过静态角色完成设置，实现方法简单直接，非常适合项目和角色数量有限的场景；但随着项目和角色数量的增加，维护众多的的权限策略将逐渐成为噩梦。并且每账户的 IAM 角色数量通常具有上限，例如亚马逊云的目前上限为每账户允许创建最多5000个角色.</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/d1e85591fe104061a30717e5fdb24f81_image.png\\" alt=\\"image.png\\" /></p>\n<h5><a id=\\"22__SAML20__Auth0__58\\"></a><strong>2.2 基于 SAML2.0 的 Auth0 与亚马逊云控制台权限集成</strong></h5>\\n<p>亚马逊云提供了 Cognito 用于支持数百万用户规模的管理、以及与第三方社交身份提供商的联合认证，并提供多种方式帮助用户从应用来控制对亚马逊云资源的访问，有关 Cognitor 的文档和博客已经非常丰富。本博客从通用方案的角度出发，选择了第三方产品 Auth0 来演示如何通过 SAML2.0 与亚马逊云控制台实现统一身份权限管理。本文对 Auth0 与 Amazon IAM 间如何交换 SAML Metadata 构建信任关系不再赘述，重点讨论如何建立 Auth0 的用户与 IAM 角色的映射关系：</p>\n<ul>\\n<li>首先，确定 Auth0 的用户如何与 IAM 角色实现映射：<br />\\n在 RBAC 中我们使用用户所属项目以及在项目中担任的角色这两个组合属性来与 IAM 角色进行映射。</li>\n<li>然后：扩展 Auth0 的用户属性：<br />\\n缺省状态下，Auth0 用户不具备项目、角色等属性，但提供了 user_metadata 属性实现对用户定义的灵活扩展，演示中我们对该用户添加 project、role 这两个属性如下图：</li>\n</ul>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/1f4023ed0cc449d48d785eccf509c8ad_image.png\\" alt=\\"image.png\\" /></p>\n<ul>\\n<li>其次：在 Auth0 中创建 Rule，构建 Auth0 用户属性与 IAM 角色的映射关系</li>\n</ul>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/b7a2faa7f0b44c82b0973a59c64203b7_image.png\\" alt=\\"image.png\\" /></p>\n<p>创建客户化的规则（上图中 sharonTest）用于实现 Auth0 的属性与 IAM role 的映射，如下 Javascript 代码示例：</p>\n<pre><code class=\\"lang-\\">\\tfunction (user, context, callback) {\\nvar awsRoles = {\\n'project1-readonly': 'arn:aws:iam::{{ACCOUNTID}}:role/auth0saml,arn:aws:iam::{{ACCOUNTID}}:saml-provider/auth0saml',// Amazon中创建的基于SAML2.0联合认证的角色，用于控制project1-manager对资源的访问\\n'project2-manager': 'arn:aws:iam::{{ACCOUNTID}}:role/auth0saml-readonly,arn:aws:iam::{{ACCOUNTID}}:saml-provider/auth0saml' // Amazon中创建的基于SAML2.0联合认证的角色，用于控制project2-readonly对资源的访问\\n};\\n\\nvar userattribute = user.user_metadata.project+'-'+user.user_metadata.access_role;\\nuser.awsRole = awsRoles[userattribute]; // 根据用户当前所在的groups属性从awsRoles中匹配对应的角色\\nuser.awsRoleSession = user.name;\\n\\ncontext.samlConfiguration.mappings = { 'https://aws.amazon.com/SAML/Attributes/Role': 'awsRole',\\n'https://aws.amazon.com/SAML/Attributes/RoleSessionName': 'awsRoleSession'\\n};\\n callback(null, user, context);\\n}\\n</code></pre>\\n<ul>\\n<li>最后，登录 Auth0 提供的 IDP URL，身份认证通过后即可跳转到亚马逊云控制台界面</li>\n</ul>\\n<p>如下，为在 Auth0 中构建的基于 0 的 application 提供的 IDP Login URL</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/b78adc9f7cb6412cb7258f1df46da698_image.png\\" alt=\\"image.png\\" /></p>\n<p>输入用户名密码，在 Auth0 完成身份验证后，自动跳转至亚马逊云控制台。</p>\n<p>从以上实践可以看到，采用 RBAC 的权限管理模型，关键是如何实现 IDP 中的用户属性与 IAM 角色的映射。集成起来简单快速，适合匹配角色数量较少的场景使用。</p>\n<h4><a id=\\"3__ABAC_105\\"></a><strong>3. 思路二：基于属性的权限管理模型 ABAC</strong></h4>\\n<h5><a id=\\"31__108\\"></a><strong>3.1 方案概述</strong></h5>\\n<p>在某些场景，每个项目所使用的资源类型都是相同的，只是不同项目对应不同的资源实例。比如所有项目都只能使用 EC2和 RDS 服务，只是每个项目使用不同的服务实例。对这类同质的项目，就非常适合使用基于 ABAC 的权限管理模型，通过设定资源的 Tag 和用户主体的 Tag，使用 IAM 策略中的条件限制进行权限管控。这样可以大幅减少角色的定义工作。</p>\n<h5><a id=\\"32__SAML20__Auth0__114\\"></a><strong>3.2 基于 SAML2.0 的 Auth0 与亚马逊云控制台权限集成</strong></h5>\\n<p>与 Auth0 结合实现 ABAC 权限管理模型的方式如下所示：</p>\n<ul>\\n<li>首先，在 Auth0 中创建 Rule，在 SAML 断言中携带 session Tag，将用户的属性作为会话标签进行传递：<br />\\n下面的实例代码展示 Auth0 通过 SAML 断言将 project 和 role 两个属性作为会话标签传递给 IAM 的 PrincipalTag</li>\n</ul>\\n<pre><code class=\\"lang-\\"> \\tfunction(user, context, callback) {\\n ......\\n context.samlConfiguration.mappings = {\\n 'https://aws.amazon.com/SAML/Attributes/Role': 'awsRole',\\n 'https://aws.amazon.com/SAML/Attributes/RoleSessionName': 'awsRoleSession',\\n 'https://aws.amazon.com/SAML/Attributes/PrincipalTag:project': user.user_metadata.project,\\n 'https://aws.amazon.com/SAML/Attributes/PrincipalTag:access_role': user.user_metadata.project\\n };\\n callback(null, user, context);\\n}\\n</code></pre>\\n<ul>\\n<li>然后，在 IAM role 中构建相应的权限<br />\\n下面的示例代码以管控 secretsmanager 资源为例，展示了权限控制的思路。构建一个 role，该 role 包含的 policy 覆盖项目中所有使用的资源，并且为每个资源都定义不同角色（如下包含了 manager 和 readonly 两个角色）对应的权限。</li>\n</ul>\\n<p>SAML 断言中携带的的两个 session Tag 将分别对应 IAM 角色主体中的 amazon:PrincipalTag/Project 和 amazon:PrincipalTag/access-role 两个主体标签。同时我们需要对亚马逊云 中的资源都按照项目属性打上 amazon:ResourceTag/project 标签。</p>\n<p>这样在 policy 的 condition 部分就会根据主体标签（access-role）以及主体标签（project）和资源标签的匹配关系获得所需的权限策略。</p>\n<pre><code class=\\"lang-\\"> \\t&quot;Statement&quot;: [ \\n{ \\n &quot;Sid&quot;: &quot;AllActionsSecretsManager&quot;, \\n &quot;Effect&quot;: &quot;Allow&quot;, \\n &quot;Action&quot;: &quot;secretsmanager:*&quot;, \\n &quot;Resource&quot;: &quot;*&quot;, \\n &quot;Condition&quot;: { \\n &quot;StringEquals&quot;:{ \\n &quot;aws:ResourceTag/project&quot;: &quot;\${aws:PrincipalTag/project}&quot;, \\n &quot;aws:PrincipalTag/access-role&quot;: &quot;manager&quot;\\n\\t\\t\\t}\\n\\t\\t}\\n},\\n{\\n &quot;Sid&quot;: &quot;ReadActionSecretsManager&quot;, \\n &quot;Effect&quot;: &quot;Allow&quot;, \\n &quot;Action&quot;: [ &quot;secretsmanager:Describe*&quot;, \\n\\t&quot;secretsmanager:Get*&quot;,\\n\\t &quot;secretsmanager:List*&quot; ],\\n &quot;Resource&quot;: &quot;*&quot;, \\n &quot;Condition&quot;: { \\n &quot;StringEquals&quot;:{ \\n &quot;aws:ResourceTag/project&quot;: &quot;\${aws:PrincipalTag/project}&quot;, \\n &quot;aws:PrincipalTag/access-role&quot;: &quot;readonly&quot;\\n \\t\\t}\\n } \\n}\\n]\\n</code></pre>\\n<p>基于 ABAC 的权限模型极大程度简化了 policy 的维护数量，尤其适用于多租户模式下对资源类型使用相对固定的场景。我们只需要一套 policy，使用资源标签和主体标签构建匹配规则就可以覆盖所有权限管控需求，并可以扩展至任意数量的项目。</p>\n<p>但 ABAC 也有自己的限制。比如 IAM 角色的附加托管策略数量具有上限， 每个托管策略的字符大小也具有上限，对构建较为复杂的策略时可能会受到相应的限制；并且 ABAC 依赖资源标签进行细粒度的资源隔离，这就需要对资源都打上标签且要求标签准确 ，这对有些不提供 ResourceTag 的资源（如 S3 prefix）ABAC 的方式就会受限。</p>\n<p>针对 RBAC 和 ABAC 的使用场景局限，我们同时推出了子妹篇《多云身份管控平台构建 — 第二篇 基于动态策略实现Auth0与亚马逊云控制台的权限集成》提供更为通用的解决思路。</p>\n<h4><a id=\\"_179\\"></a><strong>本篇作者</strong></h4>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/f82cef98e5cf48f2b9b7aeb9b8e0ed21_image.png\\" alt=\\"image.png\\" /></p>\n<h4><a id=\\"_185\\"></a><strong>倪惠青</strong></h4>\\n<p>Amazon 解决方案架构师，负责基于 Amazon 云计算方案架构的咨询和设计，在国内推广 Amazon 云平台技术和各种解决方案。在加入 Amazon 之前曾在 Oracle，Microsoft 工作多年，负责企业公有云方案咨询和架构设计，在基础架构及大数据方面有丰富经验。</p>\n"}