38.云原生之Istio安全-流量鉴权加密

云原生专栏大纲

TLS 和 mTLS

TLS（Transport Layer Security）和 mTLS（mutual TLS）都是用于加密通信的协议，用于保护数据在网络上的传输安全。它们在保护通信方面有一些区别：

1. TLS（Transport Layer Security）：
   • TLS 是一种加密通信协议，用于在网络上安全地传输数据。它用于建立安全的通信通道，确保数据在传输过程中不被篡改或窃取。
   • TLS 通常用于客户端和服务器之间的通信，并且只要求服务器端提供证书，客户端验证服务器身份。
   • 在 Web 安全中，HTTPS（HTTP over TLS）就是使用 TLS 来加密 HTTP 通信的协议。
2. mTLS（mutual TLS）：
   • mTLS 是 TLS 的一种扩展，也称为双向 TLS 或双向认证。它要求通信双方（客户端和服务器）都提供证书，进行相互验证身份。
   • 在 mTLS 中，不仅服务器验证客户端的身份，客户端也验证服务器的身份。这种双向验证确保了通信的双方都是可信的，并且加强了通信的安全性。

主要区别在于 TLS 通常是单向验证，而 mTLS 是双向验证。mTLS 提供了更高级别的安全性，因为它不仅验证服务器的身份，还验证客户端的身份，确保了通信的完整性和安全性。
在网络安全领域，mTLS 通常用于要求更严格的安全标准的场景，如微服务之间的通信、API 访问控制等。通过使用 mTLS，可以确保通信双方的身份验证和通信数据的加密，提高了通信的安全性和可靠性。

TLS 和 mTLS使用场景

TLS（Transport Layer Security）和 mTLS（mutual TLS）在网络通信中有不同的使用场景，根据安全需求和通信模型的不同，选择合适的加密方式非常重要：
TLS 使用场景：

1. Web通信：TLS 在 Web 通信中广泛应用，用于加密 HTTP 通信，形成 HTTPS 协议，保护 Web 应用的数据传输安全。
2. 客户端-服务器通信：在传统的客户端-服务器模型中，服务器通常会提供证书，客户端验证服务器的身份，确保通信的安全性。
3. 加密数据传输：TLS 可用于保护数据在网络上的传输，确保数据在传输过程中不被篡改或窃取。
4. 保护隐私数据：适用于需要保护用户隐私数据的应用场景，如登录、支付等敏感操作。

mTLS 使用场景：

1. 微服务通信：在微服务架构中，各个服务之间的通信可能需要更严格的安全性要求，mTLS 可用于确保服务之间的双向身份验证和通信加密。
2. API 访问控制：在 API 访问控制中，服务端可以要求客户端提供证书进行身份验证，确保只有授权的客户端可以访问 API。
3. 云原生环境：在容器化和云原生环境中，mTLS 可用于保护容器间的通信，确保容器之间的安全通信。
4. 内部通信：适用于内部系统或服务之间的通信，要求更高级别的安全性和身份验证。

总的来说，TLS 适用于大多数常规的加密通信场景，而 mTLS 则适用于对通信安全性要求更高、需要双向身份验证的场景，如微服务架构、API 访问控制等。选择合适的加密方式取决于您的安全需求和通信模型。

TLS 加密通信的流程

1. 服务器向受信任的 CA（证书管理机构）申请并获得证书（X.509 证书）；
2. 客户端向服务端发起请求，其中包含客户端支持的 TLS 版本和密码组合等信息；
3. 服务器回应客户端请求并附上数字证书；
4. 客户端验证证书的状态、有效期和数字签名等信息，确认服务器的身份；
5. 客户端和服务器使用共享秘钥实现加密通信；

参考：TLS 握手期间会发生什么？
写给 Kubernetes 工程师的 mTLS 指南 | 云原生资料库

终止 TLS

TLS 终止（TLS Termination）指的是在将 TLS 加密流量传递给 Web 服务器之前对其进行解密的过程。将 TLS 流量卸载到入口网关或专用设备上，可以提高 Web 应用的性能，同时确保加密流量的安全性。一般运行在集群入口处，当流量到达入口处时实施 TLS 终止，入口与集群内服务器之间的通信将直接使用 HTTP 明文，这样可以提高服务性能。

Istio 默认在入口网关处终止 TLS，然后再为网格内的服务开启 mTLS。你也可以让流量直通（passthrough）到后端服务处理，例如：

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: sample-gateway
spec:
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: PASSTHROUGH
1
2
3
4
5
6
7
8
9
10
11
12

什么时候用 mTLS？

互联网客户端对 Web 服务的访问，一般使用单向 TLS，即只需要服务端提供身份证明，而不关心客户端的身份。当你需要验证客户端身份时，使用单向 TLS 可以使用密码、token、双因子认证等方式。不过这样的认证方式需要应用程序内部支持，而双向 TLS 是运行在应用程序之外的，不需要多应用逻辑进行修改。

1. 实施 mTLS 的服务间需要交换证书，当服务数量变大时，就需要管理大量的证书，这需要消耗大量的精力，使用服务网格可以帮助你实现自动 mTLS，彻底解决证书管理的难题。
2. 微服务通信：在微服务架构中，各个服务之间的通信可能需要更严格的安全性要求，mTLS 可用于确保服务之间的双向身份验证和通信加密。
3. API 访问控制：在 API 访问控制中，服务端可以要求客户端提供证书进行身份验证，确保只有授权的客户端可以访问 API。
4. 云原生环境：在容器化和云原生环境中，mTLS 可用于保护容器间的通信，确保容器之间的安全通信。
5. 内部通信：适用于内部系统或服务之间的通信，要求更高级别的安全性和身份验证。
   

什么时候不用 mTLS？

虽然 mTLS 是确保云原生应用程序服务间通信安全的首选协议，但是应用 mTLS 需要完成复杂的对称加密、解密过程，这将非常耗时且消耗大量的 CPU 资源。
对于某些安全级别不高的流量，如果我们在流量入口处终止 TLS，并网格内部仅对针对性的服务开启 mTLS，就可以加快请求响应和减少计算资源消耗。

流量加密

Istio流量主要包含入口流量和内部流量，入口流量是需要TLS进行加密的，加密解密过程是需要消耗CPU资源的，若是集群规模比较大内部服务多，内部流量

1. 外部入站流量 这是被 Sidecar 捕获的来自外部客户端的流量。 如果客户端在网格外面，该流量可能被 Istio 双向 TLS 加密。 Sidecar 默认配置 PERMISSIVE （宽容）模式：接受 mTLS 和 non-mTLS 的流量。 该模式能够变更为 STRICT （严格）模式，该模式下的流量流量必须是 mTLS；或者变更为 DISABLE （禁用）模式， 该模式下的流量必须为明文。mTLS 模式使用 PeerAuthentication资源配置。
2. 内部入站流量 这是从 Sidecar 流出并引入您的应用服务的流量。流量会保持原样转发。 注意这并不意味着它总是明文状态，Sidecar 可能也通过 TLS 连接。 这只意味着一个新的 TLS 连接将不会从 Sidecar 中产生。
3. 内部出站流量 这是被 Sidecar 拦截的来自您的应用服务的流量。 您的应用可能发送明文或者 TLS 的流量。 如果自动选择协议已开启，Istio 将能够自动地选择协议。 否则您可以在目标服务内使用端口名手动指定协议。
4. 外部出站流量 这是离开 Sidecar 到一些外部目标的流量。流量会报错原样转发，也可以启动一个 TLS 连接（mTLS 或者标准 TLS）。 这可以通过 DestinationRule资源中的 trafficPolicy 来控制使用的 TLS 模式。 模式设置为 DISABLE 将发生明文，而 SIMPLE、MUTUAL 和 ISTIO_MUTUAL 模式将会发起一个 TLS 连接。

关键要点是：

• PeerAuthentication 用于配置 Sidecar 接收的 mTLS 流量类型。
• DestinationRule 用于配置 Sidecar 发送的 TLS 流量类型。
• 端口名，或者自动选择协议，决定 sidecar 解析流量的协议。
  

入口流量加密

理解 TLS 配置
作为入站请求的一部分，网关必须对流量进行解码才能应用路由规则。 网关根据 Gateway资源中的服务配置解码。 例如，如果入站连接是明文的 HTTP，则端口协议配置成 HTTP：

apiVersion: networking.istio.io/v1beta1
kind: Gateway
...
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
1
2
3
4
5
6
7
8

同样，对于原始 TCP 流量，协议将设置为 TCP。
对于 TLS 连接，还有更多选项：

1. 封装了什么协议？ 如果连接是 HTTPS，服务协议应该配置成 HTTPS。 反之，对于使用 TLS 封装的原始 TCP 连接，协议应设置为 TLS。
2. TLS 连接是终止还是通过？ 对于直通流量，将 TLS 模式字段配置为 PASSTHROUGH：

apiVersion: networking.istio.io/v1beta1
kind: Gateway
...
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: PASSTHROUGH
1
2
3
4
5
6
7
8
9
10

在这种模式下，Istio 将根据 SNI 信息进行路由并将请求按原样转发到目的地。

3. 是否应该使用双向 TLS ？ 相互 TLS 可以通过 TLS 模式 MUTUAL 进行配置。配置后，客户端证书将根据配置的 caCertificates 或 credentialName 请求和验证：

apiVersion: networking.istio.io/v1beta1
kind: Gateway
...
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: MUTUAL
      caCertificates: ...
1
2
3
4
5
6
7
8
9
10
11

内部流量加密

如何理解 Istio 中的 mTLS 流量加密？
tio 的对等认证默认使用 PERMISSIVE 模式，自动将 mTLS 流量发送到这些工作负载，将纯文本流量发送到没有 sidecar 的工作负载。在将 Kubernetes 服务纳入 Istio 网格后，为了防止服务无法通过 mTLS，我们可以先使用 PERMISSIVE 模式。当我想为某些服务开启严格的 mTLS 模式时，可以使用以下两种方式之一：

• 使用 PeerAuthentication 定义流量如何在 sidecar 之间传输；
• 使用 DestinationRule 定义流量路由策略中的 TLS 设置；
  

PeerAuthentication 为工作负载设置 mTLS

你可以使用 namespace 和 selector 指定某个命名空间下的某个工作负载开启严格的 mTLS。例如下面的配置：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: foo-peer-policy
  namespace: default
spec:
  selector:
    matchLabels:
      app: reviews
  mtls:
    mode: STRICT
1
2
3
4
5
6
7
8
9
10
11

你也可以给安装 Istio 的命名空间 istio-system 设置严格的 mTLS，那样会为网格中的所有服务开启严格的 mTLS，详细步骤请参考 Istio 文档 。

PeerAuthentication 中指定对目标工作负载实施的 mTLS 模式。对等认证支持以下模式：

• PERMISSIVE：默认值，工作负载可接受双向 TLS 或纯文本流量；
• STRICT：工作负载仅接受 mTLS 流量；
• DISABLE：禁用 mTLS。从安全角度来看，除非你有自己的安全解决方案，否则不应禁用 mTLS；
• UNSET：从父级继承，优先级为服务特定 > 命名空间范围 > 网格范围的设置；
  

DestinationRule 为工作负载设置 mTLS

DestinationRule 用于设置流量路由策略，例如负载均衡、异常点检测、TLS 设置等。其中 TLS 设置中包含多种模式 ，使用 ISTIO_MUTUAL 模式可以为工作负载开启 Istio 的自动 TLS，如下所示。

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
  namespace: default
spec:
  host: reviews
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
1
2
3
4
5
6
7
8
9
10

安全最佳实战

参考官网：安全最佳实践 安全策略示例
安全中通常会匹配那些路径能访问，通常这些访问路径研发人员才知道，若全是交给技术设施人员比较吃力，此处小编建议使用SpringcloudGateway网关进行路由规则的配置。istio人员只需配置限制的域名，流量加密鉴权等。在内部服务对安全要求较高的服务上加mTLS，网关入口终止TLS。