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

越来越多的企业在迁移上云旅程中都会面临多云的选择。不管是出于主动原因希望融合多云的服务优势，还是出于被动原因需要适应公司的业务并购，抑或是因为上云过程中需要实现混合云架构的打通，构建多云的统一身份权限管控平台往往是这些企业需要解决的问题。

构建这一平台，不仅要实现单点登录，还要考虑统一身份管控、统一权限管控和云上用户行为审计；并且企业内人员的多组织管理模型通常与云上基于角色的IAM管理模型存在较大差异，这进一步增加了构建跨云身份管理平台的难度。

本博客从企业客户的实际需求和技术难点出发，分别阐述了使用

• RBAC — 基于角色的权限管控
• ABAC — 基于属性的权限管控
• 动态策略生成

这三种思路实现企业统一身份管控平台，并与公有云控制台(Web console)实现身份和权限的打通；以及三种思路各自的适用场景；并在此基础上给出了基于Auth0构建该平台，完成与亚马逊云控制台集成，实现统一登录与授权的具体实现代码样例。

受篇幅所限，我们把博客分成两部分，本篇讲述RBAC和ABAC的实现方法；第二篇讲述动态策略生成的实现方法。

多云身份管控平台构建——第二篇 基于动态策略实现Auth0与亚马逊云控制台的权限集成

1.统一身份管控平台概述

1.1 构建需求

下图展示了一个实际案例中企业对统一身份管控平台的需求：

1. 企业构建统一的身份、权限管控平台，并提供唯一入口对外访问
2. 用户访问统一身份管控平台时，自动跳转至企业iDaaS系统，完成身份认证
3. 认证成功后，进入企业的权限管理系统，获取相应的权限信息
4. 用户选择需要登录的公有云链接，携带用户及权限信息，实现对公有云控制台的无缝跳转和权限控制。

1.2 技术挑战

企业的iDaaS系统通常会采用人员的多组织关系模型。如下图左半部分所述的企业实际场景：

• 企业员工可以同时归属到多个项目，并在项目中担任不同角色
• 同一个员工在不同项目中可以担任不同角色。如在Project1中担任Manager，负责iDaaS系统中用户创建和权限分配；在Project2中担任Owner，负责公有云资源的创建和管理；在Project3中担任Readonly角色，对公有云资源具有只读权限。

下图右半部分以AWS IAM为例简要展示了公有云的IAM权限管理模型：IAM通过policy控制对云资源可以实施的动作，并通过条件对资源、行为主体、请求类型等进行细粒度限制；然后将policy挂接到Role上实现权限与行为主体的映射。

可以看到，公有云的IAM管理模型虽然具有用户、组和角色的划分，但账号内通常不会支持多级人员管理；而且SSO一般是通过IDP的用户属性到公有云IAM角色的映射实现权限打通，如何使用扁平的角色管理模型实现多组织层级的资源权限管控是当前面临的主要技术难点。

2. 思路一：基于角色的权限管理模型RBAC

2.1 方案概述

基于RBAC的方案是对企业iDaaS中的每一个项目x角色的组合在云中都对应一个指定的role。因此云中IAM角色的数量将与企业iDaaS中项目x角色的数量相等。如下图，使用RBAC，就是对企业中的每个项目都在AWS IAM中创建三个角色（Manager，Owner，Readonly），并为每个角色维护单独的权限策略。该方案的特点是通过静态角色完成设置，实现方法简单直接，非常适合项目和角色数量有限的场景；但随着项目和角色数量的增加，维护众多的的权限策略将逐渐成为噩梦。并且每账户的IAM角色数量通常具有上限，例如亚马逊云的目前上限为每账户允许创建最多5000个角色.

2.2 基于SAML2.0的Auth0与亚马逊云控制台权限集成

亚马逊云提供了Cognito用于支持数百万用户规模的管理、以及与第三方社交身份提供商的联合认证，并提供多种方式帮助用户从应用来控制对亚马逊云资源的访问，有关Cognitor的文档和博客已经非常丰富。本博客从通用方案的角度出发，选择了第三方产品Auth0来演示如何通过SAML2.0与亚马逊云控制台实现统一身份权限管理。本文对Auth0与AWS IAM间如何交换SAML Metadata构建信任关系不再赘述，重点讨论如何建立Auth0的用户与IAM角色的映射关系：

• 首先，确定Auth0的用户如何与IAM角色实现映射：
  在RBAC中我们使用用户所属项目以及在项目中担任的角色这两个组合属性来与IAM角色进行映射。
• 然后：扩展Auth0的用户属性：
  缺省状态下，Auth0用户不具备项目、角色等属性，但提供了user_metadata属性实现对用户定义的灵活扩展，演示中我们对该用户添加project、role这两个属性如下图：

• 其次：在Auth0中创建Rule，构建Auth0用户属性与IAM角色的映射关系

创建客户化的规则（上图中sharonTest）用于实现Auth0的属性与IAM role的映射，如下Javascript代码示例：

 	function (user, context, callback) {
var awsRoles = {
'project1-readonly': 'arn:aws:iam::{{ACCOUNTID}}:role/auth0saml,arn:aws:iam::{{ACCOUNTID}}:saml-provider/auth0saml',// Amazon中创建的基于SAML2.0联合认证的角色，用于控制project1-manager对资源的访问
'project2-manager': 'arn:aws:iam::{{ACCOUNTID}}:role/auth0saml-readonly,arn:aws:iam::{{ACCOUNTID}}:saml-provider/auth0saml' // Amazon中创建的基于SAML2.0联合认证的角色，用于控制project2-readonly对资源的访问
};

var userattribute = user.user_metadata.project+'-'+user.user_metadata.access_role;
user.awsRole = awsRoles[userattribute]; // 根据用户当前所在的groups属性从awsRoles中匹配对应的角色
user.awsRoleSession = user.name;

context.samlConfiguration.mappings = {    'https://thinkwithwp.com/SAML/Attributes/Role': 'awsRole',
'https://thinkwithwp.com/SAML/Attributes/RoleSessionName': 'awsRoleSession'
};
  callback(null, user, context);
}

• 最后，登录Auth0提供的IDP URL，身份认证通过后即可跳转到亚马逊云控制台界面

如下，为在Auth0中构建的基于0的application提供的IDP Login URL

输入用户名密码，在Auth0完成身份验证后，自动跳转至亚马逊云控制台。

从以上实践可以看到，采用RBAC的权限管理模型，关键是如何实现IDP中的用户属性与IAM角色的映射。集成起来简单快速，适合匹配角色数量较少的场景使用。

3. 思路二：基于属性的权限管理模型ABAC

3.1 方案概述

在某些场景，每个项目所使用的资源类型都是相同的，只是不同项目对应不同的资源实例。比如所有项目都只能使用EC2和RDS服务，只是每个项目使用不同的服务实例。对这类同质的项目，就非常适合使用基于ABAC的权限管理模型，通过设定资源的Tag和用户主体的Tag，使用IAM策略中的条件限制进行权限管控。这样可以大幅减少角色的定义工作。

3.2 基于SAML2.0的Auth0与亚马逊云控制台权限集成

与Auth0结合实现ABAC权限管理模型的方式如下所示：

• 首先，在Auth0中创建Rule，在SAML断言中携带session Tag，将用户的属性作为会话标签进行传递：
  下面的实例代码展示Auth0通过SAML断言将project和role两个属性作为会话标签传递给IAM的PrincipalTag

 	function(user, context, callback) {
  ......
  context.samlConfiguration.mappings = {
    'https://thinkwithwp.com/SAML/Attributes/Role': 'awsRole',
    'https://thinkwithwp.com/SAML/Attributes/RoleSessionName': 'awsRoleSession',
    'https://thinkwithwp.com/SAML/Attributes/PrincipalTag:project': user.user_metadata.project,
    'https://thinkwithwp.com/SAML/Attributes/PrincipalTag:access_role': user.user_metadata.project
  };
  callback(null, user, context);
}

• 然后，在IAM role中构建相应的权限

下面的示例代码以管控secretsmanager资源为例，展示了权限控制的思路。构建一个role，该role包含的policy覆盖项目中所有使用的资源，并且为每个资源都定义不同角色（如下包含了manager和readonly两个角色）对应的权限。

SAML断言中携带的的两个session Tag将分别对应IAM角色主体中的aws:PrincipalTag/Project和aws:PrincipalTag/access-role两个主体标签。同时我们需要对亚马逊云 中的资源都按照项目属性打上aws:ResourceTag/project标签。

这样在policy的condition部分就会根据主体标签（access-role）以及主体标签（project）和资源标签的匹配关系获得所需的权限策略。

 	"Statement": [ 
{ 
    "Sid": "AllActionsSecretsManager", 
    "Effect": "Allow", 
    "Action": "secretsmanager:*", 
    "Resource": "*", 
    "Condition": { 
      "StringEquals":{ 
         "aws:ResourceTag/project": "${aws:PrincipalTag/project}", 
         "aws:PrincipalTag/access-role": "manager"
			}
		}
},
{
    "Sid": "ReadActionSecretsManager", 
    "Effect": "Allow", 
    "Action": [ "secretsmanager:Describe*", 
	"secretsmanager:Get*",
	 "secretsmanager:List*" ],
    "Resource": "*", 
    "Condition": { 
      "StringEquals":{ 
         "aws:ResourceTag/project": "${aws:PrincipalTag/project}", 
         "aws:PrincipalTag/access-role": "readonly"
       		}
     } 
}
]

基于ABAC的权限模型极大程度简化了policy的维护数量，尤其适用于多租户模式下对资源类型使用相对固定的场景。我们只需要一套policy，使用资源标签和主体标签构建匹配规则就可以覆盖所有权限管控需求，并可以扩展至任意数量的项目。

但ABAC也有自己的限制。比如 IAM 角色的附加托管策略数量具有上限， 每个托管策略的字符大小也具有上限，对构建较为复杂的策略时可能会受到相应的限制；并且ABAC依赖资源标签进行细粒度的资源隔离，这就需要对资源都打上标签且要求标签准确 ，这对有些不提供ResourceTag的资源（如S3 prefix）ABAC的方式就会受限。

针对RBAC和ABAC的使用场景局限，我们同时推出了子妹篇《多云身份管控平台构建 — 第二篇 基于动态策略实现Auth0与亚马逊云控制台的权限集成》提供更为通用的解决思路。

本篇作者