智汇华云 | Istio中双向TLS认证功能详解
文章插图
一、概述
Istio中实现了从客户端到服务器端的全链路加密功能 , 首先从外部的客户端发起请求 , 到达Istio的Ingress Proxy , 后者作为整个集群的边界网关 , 会再将请求转发到集群内部的微服务 , 在集群内部 , 一般会涉及到多个微服务之间的交互 , 形成一个调用链 。
在很多架构模型中 , 集群内部会被认为是天然安全的 , 微服务之间的流量也是明文传输的 。 这种模型现在受到越来越多的质疑 , 因此诸如很多公有云都实现了"零信任"网络 , 全链路加密的功能 。
本文会详细分析在一个集群内部 , 如何通过Istio实现服务之间通信数据的加密 。 Istio中的加密方式是双向tls的认证 , 具体是指两个Envoy Proxy之间的首先进行双向tls认证 , 认证通过后将后续的数据流进行加密传输 。
例如:Pod A需要访问Pod B , 在Istio中 , 请求都是由Envoy进行代理的 , 因此完整的流程是Pod A发出到Pod B的请求 , 然后请求会被Envoy Proxy A劫持 , 接着Envoy Proxy A会与Envoy Proxy B进行点对点的认证 , 认证通过后 , 数据会进行加密传输 , 请求会由Envoy Proxy A发送给Envoy Proxy B , 最后再由Envoy Proxy B将请求转发给Pod B 。
文章插图
在Envoy Proxy A与Envoy Proxy B之间认证的过程对于Pod A或者Pod B而言都是无感知的 。
Istio中双向tls认证的基本对象是
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
二、认证配置的策略类型
在具体进行配置的时候 , 有四种基本的策略
DISABLE
即禁用双向tls认证 , 这种情况下源Envoy与目的Envoy之间没有对对方进行身份的安全确认 , 它们之间发送的都是明文数据
STRICT
即严格的双向tls认证模式 。 源Envoy与目的Envoy之间必须对对方进行身份的安全确认 , 它们之间发送的都是加密后的数据 。
PERMISSIVE
可以进行双向tls认证、也可以不进行认证从而发送明文数据 。
UNSET
即没有进行设置 , 这种情况下会继承上级策略 , 比如当前namespace的或者整个系统的 。 如果上级策略都为空 , 则会默认设置为PERMISSIVE
三、认证配置的范围
【智汇华云 | Istio中双向TLS认证功能详解】Istio中对双向tls认证进行配置的时候 , 可以有几种不同的范围 , 范围越小优先级越高:
全局
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: istio-system
spec:
mtls:
mode: STRICT
注意 , 全局的安全策略名称只能是default , namespace则是istio所在的系统namespace , 这里是istio-system
namespace级别 , 即某个namespace中所有服务
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: foo
spec:
mtls:
mode: PERMISSIVE
负载级别 , 即某个namespace中某些具体的Pod
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: foo
spec:
selector:
matchLabels:
app: finance
mtls:
mode: STRICT
会将带有"app: finance"label的Pod所在的Envoy实行STRICT模式 。
端口级别
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: foo
spec:
selector:
matchLabels:
app: finance
mtls:
mode: STRICT
portLevelMtls:
8080:
mode: DISABLE
会将带有"app: finance"label的Pod所在的Envoy实行STRICT模式 , 但是会将其中的8080端口使用DISABLE模式 。
四、认证配置的具体方法
在Istio中进行双向tls认证配置 , 需要注意的是客户端和服务器端配置方法是不一样的 。 例如在namespace foo中有两组服务A和B , 每组都有一些Pod , 假设服务A的Pod对应的label为"app: A" , 而服务B的Pod对应的label为"app: B" 。 这时在服务A所在的Pod中访问服务B , 要将这一请求设置为STRICT模式 , 需要配置两处
服务器端配置 , 给服务B对应的负载配置PeerAuthentication策略 , 这里配置的是服务B所有关联Pod对应的Envoy Proxy 。
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: foo
spec:
selector:
matchLabels:
app: B
mtls:
mode: STRICT
2. 客户端配置 , 给服务B配置DestinationRule策略 。 这里配置的是所有访问服务B的Pod对应的Envoy Proxy 。
cat
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
- 共赴“科创”盛宴 同享“智汇”金华
- 多集群istio service mesh--共享控制平面
- 华云大咖说丨安超云基座助力智慧医疗
- 竹海热线网|中数智汇11月27日首发上会 核心技术和人才助力闯关IPO
- 智汇德州|山东大学史泽露:让微生物技术走出实验室,护航德州企业绿色发展
- Istio之Sidecar注入
- 【智汇长三角 科创太湖湾】这一次,杭州又被“创新”PICK了!
- 当AI赋能攻防,华云安发布智能化渗透攻防系统
- Istio安全性
- 服务|Service Mesh框架对比:Linkerd vs. Istio