istio 1.10学习笔记13: 使用认证策略设置双向TLS和基本的终端用户认证
2021-07-30
前面3~12节学习了istio的流量管理功能，包括如何配置请求路由、故障注入、流量转移、流量镜像、设置请求超时和熔断、将服务网格外部流量接入到集群内、控制服务网格的出口流量等。 从本节开始学习istio的安全管理功能，看istio是如何保护服务网格内的微服务的。本节将根据istio官方文档https://istio.io/latest/zh/docs/tasks/security/authentication/authn-policy/中的内容，学习使用istio的认证策略来设置双向TLS和基本的终端用户认证。
环境准备 #
创建foo, bar两个命名空间，并开启istio sidecar代理自动注入:
1kubectl create ns foo
2kubectl label namespace foo istio-injection=enabled
3
4
5kubectl create ns bar
6kubectl label namespace bar istio-injection=enabled
分别在foo, bar两个命名空间内部署httpbin服务和启动一个radial/busyboxplus:curl容器的pod。httpbin和curl都将被自动注入isito envoy sidecar代理。
1kubectl apply -f samples/httpbin/httpbin.yaml -n foo
2kubectl run curl --image=radial/busyboxplus:curl -it -n foo
3
4kubectl apply -f samples/httpbin/httpbin.yaml -n bar
5kubectl run curl --image=radial/busyboxplus:curl -it -n bar
创建一个legacy命名空间，不开启isito sidecar自动注入，在该命名空间内部署部署httpbin服务和curl服务，它们将不会有sidecar代理。
1kubectl create ns legacy
2kubectl apply -f samples/httpbin/httpbin.yaml -n legacy
3kubectl run curl --image=radial/busyboxplus:curl -it -n legacy
测试在foo, bar, legacy三个命名空间中的curl pod内都可以使用curl向httpbin.foo, httpbin.bar, httpbin.legacy发送http请求，都成功返回200。
1for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec curl -c curl -n ${from} -- curl -s "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}\n"; done; done
2curl.foo to httpbin.foo: 200
3curl.foo to httpbin.bar: 200
4curl.foo to httpbin.legacy: 200
5curl.bar to httpbin.foo: 200
6curl.bar to httpbin.bar: 200
7curl.bar to httpbin.legacy: 200
8curl.legacy to httpbin.foo: 200
9curl.legacy to httpbin.bar: 200
10curl.legacy to httpbin.legacy: 200
使用以下命令确认系统中没有对等身份验证(peerauthentication)策略：
1kubectl get peerauthentication --all-namespaces
2No resources found
默认的"自动双向TLS认证" #
默认情况下，Istio会跟踪迁移到Istio代理的服务器工作负载并配置客户端代理，将双向TLS流量自动发送到这些工作负载，并将plain-text流量发送到没有sidecar的工作负载。
也就是说，在默认情况下，无需做额外配置，具有sidecar代理的工作负载(如命名空间foo中的curl和httpbin)之间的所有流量都将自动开启双向TLS。可以检查httpbin/header的响应。自动开启了双向TLS时，代理会将X-Forwarded-Client-Cert请求头注入到后端的upstream请求。
即有X-Forwarded-Client-Cert这个请求头，则说明开启了双向TLS。
1kubectl exec curl -c curl -n foo -- curl -s http://httpbin.foo:8000/headers -s | grep X-Forwarded-Client-Cert | sed 's/Hash=[a-z0-9]*;/Hash=<redacted>;/'
2 "X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=<redacted>;Subject=\"\";URI=spiffe://cluster.local/ns/foo/sa/default"
当服务端工作负载没有sidecar代理时(如命名空间legacy中的httbin)，则客户端到此工作负载的请求将会是plain-text的，X-Forwarded-Client-Cert请求头将不会存在。
1kubectl exec curl -c curl -n foo -- curl -s http://httpbin.legacy:8000/headers -s | grep X-Forwarded-Client-Cert | sed 's/Hash=[a-z0-9]*;/Hash=<redacted>;/'
配置全局严格模式启用istio双向TLS #
前面学习了具有sidecar代理的工作负载之间将自动启用双向TLS认证，但工作负载仍然可以接收plain-text流量。可以通过将整个服务网格的对等认证策略(PeerAuthentication)设置为STRICT模式，以阻止整个网格的服务以非双向TLS通信。
如下所示，全局的对等认证策略是没有selector的，且它必须位于安装istio的根命名空间内(如istio-system)。
1kubectl apply -f - <<EOF
2apiVersion: security.istio.io/v1beta1
3kind: PeerAuthentication
4metadata:
5 name: "default"
6 namespace: "istio-system"
7spec:
8 mtls:
9 mode: STRICT
10EOF
再次测试在foo, bar, legacy三个命名空间中的curl pod内都可以使用curl向httpbin.foo, httpbin.bar, httpbin.legacy发送http请求：
1for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec curl -c curl -n ${from} -- curl -s "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}\n"; done; done
2
3curl.foo to httpbin.foo: 200
4curl.foo to httpbin.bar: 200
5curl.foo to httpbin.legacy: 200
6curl.bar to httpbin.foo: 200
7curl.bar to httpbin.bar: 200
8curl.bar to httpbin.legacy: 200
9curl.legacy to httpbin.foo: 000
10command terminated with exit code 56
11curl.legacy to httpbin.bar: 000
12command terminated with exit code 56
13curl.legacy to httpbin.legacy: 200
会发现没有sidecar代理的curl.legacy到有sidecar代理的httpbin.foo和httpbin.bar的请求将会失败，因为全局的对等认证策略是严格模式，要求客户端与httpbin.foo和httpbin.bar之间的流量必须是双向TLS的。
命名空间级别的双向TLS和工作负载级别的双向TLS #
如果你觉得全局开启双向TLS太严格了，还可以为每个命名空间或者工作负载启用双向TLS。
在测试前先删除前面创建的全局对等认证策略:
1kubectl delete peerauthentication -n istio-system default
创建命名空间级别的对等认证策略，只需要在metadata字段中指定具体的命名空间即可:
1kubectl apply -f - <<EOF
2apiVersion: security.istio.io/v1beta1
3kind: PeerAuthentication
4metadata:
5 name: "default"
6 namespace: "foo"
7spec:
8 mtls:
9 mode: STRICT
10EOF
因为上面创建的这个策略只应用于命名空间foo中的服务，再次测试在foo, bar, legacy三个命名空间中的curl pod内都可以使用curl向httpbin.foo, httpbin.bar, httpbin.legacy发送http请求。
会发现只有从没有sidecar代理的(curl.legacy)到有sidecar的代理的httpbin.foo的请求会失败。
1for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec curl -c curl -n ${from} -- curl -s "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}\n"; done; done
2
3curl.foo to httpbin.foo: 200
4curl.foo to httpbin.bar: 200
5curl.foo to httpbin.legacy: 200
6curl.bar to httpbin.foo: 200
7curl.bar to httpbin.bar: 200
8curl.bar to httpbin.legacy: 200
9curl.legacy to httpbin.foo: 000
10command terminated with exit code 56
11curl.legacy to httpbin.bar: 200
12curl.legacy to httpbin.legacy: 200
下面演示为特定工作负载启用双向TLS。要为特定工作负载设置对等身份验证策略，必须配置selector字段并指定与所需工作负载匹配的标签。然而Istio不能将出站双向TLS流量的工作负载策略聚合到服务。
应该通过配置目标规则destinationrule来管理该行为。
在测试之前，先删除前面创建的命名空间级别的认证策略:
1kubectl delete PeerAuthentication default -n foo
下面创建对等认证策略，并使用selector将策略应用于httpbin.bar:
1cat <<EOF | kubectl apply -n bar -f -
2apiVersion: security.istio.io/v1beta1
3kind: PeerAuthentication
4metadata:
5 name: "httpbin"
6 namespace: "bar"
7spec:
8 selector:
9 matchLabels:
10 app: httpbin
11 mtls:
12 mode: STRICT
13EOF
添加一个目标规则:
1cat <<EOF | kubectl apply -n bar -f -
2apiVersion: networking.istio.io/v1alpha3
3kind: DestinationRule
4metadata:
5 name: "httpbin"
6spec:
7 host: "httpbin.bar.svc.cluster.local"
8 trafficPolicy:
9 tls:
10 mode: ISTIO_MUTUAL
11EOF
此时再次测试从sleep.legacy到httpbin.bar的请求因为同样的原因失败。
1for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec curl -c curl -n ${from} -- curl -s "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}\n"; done; done
2
3curl.foo to httpbin.foo: 200
4curl.foo to httpbin.bar: 200
5curl.foo to httpbin.legacy: 200
6curl.bar to httpbin.foo: 200
7curl.bar to httpbin.bar: 200
8curl.bar to httpbin.legacy: 200
9curl.legacy to httpbin.foo: 200
10curl.legacy to httpbin.bar: 000
11command terminated with exit code 56
12curl.legacy to httpbin.legacy: 200
关于策略的优先级，特定服务策略比命名空间范围的策略优先级高，这里不再进行测试。
终端用户认证 #
使用ingressgateway将httbin.foo服务暴露到集群外部:
1kubectl apply -f - <<EOF
2apiVersion: networking.istio.io/v1alpha3
3kind: Gateway
4metadata:
5 name: httpbin-gateway
6 namespace: foo
7spec:
8 selector:
9 istio: ingressgateway # use istio default controller
10 servers:
11 - port:
12 number: 80
13 name: http
14 protocol: HTTP
15 hosts:
16 - httpbin.example.com
17 tls:
18 httpsRedirect: true
19 - port:
20 number: 443
21 name: https
22 protocol: HTTPS
23 tls:
24 mode: SIMPLE
25 credentialName: bookinfo-credential # must be the same as secret
26 hosts:
27 - httpbin.example.com
28---
29apiVersion: networking.istio.io/v1alpha3
30kind: VirtualService
31metadata:
32 name: httpbin
33 namespace: foo
34spec:
35 hosts:
36 - "httpbin.example.com"
37 gateways:
38 - httpbin-gateway
39 http:
40 - route:
41 - destination:
42 port:
43 number: 8000
44 host: httpbin.foo.svc.cluster.local
45EOF
从集群外部访问入口网关https://httpbin.example.com/headers，确认可以正常访问:
1curl https://httpbin.example.com/headers
2
3{
4 "headers": {
5 "Accept": "*/*",
6 "Host": "httpbin.example.com",
7 "User-Agent": "curl/7.64.1",
8 "X-B3-Parentspanid": "738289b8959bdc53",
9 "X-B3-Sampled": "1",
10 "X-B3-Spanid": "747cf3f440f92ed1",
11 "X-B3-Traceid": "d2f668d695ae4eca738289b8959bdc53",
12 "X-Envoy-Attempt-Count": "1",
13 "X-Envoy-Internal": "true",
14 "X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=47b94c19ba0586a6e9081f6449b8b7f18b2e3981e85591bbe988650be2ca16a8;Subject=\"\";URI=spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"
15 }
16}
下面添加一个身份验证策略，该策略要求入口网关需要指定终端用户的JWT:
1kubectl apply -f - <<EOF
2apiVersion: security.istio.io/v1beta1
3kind: RequestAuthentication
4metadata:
5 name: "jwt-example"
6 namespace: istio-system
7spec:
8 selector:
9 matchLabels:
10 istio: ingressgateway
11 jwtRules:
12 - issuer: "[email protected]"
13 jwksUri: "https://raw.githubusercontent.com/istio/istio/release-1.10/security/tools/jwt/samples/jwks.json"
14EOF
策略生效的命名空间是istio-system，生效的工作负载由selector字段决定，上面的配置值是带有istio:ingressgateway标签的工作负载。
如果在authorization header(默认情况)中提供了令牌，则Istio将使用public key set验证token，bearer token无效会被拒绝，而没有提供bearer token的请求会被接收。因此要观察此行为，需要在没有token，无效token和有效token的情况下进行测试:
1curl https://httpbin.example.com/headers -s -o /dev/null -w "%{http_code}\n"
2200
3
4
5curl --header "Authorization: Bearer deadbeef" https://httpbin.example.com/headers -s -o /dev/null -w "%{http_code}\n"
6401
7
8
9TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.10/security/tools/jwt/samples/demo.jwt -s) && \
10curl --header "Authorization: Bearer $TOKEN" https://httpbin.example.com/headers -s -o /dev/null -w "%{http_code}\n"
11200
下面配置要求必须提供有效的token，这样没有token的请求也会被拒绝:
1kubectl apply -f - <<EOF
2apiVersion: security.istio.io/v1beta1
3kind: AuthorizationPolicy
4metadata:
5 name: "frontend-ingress"
6 namespace: istio-system
7spec:
8 selector:
9 matchLabels:
10 istio: ingressgateway
11 action: DENY
12 rules:
13 - from:
14 - source:
15 notRequestPrincipals: ["*"]
16 to:
17 - operation:
18 hosts: ["httpbin.example.com"]
19EOF
此时再次不带token请求时会被拒绝:
1curl https://httpbin.example.com/headers -s -o /dev/null -w "%{http_code}\n"
2403
下面配置按路由提供有效token，路径指host、path、或者method:
1kubectl apply -f - <<EOF
2apiVersion: security.istio.io/v1beta1
3kind: AuthorizationPolicy
4metadata:
5 name: "frontend-ingress"
6 namespace: istio-system
7spec:
8 selector:
9 matchLabels:
10 istio: ingressgateway
11 action: DENY
12 rules:
13 - from:
14 - source:
15 notRequestPrincipals: ["*"]
16 to:
17 - operation:
18 paths: ["/headers"]
19 hosts: ["httpbin.example.com"]
20EOF
上面的配置生效后，不提供token访问https://httpbin.example.com/headers将被拒绝，但可以访问其他路径。
1curl https://httpbin.example.com/headers -s -o /dev/null -w "%{http_code}\n"
2403
3
4curl https://httpbin.example.com/ip -s -o /dev/null -w "%{http_code}\n"
5200
可以看到有点api网关的意思了。