文章目录
- [TLS 和 mTLS](#TLS 和 mTLS)
-
- [TLS 和 mTLS使用场景](#TLS 和 mTLS使用场景)
- [TLS 加密通信的流程](#TLS 加密通信的流程)
- [终止 TLS](#终止 TLS)
- [什么时候用 mTLS?](#什么时候用 mTLS?)
- [什么时候不用 mTLS?](#什么时候不用 mTLS?)
- 流量加密
- 安全最佳实战
TLS 和 mTLS
TLS(Transport Layer Security)和 mTLS(mutual TLS)都是用于加密通信的协议,用于保护数据在网络上的传输安全。它们在保护通信方面有一些区别:
- TLS(Transport Layer Security) :
- TLS 是一种加密通信协议,用于在网络上安全地传输数据。它用于建立安全的通信通道,确保数据在传输过程中不被篡改或窃取。
- TLS 通常用于客户端和服务器之间的通信,并且只要求服务器端提供证书,客户端验证服务器身份。
- 在 Web 安全中,HTTPS(HTTP over TLS)就是使用 TLS 来加密 HTTP 通信的协议。
- mTLS(mutual TLS) :
- mTLS 是 TLS 的一种扩展,也称为双向 TLS 或双向认证。它要求通信双方(客户端和服务器)都提供证书,进行相互验证身份。
- 在 mTLS 中,不仅服务器验证客户端的身份,客户端也验证服务器的身份。这种双向验证确保了通信的双方都是可信的,并且加强了通信的安全性。
主要区别在于 TLS 通常是单向验证,而 mTLS 是双向验证。mTLS 提供了更高级别的安全性,因为它不仅验证服务器的身份,还验证客户端的身份,确保了通信的完整性和安全性。
在网络安全领域,mTLS 通常用于要求更严格的安全标准的场景,如微服务之间的通信、API 访问控制等。通过使用 mTLS,可以确保通信双方的身份验证和通信数据的加密,提高了通信的安全性和可靠性。
TLS 和 mTLS使用场景
TLS(Transport Layer Security)和 mTLS(mutual TLS)在网络通信中有不同的使用场景,根据安全需求和通信模型的不同,选择合适的加密方式非常重要:
TLS 使用场景:
- Web通信:TLS 在 Web 通信中广泛应用,用于加密 HTTP 通信,形成 HTTPS 协议,保护 Web 应用的数据传输安全。
- 客户端-服务器通信:在传统的客户端-服务器模型中,服务器通常会提供证书,客户端验证服务器的身份,确保通信的安全性。
- 加密数据传输:TLS 可用于保护数据在网络上的传输,确保数据在传输过程中不被篡改或窃取。
- 保护隐私数据:适用于需要保护用户隐私数据的应用场景,如登录、支付等敏感操作。
mTLS 使用场景:
- 微服务通信:在微服务架构中,各个服务之间的通信可能需要更严格的安全性要求,mTLS 可用于确保服务之间的双向身份验证和通信加密。
- API 访问控制:在 API 访问控制中,服务端可以要求客户端提供证书进行身份验证,确保只有授权的客户端可以访问 API。
- 云原生环境:在容器化和云原生环境中,mTLS 可用于保护容器间的通信,确保容器之间的安全通信。
- 内部通信:适用于内部系统或服务之间的通信,要求更高级别的安全性和身份验证。
总的来说,TLS 适用于大多数常规的加密通信场景,而 mTLS 则适用于对通信安全性要求更高、需要双向身份验证的场景,如微服务架构、API 访问控制等。选择合适的加密方式取决于您的安全需求和通信模型。
TLS 加密通信的流程
- 服务器向受信任的 CA(证书管理机构)申请并获得证书(X.509 证书);
- 客户端向服务端发起请求,其中包含客户端支持的 TLS 版本和密码组合等信息;
- 服务器回应客户端请求并附上数字证书;
- 客户端验证证书的状态、有效期和数字签名等信息,确认服务器的身份;
- 客户端和服务器使用共享秘钥实现加密通信;
参考:TLS 握手期间会发生什么?
写给 Kubernetes 工程师的 mTLS 指南 | 云原生资料库
终止 TLS
TLS 终止(TLS Termination)指的是在将 TLS 加密流量传递给 Web 服务器之前对其进行解密的过程。将 TLS 流量卸载到入口网关或专用设备上,可以提高 Web 应用的性能,同时确保加密流量的安全性。一般运行在集群入口处,当流量到达入口处时实施 TLS 终止,入口与集群内服务器之间的通信将直接使用 HTTP 明文,这样可以提高服务性能。
Istio 默认在入口网关处终止 TLS,然后再为网格内的服务开启 mTLS。你也可以让流量直通(passthrough)到后端服务处理,例如:
yaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: sample-gateway
spec:
servers:
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: PASSTHROUGH
什么时候用 mTLS?
互联网客户端对 Web 服务的访问,一般使用单向 TLS,即只需要服务端提供身份证明,而不关心客户端的身份。当你需要验证客户端身份时,使用单向 TLS 可以使用密码、token、双因子认证等方式。不过这样的认证方式需要应用程序内部支持,而双向 TLS 是运行在应用程序之外的,不需要多应用逻辑进行修改。
- 实施 mTLS 的服务间需要交换证书,当服务数量变大时,就需要管理大量的证书,这需要消耗大量的精力,使用服务网格可以帮助你实现自动 mTLS,彻底解决证书管理的难题。
- 微服务通信:在微服务架构中,各个服务之间的通信可能需要更严格的安全性要求,mTLS 可用于确保服务之间的双向身份验证和通信加密。
- API 访问控制:在 API 访问控制中,服务端可以要求客户端提供证书进行身份验证,确保只有授权的客户端可以访问 API。
- 云原生环境:在容器化和云原生环境中,mTLS 可用于保护容器间的通信,确保容器之间的安全通信。
- 内部通信 :适用于内部系统或服务之间的通信,要求更高级别的安全性和身份验证。
什么时候不用 mTLS?
虽然 mTLS 是确保云原生应用程序服务间通信安全的首选协议,但是应用 mTLS 需要完成复杂的对称加密、解密过程,这将非常耗时且消耗大量的 CPU 资源。
对于某些安全级别不高的流量,如果我们在流量入口处终止 TLS,并网格内部仅对针对性的服务开启 mTLS,就可以加快请求响应和减少计算资源消耗。
流量加密
Istio流量主要包含入口流量和内部流量,入口流量是需要TLS进行加密的,加密解密过程是需要消耗CPU资源的,若是集群规模比较大内部服务多,内部流量
- 外部入站流量 这是被 Sidecar 捕获的来自外部客户端的流量。 如果客户端在网格外面,该流量可能被 Istio 双向 TLS 加密。 Sidecar 默认配置 PERMISSIVE (宽容)模式:接受 mTLS 和 non-mTLS 的流量。 该模式能够变更为 STRICT (严格)模式,该模式下的流量流量必须是 mTLS;或者变更为 DISABLE (禁用)模式, 该模式下的流量必须为明文。mTLS 模式使用 PeerAuthentication资源配置。
- 内部入站流量 这是从 Sidecar 流出并引入您的应用服务的流量。流量会保持原样转发。 注意这并不意味着它总是明文状态,Sidecar 可能也通过 TLS 连接。 这只意味着一个新的 TLS 连接将不会从 Sidecar 中产生。
- 内部出站流量 这是被 Sidecar 拦截的来自您的应用服务的流量。 您的应用可能发送明文或者 TLS 的流量。 如果自动选择协议已开启,Istio 将能够自动地选择协议。 否则您可以在目标服务内使用端口名手动指定协议。
- 外部出站流量 这是离开 Sidecar 到一些外部目标的流量。流量会报错原样转发,也可以启动一个 TLS 连接(mTLS 或者标准 TLS)。 这可以通过 DestinationRule资源中的 trafficPolicy 来控制使用的 TLS 模式。 模式设置为 DISABLE 将发生明文,而 SIMPLE、MUTUAL 和 ISTIO_MUTUAL 模式将会发起一个 TLS 连接。
关键要点是:
- PeerAuthentication 用于配置 Sidecar 接收的 mTLS 流量类型。
- DestinationRule 用于配置 Sidecar 发送的 TLS 流量类型。
- 端口名,或者自动选择协议,决定 sidecar 解析流量的协议。
入口流量加密
作为入站请求的一部分,网关必须对流量进行解码才能应用路由规则。 网关根据 Gateway资源中的服务配置解码。 例如,如果入站连接是明文的 HTTP,则端口协议配置成 HTTP:
yaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway
...
servers:
- port:
number: 80
name: http
protocol: HTTP
同样,对于原始 TCP 流量,协议将设置为 TCP。
对于 TLS 连接,还有更多选项:
- 封装了什么协议? 如果连接是 HTTPS,服务协议应该配置成 HTTPS。 反之,对于使用 TLS 封装的原始 TCP 连接,协议应设置为 TLS。
- TLS 连接是终止还是通过? 对于直通流量,将 TLS 模式字段配置为 PASSTHROUGH:
yaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway
...
servers:
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: PASSTHROUGH
在这种模式下,Istio 将根据 SNI 信息进行路由并将请求按原样转发到目的地。
- 是否应该使用双向 TLS ? 相互 TLS 可以通过 TLS 模式 MUTUAL 进行配置。配置后,客户端证书将根据配置的 caCertificates 或 credentialName 请求和验证:
yaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway
...
servers:
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: MUTUAL
caCertificates: ...
内部流量加密
tio 的对等认证默认使用 PERMISSIVE 模式,自动将 mTLS 流量发送到这些工作负载,将纯文本流量发送到没有 sidecar 的工作负载。在将 Kubernetes 服务纳入 Istio 网格后,为了防止服务无法通过 mTLS,我们可以先使用 PERMISSIVE 模式。当我想为某些服务开启严格的 mTLS 模式时,可以使用以下两种方式之一:
- 使用 PeerAuthentication 定义流量如何在 sidecar 之间传输;
- 使用 DestinationRule 定义流量路由策略中的 TLS 设置;
PeerAuthentication 为工作负载设置 mTLS
你可以使用 namespace 和 selector 指定某个命名空间下的某个工作负载开启严格的 mTLS。例如下面的配置:
yaml
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: foo-peer-policy
namespace: default
spec:
selector:
matchLabels:
app: reviews
mtls:
mode: STRICT
你也可以给安装 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,如下所示。
yaml
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: reviews
namespace: default
spec:
host: reviews
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
安全最佳实战
安全中通常会匹配那些路径能访问,通常这些访问路径研发人员才知道,若全是交给技术设施人员比较吃力,此处小编建议使用SpringcloudGateway网关进行路由规则的配置。istio人员只需配置限制的域名,流量加密鉴权等。在内部服务对安全要求较高的服务上加mTLS,网关入口终止TLS。