作者：
艾竞，花名庭坚，蚂蚁金服系统部研究员
李婷婷，花名鸿杉，蚂蚁金服平台安全资深安全专家

背景

随着轻量级容器（container）的兴起，应用（applications）逐渐由单体（monolithic）向微服务（micro-service）演进。相应的，应用的微服务化也带来了如下的变化：

• 软件研发、运维人员组织围绕着微服务下的软件模块重新架构：研发、运维人员分化成更小的组织以专注于一个或多个软件模块（以容器的形式交付）；在微服务 API 稳定的情况下，各个模块独立开发，测试和部署可以进行更高速的迭代
• 应用中软件模块之间由函数调用的“强”耦合变成网络远程调用的“松”耦合；维持原先各个模块之间的信任需要有额外的安全机制

另一方面，除了台式机（desktop），其它可以接入应用的物理设备（device），例如笔记本电脑（laptop），手机（mobile phone），也已经大规模普及。因此，企业员工通常拥有多个设备来访问企业应用以完成日常工作。个人多设备以及设备的移动性对于企业传统的安全边界模型（perimeter model）提出了挑战。

可以观察到，在应用由单体向微服务，设备由单一、静态向多种、移动的演化下，系统中各个 Entity（实体，例如，人，设备，服务等）的 Identity（身份），由单一的网络标识，即 IP 或者 IP：Port，向多种形态（X.509 certificate, token, service account 等）分化。Identity 的分化会对研发、运维效能和资源效能也会产生深刻的影响。

在这些背景下，传统基于 IP、域名的管控方式临着巨大的挑战，静态的规则让安全策略变得无法维护；同时，在微服务架构下，安全人员很难快速找到一条边界，将不同的风险域隔离开来。因此，急需一种新 Access Control 模式来应对。

Forrester 的首席分析师约翰·金德维格在 2010 年提出了零信任（Zero Trust）的理念针对传统边界安全架构思想进行了重新评估和审视，并对安全架构思路给出了新的建议，其核心思想是 "Never Trust，Always Verify" - All network traffic is untrusted. There is no "trusted traffic"。阿里巴巴已经在内部开始推进零信任架构的落地，包括企业内部接入层的零信任、生产网内部机器、应用间的零信任，并已经开始在 双11 中发挥了重要的作用。

零信任第一个核心问题就是 Identity，赋予不同的 Entity 不同的 Identity，解决是谁在什么环境下访问某个具体的资源的问题。因此，本文将从 Identity 与微服务和 Identity 与企业应用访问两个方面来阐述 Identity 在生产应用和企业应用中的思考，同时也会介绍在不同的场景下如何利用 Identity 解决谁在什么环境可以访问某个资源的具体实践。

Identity 与微服务

随着用户需求在信息化时代的日益增长，软件也变得越来越复杂。为了应对软件复杂度的提升，软件的架构也由简单的单体应用逐渐演变成为复杂的微服务应用。2017 年，Kubernetes 开始成为事实上的标准容器编排平台。同一年，谷歌联合 IBM，Lyft 推出的 Istio 主打 SideCar 模式下的微服务治理。至此，在云原生时代，应用得以在 Kubernetes 和 Istio 构成的底座之上以容器的形式微服务化。

在云原生的转型中，软件研发、运维组织架构需要围绕微服务来重新构建：如果把一组在逻辑、功能上耦合紧密的软件模块看作一门“功夫”的话，它们背后的研发、运维人员就是一个“武林门派”；各个“武林门派”相对独立的“修炼”自己的“功夫”；配合起来，又能满足软件系统整体的演进。然而，这套适配微服务的组织架构对于研发、运维模式提出了很大的挑战。归结到一点：就是从每个研发、运维者的角度，如何在关注本门“功夫”的同时保证软件系统整体的可用性。

Identity 由单一网络地址变得更多元化以标识不同的对象（例如，用户，用户组，服务等）为应对上述挑战提供了可能性。接下来，我们会看到 Identity 是如何覆盖整个软件开发周期各个场景为每个研发、运维者创造相对隔离的“环境”的。

Identity 与 Kubernetes 集群

首先，我们来看 Identity 是如何依据用户/用户组提供所需 Kubernetes 集群资源的。Kubernetes 集群是用于容器生命周期管理的。细分一下，其用户大致可以分为如下两类：

• Kubernetes 集群的管理者：关注集群本身，主要的职责包括并不限于：

  • Kuberentes 组件的维护及升级
  • Kuberentes 集群中 Node 的治理
  • Kuberentes 集群中 Namespace 的治理
  • Kuberentes 集群中各类 policy（例如，Role-Based Access Control（RBAC） for AuthZ）的治理
  • Kuberentes 集群中 Pod 调度管理
  • Kuberentes 集群中 C[X]I（例如，CRI，CNI，CSI 等）的治理
  • Kuberentes 集群资源容量管理
  • 。。。

• Kubernetes 集群的使用者：关注如何在集群之上运行容器，依据角色（例如，开发/测试/运维）的不同，主要的使用方式有：

  • Kuberentes 集群中 Service Account 的治理
  • 将 Kubernetes 集群作为开发环境
  • 将 Kubernetes 集群作为线下测试环境，运行 CI/CD
  • 将 Kubernetes 集群作为线上发布环境，进行灰度，回滚等操作

对于第一类 Kubernetes 集群用户，可以通过 Kubernetes RBAC 机制下 ClusterRoleBinding 赋予集群级别权限；并且需要“垄断”集群和 Namespace 级别策略的制定；为了防止敏感信息泄露，还需要将集群和 Namespace 级别的信息以及敏感信息（例如 Secret）设置为仅为 Kubernetes 集群管理者可见。

对于第二类 Kubernetes 集群用户，可以进一步按照对应的微服务中软件模块来进行细分成不同的组（Group）。另一方面，Kubernetes Namespace 提供了虚拟集群的抽象。因此，当 Kubernetes API Server 认证用户身份之后，可以按照组的粒度将用户映射到 Kubernetes 集群某个 Namespace 的角色（Role）而这个角色在此 Namespace 中拥有相应权限。具体来说，用户到 Namespace 的映射可以通过 Kubernetes RBAC 机制下 RoleBinding 完成。考虑到系统策略的可维护性，以组 Identity 的粒度制定策略而以用户 Identity 用于审计（Audit）是合理的。

Kubernetes 中并没有代表用户的资源，并且企业一般都会拥有多个 Kubernetes 集群。因此，提供组织架构信息（例如，用户（User），组（Group））的 Identity Provider（IdP）应该独立于 Kubernetes 集群之外并可以服务多个 Kubernetes 集群。如果对多个 Kubernetes 集群采用相同的配置，用户可以收获跨集群的一致性用户体验。

图 1：Identity Provider 与 Kubernetes 集群

在 IdP 中的组织架构，一个组可以包含用户，也可以包含其他组；与此同时，一个用户也可以直接棣属于多个组。因此可以根据用户操作（用户执行的 yaml 文件中指定了具体的 Namespace）来更加灵活映射到不同的角色来操作相应的 Kubernetes Namespace：

• 例子一：一个用户按架构域划分属于 A 组，按角色划分属于 dev 组。当要运行容器时，Kubernetes 集群的 RBAC 策略会允许他在 Namespace A-dev 中操作。
• 例子二：一个用户按架构域划分既属于 A 组也属于 B 组，按角色划分属于 test 组。当要运行容器时，Kubernetes 集群的 RBAC 策略会允许他在 Namespace A-test 和 Namespace B-test 中操作。

图 2：企业组织架构与 Kubernetes 集群


值得注意的是，IdP 中的组织架构代表 Kubernetes 管理者和使用者的组还是要严格分开以防止权限泄露。此外，当有任何组织架构变动时（例如，用户从 Kubernetes 管理者变成使用者），Kubernetes 集群需要能够及时捕捉。

Identity 与 Service Mesh

其次，我们来看 Identity 是如何依据用户/用户组和相应的配置创造出不同的软件运行环境的。当用户通过 Kubernetes 开始运行容器后，容器所代表的微服务就交由 Service Mesh 来治理。如图 3 所示，在 Istio 1.1+，在启动 Pod 的时候，Pod Identity 会通过 SDS（Secret Discovery Service）获取。

图 3：Pod Identity 获取流程

Pod 的 Identity 的格式会采取源自谷歌 LOAS（Low-Overhead Authentication Service）的 SPIFFE（Secure Production Identity Framework for Everyone）标准，spiffe:///ns//sa/以全局唯一标识相应的 Workload；并且 Identity 相应的证书也会由 CA（Certificate Authority）来签发。有了证书背书，当 Pod 可以与其它 Pod 通信时，就可以通过 mTLS 完成对通信链路加密。

更为重要的是，Service Mesh 可以通过 Istio RBAC 实现基于 Identity 的 RPC（Remote Procedure Call）ACL（Access Control List）。因此，当由有不同角色（例如，开发/测试/运维）的用户来运行/部署同一个微服务时，因为所在组不同而获取不同的 SPIFFE ID，即使在同一个 Kubernetes 集群中，只要设置合适的 Istio RBAC Policy，他们能运行的微服务也处于彼此隔离的环境中。

图 4：Istio 下基于 Identity 隔离的环境


此外，一个组通常会拥有微服务的多组软件模块。当映射到 Kubernetes Namespace 时，对不同组的软件模块最好采用不同的 Service Account。这是因为，Pod 的 SPIFFE ID 的信任来自于 Kubernetes Service Account；一旦Service Account 被 compromise，它所造成的损失有限。

图 5：Service Account 的隔离

Workload Identity 的实践

阿里巴巴正在全面推行 Service Mesh 的架构演进，这为我们在此场景下快速落地 Workload 的 Identity 及访问控制提供了很好的基础。

图 6：Service Mesh 架构下应用间访问控制


应用的身份以及认证统一由安全 Sidecar 统一提供，授权模型我们采用了 RBAC 模型，在 Sidecar 中集成了 RBAC Filter。RBAC 模型在大部分场景下都能满足需求，但在项目推进过程中我们发现一种比较特殊的场景，比如 A 应用需要被所有的应用访问，会导致策略无法描述。因此在这种场景下，我们考虑升级为 ABAC（Attribute-Based Access Control）模型，采用 DSL（Domain Specific Language）语言来描述，并集成在安全 Sidecar 中。

Identity 与软件交付

此外，Identity 不仅仅体现在软件研发、测试及运维，它还覆盖其他的方面。

镜像管理

在云原生范式下，代码终将以镜像的形式来使用。在关注构成镜像本身代码的安全性同时，我们还关心镜像的来源（即相应代码库 URL），制作者（组）和标签。在线上生产环境（其它环境可以放松这个限制）以容器运行镜像时，我们需要确保镜像是来自已知代码库，由合法的用户（来自拥有代码所有权的组）制作并有合适的标签（例如，release）。因此，我们需要在镜像的 metadata 中植入相关的 Identity 信息以便应用相关的策略。

微服务部署

在云原生时代，微服务部署所需的 yaml 配置往往是庞大繁琐的。如前所述，Identity 结合 Kubernetes/Istio RBAC Policies 可以创建出不同的隔离环境以便于开发，测试和运维，但是也需要有相应的 yaml 配置来适配。然而，yaml仅仅只是对一组可嵌套的描述，自身没有任何复用，重载的计算机编程语言的特性。因此，我们需要使用云原生场景下的 DSL 来方便的刻画同一个微服务不同（例如，研发/测试/生产）环境下的配置。举例来说，针对不同的环境，主要区别在于：1）Kubernetes Namespace 不同；2）所需的计算资源不同。所以，DSL 可以将各个环境相同的配置沉淀下来形成模版，在此基础之上，对与环境相关的配置进行定制或重载以适配不同环境。

图 7：DSL 下的微服务配置

通常来讲，相对于微服务代码变更，微服务配置变更属于低频操作。DSL 将微服务配置接管过来使得配置也像代码一样可重用、可验证，大大降低因为配置及其变更带来的错误。因此，所有的开发者可以对代码进行更高速的迭代从而把代码缺陷暴露在更早的阶段。

Identity 与企业应用访问

阿里巴巴已经内部已部分地落地了基于零信任的企业应用访问的架构，从以前简单以员工的身份作为唯一且静态的授权依据，扩展为员工身份、设备、以持续的安全评估达到动态安全访问控制的新架构。

图 8：企业应用的访问控制

在这种新的架构下，首先，我们选择安全网关作为控制点，与阿里巴巴 IAM（Identity Access Management）结合，对员工的身份以及接入的设备进行认证，知道是否从对应的人和其对应的设备请求接入；协议方面，员工设备与安全网关之前，采用 HTTPS 对各种协议进行封装，统一由安全网关进行代理访问后端的应用；其次，安全网关内置的 Access Control Engine 结合流量中的上下文（Context）对访问的请求做持续的建模，对来自非可信、非认证设备、或者异常的访问行为做实时的阻断。

结语

随着互联网应用由单体向微服务架构转型，加之访问互联网应用的移动设备的繁荣，网络标识（例如，IP，Port等）已经不能作为稳定的 Identity 来标识分布式系统中的实体，建立在此之上的边界安全模型应对各种场景已经显得力不从心。因此，对于不同实体（例如，人，设备，服务等），Identity 需要由更能凸显其本质的、有密码学背书的稳定凭证（credential）来担当。相应的，建立在此类 Identity 基础之上安全策略有着丰富的语义来适配不同的场景：在研发、测试和运维微服务场景下，Identity 及其相关策略不仅是安全的基础，更是众多（资源，服务，环境）隔离机制的基础；在员工访问企业内部应用的场景下，Identity 及其相关策略提供了灵活的机制来提供随时随地的接入服务。无论那种场景下，Identity 对分布式系统中不同实体划分了有效的安全边界，并提供隔离机制来提高资源效能和用户体验。

本书亮点

• 双11 超大规模 K8s 集群实践中，遇到的问题及解决方法详述
• 云原生化最佳组合：Kubernetes+容器+神龙，实现核心系统 100% 上云的技术细节
• 双 11 Service Mesh 超大规模落地解决方案

“阿里巴巴云原生微信公众号（ID：Alicloudnative）关注微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的技术公众号。”