编辑导读： AutoMQ 是全球唯一一款与 Apache Kafka 100% 完全兼容的新一代 Kafka，可以做到 10 倍成本降低和极速的弹性。AutoMQ 提供的 BYOC 可以将数据面和控制面全部部署到用户的 VPC 内，具有非常强的数据隐私性，适合对数据主权十分关注的用户。本文在开头首先科普了云厂商现有的主要权限体系然后对 AutoMQ BYOC 模式获取权限的方式进行了简单的介绍，欢迎品读。

云厂商的权限体系

作为云技术服务商，API 集成是必备一项基本能力，与此关联的用户体系同样是关键的基础部分。一般我们将权限管理与用户管理及其关联的功能，往往统称为身份识别与访问管理，即 IAM（Identity and Access Management 的缩写）。IAM 一般情况包括两个主要部分，我们通常称为 Authn（Authentication）与 Authz（Authorization）。

• Authentication：主要职责为识别用户的身份，我们通常使用的登录功能可以认为是 Authentication 领域内的功能，通俗讲就是区分用户 A 与用户 B

• Authorization：主要用于用户认证后的权限控制，往往用于区分不同身份对于资源的访问权限的限制，即用户 A 登录后是否可以访问 a 链接或是 b 链接

接下来我们就简单介绍一下云提供商常见的一些 Authn 与 Authz 方案：

子账号体系

一个简单存在用户系统的应用，大部分情况都是每个用户注册一个账号，然后登录使用功能，前期的云提供商也是使用的这类账号体系，十分的直观。这个时期，以虚拟机为例，每个登录用户创建的虚拟机限制只能自己使用，其他的用户是无法看到与使用他人创建的虚拟机的。

但是随着企业客户越来越多，这类账号体系就存在了一些弊端：一个企业往往有很多员工，都会使用云提供商的功能与服务，如果每个用户都注册一个账号，并管理资源，那这个企业内的虚拟机会分散到许多的账号内，这对于管理会变得非常的不利。因为 AWS 推出了主子账号体系，即账号分为了两级：根账号与子账号。资源的归属权属于根账号，往往代表一个企业或虚拟主体，子账号由根账号创建和管理，可以创建和使用资源，但与资源无归属关联，子账号的注销并不会对实际资源产生任何影响，这样比较好的解决了企业客户使用云资源的场景。但是对于个人用户来说，这种体系稍显复杂，而且如果企业因为某些原因不止使用了一个根账号，那管理这些根账号同样也是一个复杂的工作，关于这类解决方案，我们会在后续的文章中详细讲解，现在暂不继续引申。

API 认证方式

解决了多用户使用云资源的问题，企业可能会推进自动化的体系建设，就需要使用 API 对接资源的生命周期和相关操作了，常见的用户名密码的登录模式就无法使用了。

目前主流的 API 认证方式有如下几种：

• Basic Auth：最为基础的 http 认证方案，将静态认证信息存储与 http header 中，简单但存在较大的安全隐患，在 http 协议下明文存储的认证信息非常容易被截获与复制，在 https 尚未普及的时代较少使用，但随着 https 的不断普及与发展，反而成为最为简单高效的认证方式。

• AccessKeyPair：目前云厂商采用的主流认证方式，对请求的内容进行了签名，保证了在 http 明文协议下的数据安全。

虽然 AccessKeyPair 保证了传输过程的安全，但在客户端侧 Sercet 还是往往以明文的方式存储，这类方式仍然产生了不小的安全隐患，因为很多云厂商都推出了基于基础设施的虚拟机授权方案。

用户可以将授权信息直接绑定在虚拟机上，访问 API 时可以通过内部的接口获取到临时 Access 信息，在不保存 AccessKeyPair 的情况下实现 API 的认证，大幅度提高了被攻击的风险。

权限策略

在 Authz 领域内，有很多种权限管理方案，常见的方案我这边列举三类：

• ACL：用户直接与权限点进行绑定，在权限点较少及领域模型较为简单的情况下，这类方案最为简单高效，而且能够较好的支持权限的申请与流程化。

  
  
  

• RBAC：最为常见的权限模型，使用“角色”概念将权限点聚合到一起，相同权限的用户可以快速的复用角色，减少重复的授权操作

  
  
  

• ABAC：基于属性的权限管理体系，相对于 RBAC，ABAC 提供了更多的扩展能力与可编程能力，权限的描述信息不仅仅包含了权限点信息，还往往扩展为基于资源属性的众多功能，例如对于资源与生效条件的限制。

  
  
  

目前主要的云提供商大多采用了 ABAC 的权限模型，以阿里云与 AWS 为例，简单介绍一下权限策略的构成：

• Policy：代表独立的一个权限策略，可以直接与授权主体绑定。

• Statement：代表一条权限描述语句，一个 Policy 内可以包含多个 Statement，其中逻辑关系与 Effect 有关，可以参考下面的介绍。

• Effect：Statement 中的元素，有两个枚举 Allow 与 Deny，Allow 最为常用，代表此条语句中的描述信息均为允许含义，不同 Allow 语句之间为逻辑或关系；Deny 代表强制否定含义，拥有最高优先级，Allow 与 Deny 存在冲突时，Deny 优先，不同 Deny 语句直接为逻辑与。

• Action：Statement 中的元素，代表语句包含的权限点，支持通配符。

• Resource：Statement 中的元素，代表语句所涉及的资源，支持通配符。

• Condition：Statement 中的元素，扩展性最强的元素，代表语句生效的条件，有很多扩展能力，包括对于标签，属性，环境等的匹配表达式。

• NotAction 与 NotResource：Statement 中的元素，较为不常用，代表语句不包含的权限点及资源，相当于黑名单机制

角色与 STS

面对常规的管理需求，我们已经有了应对手段。随着云计算的发展，使用云计算的客户也越来越多，很多时候我们需要访问其他根账号领域内的资源，这时候使用常规的 IAM 管理方案就无法满足需求了，这时候云厂商提出了角色概念。

这里的角色不同于权限管理中的角色，与子账号属于同一领域，代表了授权的主体，可以与权限策略进行绑定，代表一个虚拟的身份，当使用角色时，往往会采用“扮演”机制，即角色的使用场景，可扮演的主体大多分为几类：

• 账号：跨账号使用 API 的基本模式，被允许的用户可以扮演此角色。

• 联合登录 IDP：联合登录场景下，被允许的 IDP 身份可以扮演此角色。

• 云服务：允许云提供商的云服务以用户管理的角色身份，执行授权的 API

• 虚拟机：严格说也是使用云服务主体的模式，用于实现上文中提到的虚拟机授权场景

AutoMQ BYOC 的架构模式

AutoMQ 作为云原生架构的产品，依托于云的基本能力提供更加现代化的产品能力。BYOC 模式下，AutoMQ 将基于用户自身的云资源提供服务，保证了用户的独立性与安全性，也更能利用用户自身的云厂商折扣与现存的资源体系

虚拟机授权机制

AutoMQ 在 BYOC 模式下使用了虚拟机授权作为主要的授权模式，用户仅仅需要将 AutoMQ 需要的相关资源权限授予控制台所在的 VM 即可完成环境的初始化工作，控制台会通过 PassRole 方式将权限传播至 AutoMQ 的实例基础设施内，完成权限的授予。

基于标签进行权限约束

云厂商提供了基于标签的权限控制能力，能够进一步限制权限的范围，降低权限扩大的风险。

目前 AutoMQ 创建的所有资源均增加了 automqVendor 的标签，以阿里云为例，可以在权限 Policy 的 Condition 中增加对于 automqVendor 的限制，限制资源的操作范围：

• 限制资源创建的范围，仅可创建包含 automqVendor:automq 标签的资源

{    "Condition": {        "StringEquals": {            "acs:RequestTag/automqVendor": "automq"        }    }}

• 限制资源使用的范围，仅可以操作包含 automqVendor:automq 标签的资源

{    "Condition": {        "StringEquals": {            "acs:ResourceTag/automqVendor": "automq"        }    }}

结语

本文简单介绍了云提供商的权限相关的基础知识与 AutoMQ 对于权限控制方面的一些方案，欢迎大家关注 AutoMQ 的产品。