关于微服务:如何缩小安全漏洞爆炸半径实现服务间零信任安全

作者：王夕宁, 奇方

近日国内外多家平安机构监测到 Apache Log4j 存在任意代码执行破绽（破绽编号：CVE-2021-44228），未获得身份认证的用户，能够从近程发送数据申请输出数据日志，轻松触发破绽，最终在指标上执行任意代码。

家喻户晓，Log4j 在多个微服务利用框架中被宽泛应用，这些散布泛滥的微服务也会减少平安的挑战，每个微服务都是一个被攻打的指标。Kubernetes 为托管和编排用户的微服务提供了一个杰出的平台。然而，默认状况下，微服务之间的所有交互都不平安。它们通过纯文本 HTTP 进行通信，但这不足以满足平安要求。只依赖网络边界来保障平安是不够的，因为一旦外部的某个服务被攻陷，边界平安伎俩就如马奇诺防线，攻击者可能以该机器为跳板来攻打内网。所以，外部的调用也必须平安，这就是零信赖的用武之地。

零信赖是 Forrester 分析师 John Kindervag 提出的, 是指无论在网络边界外部还是内部，都没有任何隐含的信赖可言。换句话说，任何中央都须要显式认证, 并应用最小权限准则来限度对资源的拜访。

服务网格技术的一个重要的价值主张就是它如何无效地爱护利用的生产环境，同时又不升高开发人员的生产力。通过服务网格技术，为微服务架构采纳零信赖网络安全办法提供必要的根底，以此实现所有拜访都通过强身份验证、基于上下文受权、记录监控等平安指标。应用这些网格性能，您能够为属于网格的所有应用程序提供安全控制能力，例如所有流量都已加密、到应用程序的所有流量都通过策略执行点（PEP）的验证等。

由美国国家安全局（NSA）于 2021 年 8 月公布的《Kubernetes Hardening Guidance》（具体请见文末相干链接 1）也提到了管理员应该思考应用服务网格来增强 Kubernetes 集群的安全性。

阿里云服务网格 ASM（具体请见文末相干链接 2）成为重要的云原生零信赖体系落地载体之一，将身份验证和受权从利用程序代码卸载到服务网格，开箱即用、动静可配、更新策略更加容易且立刻失效。在应用 Kubernetes Network Policy 实现三层网络安全管制之上，服务网格 ASM 提供了包含对等身份和申请身份认证能力、Istio 受权策略以及更为精细化治理的基于 OPA(Open Policy Agent) 的策略控制能力。阿里云服务网格 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 提供了如下的零信赖平安根本能力：

工作负载身份

当应用程序在服务网格环境中运行时，服务网格会为每个服务提供一个惟一标识。连贯到服务网格中运行的其余微服务时，将会应用该标识。服务标识可用于服务的双向验证，以此进行验证是否容许服务间的拜访，同时该服务标识也可用于受权策略中。

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

ASM 中的服务身份合乎 SPIFFE 规范，并具备以下格局：spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>

在服务网格 ASM 管制台上，关上对应的 ASM 实例，在左侧导航栏中能够看到如下零信赖平安下的工作负载身份。

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

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

对等身份认证

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

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

• 对等身份验证 – 当两个微服务互相交互时，启用还是禁用双向 TLS 进行对等身份验证。
• 申请身份验证 – 容许最终用户和零碎应用申请身份认证与微服务进行交互。通常应用 JSON Web 令牌（JWT）执行该操作

依照入门指引（具体请见文末相干链接 3）装置部署 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

\

申请身份验证

首先，咱们将创立一个申请身份认证策略来对 details 服务的入站申请强制执行 JWT 身份验证。在服务网格 ASM 管制台上，关上对应的 ASM 实例，在左侧导航栏中能够看到如下零信赖平安下的申请身份认证。在右侧页面中，点击“新建”按钮，为工作负载 details 定义 jwt 规定。

其中，issuer 值设置为 ”testing@secure.istio.io”，jwks 的值取自 Istio 安装文件中的 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 产品中定义受权策略。

受权策略

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

OPA 策略

作为由 CNCF（具体请见文末相干链接 4）托管的一个孵化我的项目，凋谢策略代理（OPA）（具体请见文末相干链接 5）是一个策略引擎，可用于为您的应用程序实现细粒度的访问控制。OPA 作为通用策略引擎，能够与微服务一起部署为独立服务。为了爱护应用程序，必须先受权对微服务的每个申请，而后能力对其进行解决。为了查看受权，微服务对 OPA 进行 API 调用，以确定申请是否被受权。

服务网格 ASM 集成了凋谢策略代理（OPA）插件，通过 OPA 定义拜访控制策略，能够使您的利用实现细粒度的访问控制，并反对动静更新 OPA 策略。

具体能够参考《在 ASM 中实现动静更新 OPA 策略》（具体请见文末相干链接 6）

零信赖性能晋升

英特尔® 在全新的第三代英特尔® 至强® 可扩大处理器（ICELAKE）中引入泛滥咱们称为 Crypto Acceleration 加解密减速技术和架构翻新，大大晋升了一些要害加解密算法的性能。第三代英特尔至强处理器和 Multi-Buffer 技术所应用的 AVX512 指令集，在阿里云第七代 ECS 服务器中提供了若干不同的实例类型。基于这些指令集, 加上交融了 MultiBuffer 技术的 Envoy 上游社区能力，阿里云服务网格 ASM 产品提供了基于 MB 技术的 TLS 加解密性能优化能力。

联合英特尔的开源软件库，例如 IPP 加密库、IPsec 多缓冲区加密库 (intel-ipsec-mb)、英特尔® QuickAssist 技术（英特尔® QAT）和 OpenSSL 引擎。这些解决方案显着改善了加密操作，例如 TLS 连贯握手性能。这些新组件能够并行处理多个 TLS 私钥操作。借助 OpenSSL 和 BoringSSL 中都可用的异步私钥解决机制，应用程序软件能够提交握手私钥申请，而无需期待一个申请返回，而后能力提交另一个。反过来，一旦筹备好，就会为每个申请调用一个回调。在上面，多缓冲区加密解决能够将 8 个这样异步提交的私钥操作，并应用 AVX512 SIMD（单指令多数据）指令并行处理，大大提高了整体利用性能。

在阿里云 ASM 控制台中一键能够启用性能优化开关，以后这个性能曾经在产品最新版本中对外开放。

在 KubeCon 2021 大会上阿里云服务网格 ASM 负责人王夕宁和英特尔软件和先进技术部云计算团队的胡伟将会给大家带来一次专题的技术分享，届时咱们将会介绍更多的技术细节和实际的状况。（技术分享链接见文末 7）

总结及参考案例

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

• 提供具备残缺证书生命周期治理的托管证书基础设施，解决了证书颁发和 CA 轮换的复杂性；
• 托管的管制面 API，用于向 Envoy 代理散发身份验证策略，受权策略和平安命名信息；
• Sidecar 代理通过提供策略执行点 PEP 来帮忙确保网格的平安；
• Envoy 代理扩大容许遥测数据收集和审计；

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

参考案例

1. 应用受权策略在入口网关上施行基于 IP 的访问控制（具体请见文末相干链接 8）、或者基于自定义内部受权的访问控制等，如下图所示云产品云原生利用交付平台 ADP（具体请见文末相干链接 9）基于阿里云服务网格 ASM 的网关受权策略实现。

2. 某互联金融客户在解决跨集群多语言利用的拜访权限管制方面，应用阿里云服务网格 ASM 提供的受权策略隔离外联区域和利用区域。同时能够联合进口网关来审计出网格的流量，配合上受权策略，还能够管制利用对第三方服务的拜访权限。

相干链接

1）《Kubernetes Hardening Guidance》：

​​https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF​​

2）阿里云服务网格 ASM：

​​https://www.aliyun.com/product/servicemesh​​

3）入门指引：

​​https://help.aliyun.com/document_detail/149552.html​​

4）CNCF：

​​https://www.cncf.io/ ​​

5）凋谢策略代理（OPA）：

​​https://www.openpolicyagent.org/ ​​

6）《在 ASM 中实现动静更新 OPA 策略》：​​​​

​​https://help.aliyun.com/document_detail/277428.html​​

7）KubeCon 技术分享：

​​https://kccncosschn21.sched.com/event/rxVz/leng-ssxian-zhi-qiang-tang-jie-asmreintel-multi-bufferjiong-zha-zhi-hui-sponsored-session-using-alibaba-cloud-service-mesh-asm-and-intel-multi-buffer-technology-to-achieve-faster-encrypted-communication-between-application-services​​

8）应用受权策略实现访问控制

​​https://help.aliyun.com/document_detail/214764.html?spm=a2c4g.11186623.6.613.6b213918q0rlZV#title-f15-wyq-fxg​​

9）云原生利用交付平台 ADP：

​​https://adp.console.aliyun.com/ ​​