智汇华云 | Istio中双向TLS认证功能详解

3 S* s, q/ V+ P& W4 ~                               
登录/注册后可看大图

一、概述
: R+ o9 T  l/ i& R
! I" F; ^, S. j- iIstio中实现了从客户端到服务器端的全链路加密功能，首先从外部的客户端发起请求，到达Istio的Ingress Proxy，后者作为整个集群的边界网关，会再将请求转发到集群内部的微服务，在集群内部，一般会涉及到多个微服务之间的交互，形成一个调用链。

5 W5 M- |) R- r# R) m7 }1 j在很多架构模型中，集群内部会被认为是天然安全的，微服务之间的流量也是明文传输的。这种模型现在受到越来越多的质疑，因此诸如很多公有云都实现了"零信任"网络，全链路加密的功能。
' }5 V$ p6 V, L: w: s
5 q7 o, s% V& `本文会详细分析在一个集群内部，如何通过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。

4 g/ x4 [% i% S6 s# a1 k                               
登录/注册后可看大图

在Envoy Proxy A与Envoy Proxy B之间认证的过程对于Pod A或者Pod B而言都是无感知的。

Istio中双向tls认证的基本对象是

apiVersion: security.istio.io/v1beta1
" x' l2 v* `7 s7 H5 zkind: PeerAuthentication
  G$ A  n  W+ Z  i, Y4 ^, ^
二、认证配置的策略类型
! t7 R7 u7 b7 ?0 @& c0 K在具体进行配置的时候，有四种基本的策略
2 k5 h( L+ }; W- ~
4 y' S$ o3 W% [, ?, }●DISABLE

即禁用双向tls认证，这种情况下源Envoy与目的Envoy之间没有对对方进行身份的安全确认，它们之间发送的都是明文数据
1 X) r7 X9 e5 M
●STRICT
$ x6 u6 n6 Q( `  |' I+ E; H
" d; j0 h5 |  A% ~即严格的双向tls认证模式。源Envoy与目的Envoy之间必须对对方进行身份的安全确认，它们之间发送的都是加密后的数据。

/ X% B0 o4 R& b) W% b0 F+ A; U" t% k0 ~●PERMISSIVE

. S& S- H' J) |* z! v可以进行双向tls认证、也可以不进行认证从而发送明文数据。

1 w& p* i, [' f●UNSET

即没有进行设置，这种情况下会继承上级策略，比如当前namespace的或者整个系统的。如果上级策略都为空，则会默认设置为PERMISSIVE
8 U) x4 e6 Z) t4 v* t
三、认证配置的范围
: s0 s+ ]+ a4 ?0 o  V1 @Istio中对双向tls认证进行配置的时候，可以有几种不同的范围，范围越小优先级越高：

; n5 _3 J7 j4 G+ ^●全局
/ `5 V" O2 r; ~" g: |3 U: x8 s% v# K# ]  apiVersion: security.istio.io/v1beta1
  kind: PeerAuthentication
  metadata:
    name: default
/ L2 s1 v( G1 j/ }, {    namespace: istio-system
9 B0 W( T- ^  u5 _  spec:
    mtls:
- o! N* b5 A. S      mode: STRICT
- K5 d- u! }, x$ Q. b
. @- r4 Q& [. ]3 I0 k注意，全局的安全策略名称只能是default，namespace则是istio所在的系统namespace，这里是istio-system
9 ?1 M% h9 T; F. B
●namespace级别，即某个namespace中所有服务
1 R, B. y0 y( L0 a( X7 @0 U9 y/ s0 N, Q
4 h5 n1 d' G8 q. T& E  apiVersion: security.istio.io/v1beta1
* F' o5 @, o: I( p; d) B  kind: PeerAuthentication
  metadata:
    name: default
0 s$ j3 t: T4 [% q4 Q' m8 _0 j    namespace: foo
  spec:
    mtls:
  \  u. f4 G- j$ I* G3 a      mode: PERMISSIVE
. |7 G% ~# O2 w
●负载级别，即某个namespace中某些具体的Pod

/ }. x5 i$ d; J# ]3 }) Z$ y0 [- i  apiVersion: security.istio.io/v1beta1
2 @8 R. ^* ]) w; H: u/ j& k7 w  kind: PeerAuthentication
" ]3 |% b' m5 W, `  metadata:
    name: default
    namespace: foo
: q; c8 \5 j- \: m3 J  spec:
1 U& b" k/ S; X$ U+ G; E- c    selector:
* U9 T& o: P; S      matchLabels:
& i% S8 b7 r+ @. U; G! b        app: finance
, @4 B5 B5 A% Z9 I" N8 g! v    mtls:
- e1 N, M: Z  K/ u9 b7 [5 M. W' P+ @6 [      mode: STRICT
! O6 }/ q# ^! o! k  f
会将带有"app: finance"label的Pod所在的Envoy实行STRICT模式。
# I+ L7 _# u$ E9 Q! M
●端口级别
9 p, S% y* M4 g! c5 `  apiVersion: security.istio.io/v1beta1
' M+ _0 a& i. |  kind: PeerAuthentication
: G; ?/ Q$ `- w/ Z. G  metadata:
/ o2 D" e( Q$ Y2 ]' t: q7 _    name: default
    namespace: foo
8 M9 ]; h1 q/ P: c9 m/ _  spec:
    selector:
      matchLabels:
6 Z9 L& w0 M0 _, S# A% j$ V( }! }0 J* D        app: finance
3 O; n" j8 }! Z) e$ Z    mtls:
      mode: STRICT
2 v3 e9 a6 @4 }$ p2 z2 ]; \    portLevelMtls:
4 j% G) }' r  A1 j" @3 c7 |8 l0 g      8080:
2 J* j$ V: I$ o! k        mode: DISABLE

# w; v0 y* p1 j3 H. [0 m1 U/ L/ F& }会将带有"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模式，需要配置两处
, _. `8 |1 A* l& W* K
1.服务器端配置，给服务B对应的负载配置PeerAuthentication策略，这里配置的是服务B所有关联Pod对应的Envoy Proxy。
! {" v/ s1 |% N; b* X, m" d' k6 s
' D8 x' w3 A1 ^- p: u) J   apiVersion: security.istio.io/v1beta1
   kind: PeerAuthentication
0 @, A! W+ w/ G% B& N8 \   metadata:
     name: default
- q; U: y9 H0 R5 z5 Y9 Y     namespace: foo
1 }" x, K3 h* N) W   spec:
9 U4 C+ z4 S5 `7 m1 y; X9 e% ?     selector:
       matchLabels:
         app: B
5 U  h& t: O( \5 g) w$ Y1 \# A     mtls:
0 y9 O8 d; e% e3 w" D+ q6 f       mode: STRICT
; S- {; g4 r+ g. F& E
2. 客户端配置，给服务B配置DestinationRule策略。这里配置的是所有访问服务B的Pod对应的Envoy Proxy。

  j) r  _  F0 @" U$ Y1 v+ Y/ j   cat <<EOF | kubectl apply -n foo -f -
( c* b- L1 t. V- ~. O3 P   apiVersion: "networking.istio.io/v1alpha3"
   kind: "DestinationRule"
) m  j1 t- ]1 Z! C2 v4 o   metadata:
1 R( W+ }) {$ }- F% R6 N     name: "B"
; K8 Q) D! B& d. B# g* B   spec:
6 ]+ ^$ P, l% |# E. @; ~; d     host: "B.foo.svc.cluster.local"
# @  W  j( t* t7 O3 K! V     trafficPolicy:
       tls:
4 S+ Q5 M( _; f% _, z0 {- k         mode: ISTIO_MUTUAL
( I4 z" [3 h! X; g  B   EOF
+ K  O4 L  i1 ]: b9 u: u: G! ]+ Z
; G, M8 z5 a) C5 d. y也就是说客户端配置的时候需要配置目的服务的DestinationRule对象，而服务器端配置的时候需要配置服务器端对应负载的PeerAuthentication对象。
$ j. i6 d. k6 H( J% p五、测试case1：默认配置
/ V! o; _: v! q  b# h9 Y; `kubectl create ns foo
kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n foo
kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n foo
kubectl create ns bar
, n6 `) R3 d* z4 \' okubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n bar
kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n bar
kubectl create ns legacy
  D8 t, u+ O- H7 ~4 A8 d- mkubectl apply -f samples/httpbin/httpbin.yaml -n legacy
) R8 Q% H8 V, S( A/ }kubectl apply -f samples/sleep/sleep.yaml -n legacy
9 J2 A, p3 J& o' ?9 h
创建了3个namespace：foo, bar和legacy，每个namespace分别创建了sleep和httpbin两种应用，作为客户端和服务器端。在foo和bar中的Pod有对应的Envoy Proxy，而在legacy中则没有。下面是创建成功后的Pod情况
[root@master1 istio-1.6.0]# kubectl get pod --all-namespaces
6 E* S0 R0 W; \  S. w5 Z4 HNAMESPACE      NAME                                    READY   STATUS    RESTARTS   AGE
  _% `& e% m0 ~! d9 N9 \bar            httpbin-67576779c-tjl4m                 2/2     Running   0          31m
: \$ L$ u$ X, K4 T  Rbar            sleep-7dc44b8d45-rfhpl                  2/2     Running   0          31m
5 S: ^% s$ W6 H& ufoo            httpbin-67576779c-tw6kl                 2/2     Running   0          31m
foo            sleep-7dc44b8d45-87x2p                  2/2     Running   0          31m
legacy         httpbin-779c54bf49-h5wrw                1/1     Running   0          31m
( n+ Y, c: Z4 \: P) x) elegacy         sleep-f8cbf5b76-b8xgd                   1/1     Running   0          31m


- c8 A% s* R8 S3 ?6 P" m6 R在使用默认的default配置部署Istio的情况下，如果没有设置任何安全策略，默认是PERMISSIVE，即同时允许双向tls认证和不进行任何认证的明文传输两种方式。注意这只针对有Envoy Proxy的情况，因为这些策略最终的执行者是Envoy，而对于那些没有Envoy Proxy的Pod，例如legacy中的Pod，则只能使用明文方式进行收发数据。下面来验证这一点

1 u& x- k( _* k9 N. {, q[root@master1 istio-1.6.0]# for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
sleep.foo to httpbin.foo: 200
7 S) O8 I* u+ ^sleep.foo to httpbin.bar: 200
sleep.foo to httpbin.legacy: 200
7 X# P6 @6 `) U, p& Z+ Usleep.bar to httpbin.foo: 200
! I0 E' ?7 b( q0 Bsleep.bar to httpbin.bar: 200
) h/ o* H4 a5 Nsleep.bar to httpbin.legacy: 200
sleep.legacy to httpbin.foo: 200
6 n* `. z2 K7 Nsleep.legacy to httpbin.bar: 200
sleep.legacy to httpbin.legacy: 200
4 a; K4 N- a! |' e3 Z" A( z
! E  l( X+ t& C2 T可以看到任何两个sleep与httpbin之间都是可以连通的。但是如果进一步观察，发现这些认证方式其实是不同的
[root@master1 istio-1.6.0]# kubectl exec $(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name}) -c sleep -n foo -- curl http://httpbin.foo:8000/headers -s | grep X-Forwarded-Client-Cert
% B/ `' u* q( V1 e4 P" Z5 A% _8 w    "X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=41eb8aa0a91782fc1a09df8da85b586c5eaabbca3117f645cdb9df8d998b55f2;Subject=\"\";URI=spiffe://cluster.local/ns/foo/sa/sleep"

从foo中的sleep访问foo中的httpbin，header中带有"X-Forwarded-Client-Cert"表明使用了双向tls认证。
[root@master1 istio-1.6.0]# kubectl exec $(kubectl get pod -l app=sleep -n legacy -o jsonpath={.items..metadata.name}) -c sleep -n legacy -- curl http://httpbin.foo:8000/headers -s | grep X-Forwarded-Client-Cert
0 C' J1 F' k0 X1 K9 h: U4 w[root@master1 istio-1.6.0]#
3 \, X, _, V( Z
而从legacy中的sleep访问legacy中的httpbin，header中则不会带有"X-Forwarded-Client-Cert"，因为客户端和服务器端都没有Envoy Proxy，只能进行没有任何加密的明文传输。

0 R& @0 h; W  v/ q) f' G另外，还可以看出sleep.legacy发出去的请求都是明文数据，而sleep.httpbin收到的请求也都是明文数据。而foo和bar里面的Pod发送请求时则会优先使用双向tls认证方式(即下面四种)，这些可以自行测试验证。
sleep.foo to httpbin.foo: 200
/ E, e8 P0 R9 y6 {  o2 bsleep.foo to httpbin.bar: 200
sleep.bar to httpbin.foo: 200
# ?% k: Q. i6 x0 J- L& Bsleep.bar to httpbin.bar: 200

清理命令
7 i, @4 u1 O) I% V" X4 a: {; Hkubectl delete -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n foo
kubectl delete -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n foo
9 w9 w8 F' ~- r* j: U; Mkubectl delete -f samples/httpbin/httpbin.yaml -n legacy
kubectl delete -f samples/sleep/sleep.yaml -n legacy
, v) G; o2 \1 bkubectl delete -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n bar
kubectl delete -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n bar
kubectl delete ns foo
; q2 ~% w( K, [  n; ]) s" Bkubectl delete ns legacy
kubectl delete ns bar

, \7 }6 z0 f7 q: I) v5 X5 J六、测试case2：针对特定服务的配置
首先，创建一个全局的安全策略，禁用所有的双向tls认证。
- D% ^3 n0 F/ h3 e' [. _. x# s* Ekubectl apply -f - <<EOF
1 p$ E& Y  H, o; D0 eapiVersion: "security.istio.io/v1beta1"
. |; p* B7 X; q0 Y! H( Y1 `, Y+ ]# Vkind: "PeerAuthentication"
- V  [) P: o4 y9 a0 q2 p$ N% qmetadata:
, z5 [, z8 m7 f2 J4 {  name: "default"
  namespace: "istio-system"
" N9 R3 Y* l& g; X) Ispec:
  mtls:
/ E! q* y0 A. l: Z3 r! E7 P/ O1 z6 M# J    mode: DISABLE
EOF
, H$ w  ?( {" b2 A- l
  |8 G! L# R6 h+ G" t然后创建一个foo namespace，并在其中创建带有Envoy Proxy的sleep和httpbin
kubectl create ns foo
kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n foo
kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n foo
8 a4 u( ^* c8 A
这时进行测试，会发现他们之间可以正常访问，但没有使用双向tls认证，这符合预期，说明全局策略生效。
[root@master1 istio-1.6.0]# kubectl exec $(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name}) -c sleep -n foo -- curl "http://httpbin.foo:8000/ip" -s -o /dev/null -w "sleep.foo to httpbin.foo: %{http_code}\n"
& K$ ?# r$ Y( L+ z) `sleep.foo to httpbin.foo: 200
3 m! R0 W1 q) U+ y9 X1 |2 L[root@master1 istio-1.6.0]# kubectl exec $(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name}) -c sleep -n foo -- curl http://httpbin.foo:8000/headers -s | grep X-Forwarded-Client-Cert
[root@master1 istio-1.6.0]#
9 E  C+ M' H) c8 M) K7 H- m4 ~
接下来为服务器端配置PeerAuthentication策略，让其强制执行双向tls认证
7 N& s6 \7 a9 u% h! U9 {* m2 n: Zcat <<EOF | kubectl apply -n foo -f -
9 n0 i  ?; U+ k% J# capiVersion: "security.istio.io/v1beta1"
$ ?6 W; J+ P9 s; o6 L2 O& okind: "PeerAuthentication"
metadata:
  name: "httpbin"
  namespace: "foo"
spec:
0 X" F/ z. X% R3 C8 C1 N9 O  selector:
7 m( }* o% \5 L% a$ W0 l' |    matchLabels:
4 f& n- a1 K+ Y- }% Y      app: httpbin
) }; I" [2 e% q$ w' c  mtls:
    mode: STRICT
EOF

这时再次进行测试
[root@master1 istio-1.6.0]# kubectl exec $(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name}) -c sleep -n foo -- curl "http://httpbin.foo:8000/ip" -s -o /dev/null -w "sleep.foo to httpbin.foo: %{http_code}\n"
sleep.foo to httpbin.foo: 503
[root@master1 istio-1.6.0]#

出现了503错误，这其实是一个tls冲突，因为截至目前为止我们为服务器端设置了强制使用双向tls认证，但是客户端还未设置。
, V# ^2 ^  v: t& j+ |. T- b
9 l* c& J/ G; P/ c! z+ S接下来设置客户端。
cat <<EOF | kubectl apply -n foo -f -
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
* x0 S1 @+ t. Y4 @0 Fmetadata:
+ r. G* }0 G. o* D2 v  name: "httpbin"
; m3 j! u) `9 Hspec:
4 q- [$ M7 ]2 \" e% O$ }" K8 `  host: "httpbin.foo.svc.cluster.local"
/ ?0 Z; q0 G, D5 x/ g/ v  trafficPolicy:
) T2 t* n- C4 j! L. j+ i    tls:
      mode: ISTIO_MUTUAL
( S6 X. l  _/ H. h: M9 c9 HEOF

然后进行测试，发现现在已经可以正常访问，且使用了双向tls认证，符合预期。
[root@master1 istio-1.6.0]# kubectl exec $(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name}) -c sleep -n foo -- curl "http://httpbin.foo:8000/ip" -s -o /dev/null -w "sleep.foo to httpbin.foo: %{http_code}\n"
sleep.foo to httpbin.foo: 200
[root@master1 istio-1.6.0]# kubectl exec $(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name}) -c sleep -n foo -- curl http://httpbin.foo:8000/headers -s | grep X-Forwarded-Client-Cert
8 w. I' z# `5 H" t$ Z; F    "X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=b8a73b2655b270e23eda820e49c56cc9b16521d98cb6c1896eff41c58cc32d56;Subject=\"\";URI=spiffe://cluster.local/ns/foo/sa/sleep"
[root@master1 istio-1.6.0]#
" X- e3 C& [7 h! g$ s" z
清理命令

; a* V! |% O1 qkubectl delete PeerAuthentication httpbin -n foo
5 N$ E" E- x! gkubectl delete DestinationRule httpbin -n foo
2 T% }& J* [( y" R5 j5 dkubectl delete -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n foo
$ w* H' @8 `) c5 `! Okubectl delete -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n foo
# [, k9 g1 Q/ b9 ]( ?kubectl delete ns foo

( Z" m, h" k5 h0 N7 k! W. L1 D) J