作者： 王夕宁, 奇方

微服务提供了诸多价值，包括可伸缩性、敏捷性、独立扩展、业务逻辑隔离、独立生命周期管理和更容易的分布式开发。然而，这些分布众多的微服务也会增加安全的挑战, 每个微服务都是一个被攻击的目标。Kubernetes为托管和编排您的微服务提供了一个出色的平台。但是，默认情况下，微服务之间的所有交互都不安全。它们通过纯文本HTTP进行通信，但这不足以满足安全要求。只依赖网络边界来保证安全是不够的，因为一旦内部的某个服务被攻陷，边界安全手段就如马奇诺防线，攻击者能够以该机器为跳板来攻击内网。所以，内部的调用也必须安全，这就是零信任的用武之地。

零信任是Forrester分析师John Kindervag提出的, 是指无论在网络边界内部还是外部，都没有任何隐含的信任可言。 换句话说，任何地方都需要显式认证, 并使用最小权限原则来限制对资源的访问。

服务网格技术的一个重要的价值主张就是它如何有效地保护应用的生产环境，同时又不降低开发人员的生产力。通过服务网格技术, 为微服务架构采用零信任网络安全方法提供必要的基础, 以此实现所有访问都经过强身份验证、基于上下文授权、记录监控等安全目标。使用这些网格功能，您可以为属于网格的所有应用程序提供安全控制能力, 例如所有流量都已加密、到应用程序的所有流量都通过策略执行点（PEP）的验证等。

由美国国家安全局（NSA）于 2021 年 8 月发布的《Kubernetes Hardening Guidance》也提到了管理员应该考虑使用服务网格来加强 Kubernetes 集群的安全性。

阿里云服务网格ASM（https://www.aliyun.com/product/servicemesh）成为重要的云原生零信任体系落地载体之一, 将身份验证和授权从应用程序代码卸载到服务网格, 开箱即用、动态可配、更新策略更加容易且立即生效。在使用Kubernetes Network Policy实现三层网络安全控制之上, 服务网格ASM提供了包括对等身份和请求身份认证能力、Istio 授权策略以及更为精细化管理的基于OPA(Open Policy Agent)的策略控制能力。阿里云服务网格ASM提供的这些零信任安全能力, 帮助用户实现上述这些安全目标。

构建服务网格ASM产品能力的理论体系包括了以下几个方面：

• 1）零信任的基础 - 工作负载身份, 如何为云原生工作负载提供统一的身份; ASM产品为服务网格下的每一个工作负载提供了简单易用的身份定义, 并根据特定场景提供定制机制用于扩展身份构建体系, 同时兼容社区SPIFFE标准；
• 2）零信任的载体 - 安全证书, ASM产品提供了如何签发证书以及管理证书的生命周期、轮转等机制, 通过X509 TLS证书建立身份，每个代理都使用该证书。并提供证书和私钥轮换；
• 3) 零信任的引擎 - 策略执行, 基于策略的信任引擎是构建零信任的关键核心, ASM产品除了支持Istio RBAC授权策略之外, 还提供了基于OPA提供更加细粒度的授权策略;
• 4）零信任的洞察 - 可视化与分析, ASM产品提供了可观测机制用于监视策略执行的日志和指标, 来判断每一个策略的执行情况等;

为什么要使用服务网格实现零信任？

与直接在应用程序代码中构建这些安全机制的传统方法相比,服务网格体系结构具有以下多种安全性好处：

• Sidecar代理的生命周期与应用程序保持独立，因此可以更轻松地管理这些Sidecar代理。
• 允许动态配置, 更新策略变得更加容易，更新立即生效，而无需重新部署应用程序。
• 服务网格的集中控制架构使企业的安全团队可以构建、管理和部署适用于整个企业的安全策略，从而默认情况下就能确保应用开发人员构建的业务应用的安全。他们无需额外的工作即可立即使用这些安全策略。
• 服务网格提供了对附加到请求的终端用户凭据进行身份验证的能力如JWT。
• 此外, 使用服务网格体系结构，可以将身份验证和授权系统作为服务部署在网格中。这样一来, 如同网格中的其他服务一样，这些安全系统从网格中本身也可以得到安全保证, 包括传输中的加密、身份识别、策略执行点、终端用户凭据的身份验证和授权等。

借助阿里云服务网格ASM，可以使用单个控制平面来实施强大的身份和访问管理，透明的TLS和加密，身份验证和授权以及审核日志记录。阿里云服务网格ASM开箱即用地提供了这些功能，并且安装和管理它的简单性使开发人员，系统管理员和安全团队可以适当地保护其微服务应用程序。

ASM中的零信任体系

服务网格能够减小云原生环境中的被攻击面积，并提供零信任应用网络所需的基础框架。通过ASM管理服务到服务的安全性，可以确保服务网格的端到端加密、服务级别身份认证和细粒度授权策略。

在服务网格体系下, 可以支持：

• 在服务之间实施双向 TLS认证或者面向server侧的TLS认证，支持证书的自动轮转等生命周期管理。网格内的通信都经过身份验证和加密处理。
• 启用基于身份的细粒度授权，以及基于其他维度参数的授权。基于角色访问控制 (RBAC) 的基础，支持“最低权限”的立场，也就是只有经过授权的服务才能根据 ALLOW/DENY 规则相互通信。

当前, 阿里云服务网格ASM提供了如下的零信任安全基本能力：

1. 工作负载身份

当应用程序在服务网格环境中运行时，服务网格会为每个服务提供一个唯一标识。连接到服务网格中运行的其他微服务时，将会使用该标识。服务标识可用于服务的双向验证,以此进行验证是否允许服务间的访问, 同时该服务标识也可用于授权策略中。

当使用服务网格ASM管理运行在Kubernetes上的工作负载或者基于WorkloadEntry定义虚拟机工作负载时，ASM会为每个工作负载提供服务身份；该身份基于工作负载的服务帐户令牌实现。

ASM中的服务身份符合SPIFFE标准，并具有以下格式：

spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>

在服务网格ASM控制台上, 打开对应的ASM实例, 在左侧导航栏中可以看到如下零信任安全下的工作负载身份。

数据面中的Kubernetes集群下的工作负载及其身份定义：

基于WorkloadEntry定义虚拟机工作负载及其身份定义：

2. 对等身份认证

认证指的是身份：这个服务是谁？这个最终用户是谁？我可以相信他们就是他们所说的那样吗？

ASM产品提供了两种身份验证：

- 对等身份验证 - 当两个微服务相互交互时，启用还是禁用双向TLS进行对等身份验证。

- 请求身份验证 - 允许最终用户和系统使用请求身份认证与微服务进行交互。通常使用JSON Web令牌（JWT）执行该操作。

按照入门指引(https://help.aliyun.com/document_detail/149552.html)安装部署bookinfo示例。

首先，当尝试从同一命名空间(例如本示例中为default)中的productpage pod 使用纯 HTTP 访问details服务时，默认情况下请求应该以 status 200 成功返回。这是因为在默认情况下，TLS和纯文本流量都可以被接受。

kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null -s -w '%{http_code}\n'

接着, 在命名空间default下定义对等身份认证。

在服务网格ASM控制台上, 打开对应的ASM实例, 在左侧导航栏中可以看到如下零信任安全下的对等身份认证。在右侧页面中, 点击“新建双向mTLS模式”按钮, 为工作负载details定义mTLS模式为STRICT。

再次, 使用productpage pod 使用纯HTTP访问details服务时：

kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null -s -w '%{http_code}\n'
000
command terminated with exit code 56

退出码56 表示接收网络数据失败。这是符合预期的, 工作负载details定义了mTLS模式为STRICT, 这样在每个请求中都需要TLS证书认证。

为了允许正常访问, 可以通过上述定义的对等身份认证从STRICT修改为PERMISSIVE。对应的YAML定义如下：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: details-strict
  namespace: default
spec:
  mtls:
    mode: PERMISSIVE
  selector:
    matchLabels:
      app: details

3. 请求身份验证

首先，我们将创建一个请求身份认证策略来对details服务的入站请求强制执行JWT身份验证。在服务网格ASM控制台上, 打开对应的ASM实例, 在左侧导航栏中可以看到如下零信任安全下的请求身份认证。在右侧页面中, 点击“新建”按钮, 为工作负载details定义jwt规则。

其中, issuer值设置为"testing@secure.istio.io",

jwks的值取自https://raw.githubusercontent.com/istio/istio/release-1.9/security/tools/jwt/samples/jwks.json，对应如下:

{ "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}

接着, 尝试使用productpage pod 使用纯 HTTP访问details服务时，可以看到返回结果为200。

其中设置变量TOKEN值为：

export TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3Uc1MI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg
kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer $TOKEN" -s -w '%{http_code}\n'
200

如果传递的是无效令牌，我们应该看到“401: Unauthorized”响应：

kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer badtoken" -s -w '%{http_code}\n'
401

但是，如果我们根本不传递令牌，RequestAuthentication则不会调用该策略。不使用JWT Token的请求, 同样也返回了200。

kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n'
200

因此，除了此身份验证策略之外，我们还需要一个授权策略，该策略要求对所有请求进行 JWT。下一部分会讲述如何在ASM产品中定义授权策略。

4. 授权策略

ASM产品提供了授权策略, 可以使用授权策略AuthorizationPolicy资源来激活微服务之间的授权机制，并使用以下内容建立适当的流量授权策略机制：

• 工作负载标签选择selector字段指定策略目标;
• action 字段指定是 ALLOW 还是 DENY 请求。如果您未指定操作，则操作默认设置为 ALLOW。为清晰起见，我们建议您始终指定操作。（授权政策还支持 AUDIT 和 CUSTOM 操作）;
• rules 指定何时触发操作：
• rules 中的 from 字段指定请求的来源;
• rules 中的 to 字段指定请求的操作;
• when 字段指定为了应用规则所需满足的其他条件;

对应的YAML定义如下：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  action: ALLOW
  rules:
    - from:
        - source:
            requestPrincipals:
              - testing@secure.istio.io/testing@secure.istio.io
  selector:
    matchLabels:
      app: details

再次不使用JWT Token发送请求, 您现在应该看到403 - Forbidden。这就是AuthorizationPolicy生效了，所有前端请求都必须有一个 JWT Token。

kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n'
403

5. OPA策略

作为由CNCF托管的一个孵化项目，开放策略代理（OPA）是一个策略引擎，可用于为您的应用程序实现细粒度的访问控制。OPA作为通用策略引擎，可以与微服务一起部署为独立服务。为了保护应用程序，必须先授权对微服务的每个请求，然后才能对其进行处理。为了检查授权，微服务对OPA进行API调用，以确定请求是否被授权。

服务网格ASM集成了开放策略代理（OPA）插件，通过OPA定义访问控制策略，可以使您的应用实现细粒度的访问控制，并支持动态更新OPA策略。

具体可以参考https://help.aliyun.com/document_detail/277428.html

总结及参考案例

综上所示, 服务网格ASM提供了以下用于增强安全性的组件：

• 提供具有完整证书生命周期管理的托管证书基础设施, 解决了证书颁发和 CA 轮换的复杂性;
• 托管的控制面API，用于向Envoy代理分发身份验证策略，授权策略和安全命名信息;
• Sidecar代理通过提供策略执行点PEP来帮助确保网格的安全;
• Envoy代理扩展允许遥测数据收集和审计;

每一个工作负载通过X509 TLS证书建立身份，每个Sidecar代理都使用该证书。服务网格ASM会提供并定期轮换证书和私钥。如果某个特定的私钥被盗用，服务网格很快就会用新的私钥替换它，从而大大减少了攻击面。

参考案例

1. 使用授权策略在入口网关上实施基于 IP 的访问控制（参考文档 https://help.aliyun.com/document_detail/214764.html?spm=a2c4g.11186623.6.613.6b213918q0rlZV#title-f15-wyq-fxg）、或者基于自定义外部授权的访问控制等, 如下图所示某云产品基于ASM的网关授权策略实现。

1. 某互联金融客户在解决跨集群多语言应用的访问权限控制方面, 使用阿里云服务网格ASM提供的授权策略隔离外联区域和应用区域。同时可以结合出口网关来审计出网格的流量，配合上授权策略，还可以控制应用对第三方服务的访问权限。