前面3~12节学习了istio的流量管理功能,包括如何配置请求路由、故障注入、流量转移、流量镜像、设置请求超时和熔断、将服务网格外部流量接入到集群内、控制服务网格的出口流量等。 从本节开始学习istio的安全管理功能,看istio是如何保护服务网格内的微服务的。本节将根据istio官方文档https://istio.io/latest/zh/docs/tasks/security/authentication/authn-policy/中的内容,学习使用istio的认证策略来设置双向TLS和基本的终端用户认证。

环境准备

创建foo, bar两个命名空间,并开启istio sidecar代理自动注入:

1
2
3
4
5
6
kubectl create ns foo
kubectl label namespace foo istio-injection=enabled


kubectl create ns bar
kubectl label namespace bar istio-injection=enabled

分别在foo, bar两个命名空间内部署httpbin服务和启动一个radial/busyboxplus:curl容器的pod。httpbin和curl都将被自动注入isito envoy sidecar代理。

1
2
3
4
5
kubectl apply -f samples/httpbin/httpbin.yaml -n foo
kubectl run curl --image=radial/busyboxplus:curl -it -n foo

kubectl apply -f samples/httpbin/httpbin.yaml -n bar
kubectl run curl --image=radial/busyboxplus:curl -it -n bar

创建一个legacy命名空间,不开启isito sidecar自动注入,在该命名空间内部署部署httpbin服务和curl服务,它们将不会有sidecar代理。

1
2
3
kubectl create ns legacy
kubectl apply -f samples/httpbin/httpbin.yaml -n legacy
kubectl run curl --image=radial/busyboxplus:curl -it -n legacy

测试在foo, bar, legacy三个命名空间中的curl pod内都可以使用curl向httpbin.foo, httpbin.bar, httpbin.legacy发送http请求,都成功返回200。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
for 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
curl.foo to httpbin.foo: 200
curl.foo to httpbin.bar: 200
curl.foo to httpbin.legacy: 200
curl.bar to httpbin.foo: 200
curl.bar to httpbin.bar: 200
curl.bar to httpbin.legacy: 200
curl.legacy to httpbin.foo: 200
curl.legacy to httpbin.bar: 200
curl.legacy to httpbin.legacy: 200

使用以下命令确认系统中没有对等身份验证(peerauthentication)策略:

1
2
kubectl get peerauthentication --all-namespaces
No 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。

1
2
kubectl 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>;/'
    "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请求头将不会存在。

1
kubectl 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)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT
EOF

再次测试在foo, bar, legacy三个命名空间中的curl pod内都可以使用curl向httpbin.foo, httpbin.bar, httpbin.legacy发送http请求:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
for 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

curl.foo to httpbin.foo: 200
curl.foo to httpbin.bar: 200
curl.foo to httpbin.legacy: 200
curl.bar to httpbin.foo: 200
curl.bar to httpbin.bar: 200
curl.bar to httpbin.legacy: 200
curl.legacy to httpbin.foo: 000
command terminated with exit code 56
curl.legacy to httpbin.bar: 000
command terminated with exit code 56
curl.legacy to httpbin.legacy: 200

会发现没有sidecar代理的curl.legacy到有sidecar代理的httpbin.foohttpbin.bar的请求将会失败,因为全局的对等认证策略是严格模式,要求客户端与httpbin.foohttpbin.bar之间的流量必须是双向TLS的。

命名空间级别的双向TLS和工作负载级别的双向TLS

如果你觉得全局开启双向TLS太严格了,还可以为每个命名空间或者工作负载启用双向TLS。

在测试前先删除前面创建的全局对等认证策略:

1
kubectl delete peerauthentication -n istio-system default

创建命名空间级别的对等认证策略,只需要在metadata字段中指定具体的命名空间即可:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: "default"
  namespace: "foo"
spec:
  mtls:
    mode: STRICT
EOF

因为上面创建的这个策略只应用于命名空间foo中的服务,再次测试在foo, bar, legacy三个命名空间中的curl pod内都可以使用curl向httpbin.foo, httpbin.bar, httpbin.legacy发送http请求。 会发现只有从没有sidecar代理的(curl.legacy)到有sidecar的代理的httpbin.foo的请求会失败。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
for 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

curl.foo to httpbin.foo: 200
curl.foo to httpbin.bar: 200
curl.foo to httpbin.legacy: 200
curl.bar to httpbin.foo: 200
curl.bar to httpbin.bar: 200
curl.bar to httpbin.legacy: 200
curl.legacy to httpbin.foo: 000
command terminated with exit code 56
curl.legacy to httpbin.bar: 200
curl.legacy to httpbin.legacy: 200

下面演示为特定工作负载启用双向TLS。要为特定工作负载设置对等身份验证策略,必须配置selector字段并指定与所需工作负载匹配的标签。然而Istio不能将出站双向TLS流量的工作负载策略聚合到服务。 应该通过配置目标规则destinationrule来管理该行为。

在测试之前,先删除前面创建的命名空间级别的认证策略:

1
kubectl delete PeerAuthentication default -n foo

下面创建对等认证策略,并使用selector将策略应用于httpbin.bar:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
cat <<EOF | kubectl apply -n bar -f -
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: "httpbin"
  namespace: "bar"
spec:
  selector:
    matchLabels:
      app: httpbin
  mtls:
    mode: STRICT
EOF

添加一个目标规则:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
cat <<EOF | kubectl apply -n bar -f -
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: "httpbin"
spec:
  host: "httpbin.bar.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
EOF

此时再次测试从sleep.legacyhttpbin.bar的请求因为同样的原因失败。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
for 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

curl.foo to httpbin.foo: 200
curl.foo to httpbin.bar: 200
curl.foo to httpbin.legacy: 200
curl.bar to httpbin.foo: 200
curl.bar to httpbin.bar: 200
curl.bar to httpbin.legacy: 200
curl.legacy to httpbin.foo: 200
curl.legacy to httpbin.bar: 000
command terminated with exit code 56
curl.legacy to httpbin.legacy: 200

关于策略的优先级,特定服务策略比命名空间范围的策略优先级高,这里不再进行测试。

终端用户认证

使用ingressgateway将httbin.foo服务暴露到集群外部:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: httpbin-gateway
  namespace: foo
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - httpbin.example.com
    tls:
      httpsRedirect: true
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: bookinfo-credential # must be the same as secret
    hosts:
    - httpbin.example.com
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin
  namespace: foo
spec:
  hosts:
  - "httpbin.example.com"
  gateways:
  - httpbin-gateway
  http:
  - route:
    - destination:
        port:
          number: 8000
        host: httpbin.foo.svc.cluster.local
EOF

从集群外部访问入口网关https://httpbin.example.com/headers,确认可以正常访问:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
curl https://httpbin.example.com/headers

{
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.example.com",
    "User-Agent": "curl/7.64.1",
    "X-B3-Parentspanid": "738289b8959bdc53",
    "X-B3-Sampled": "1",
    "X-B3-Spanid": "747cf3f440f92ed1",
    "X-B3-Traceid": "d2f668d695ae4eca738289b8959bdc53",
    "X-Envoy-Attempt-Count": "1",
    "X-Envoy-Internal": "true",
    "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"
  }
}

下面添加一个身份验证策略,该策略要求入口网关需要指定终端用户的JWT:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: "jwt-example"
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  jwtRules:
  - issuer: "testing@secure.istio.io"
    jwksUri: "https://raw.githubusercontent.com/istio/istio/release-1.10/security/tools/jwt/samples/jwks.json"
EOF

策略生效的命名空间是istio-system,生效的工作负载由selector字段决定,上面的配置值是带有istio:ingressgateway标签的工作负载。

如果在authorization header(默认情况)中提供了令牌,则Istio将使用public key set验证token,bearer token无效会被拒绝,而没有提供bearer token的请求会被接收。因此要观察此行为,需要在没有token,无效token和有效token的情况下进行测试:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
curl https://httpbin.example.com/headers -s -o /dev/null -w "%{http_code}\n"
200


curl --header "Authorization: Bearer deadbeef" https://httpbin.example.com/headers -s -o /dev/null -w "%{http_code}\n"
401


TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.10/security/tools/jwt/samples/demo.jwt -s) && \
curl --header "Authorization: Bearer $TOKEN" https://httpbin.example.com/headers -s -o /dev/null -w "%{http_code}\n"
200 

下面配置要求必须提供有效的token,这样没有token的请求也会被拒绝:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "frontend-ingress"
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["*"]
    to:
    - operation:
        hosts: ["httpbin.example.com"]
EOF

此时再次不带token请求时会被拒绝:

1
2
curl https://httpbin.example.com/headers -s -o /dev/null -w "%{http_code}\n"
403

下面配置按路由提供有效token,路径指host、path、或者method:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "frontend-ingress"
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["*"]
    to:
    - operation:
        paths: ["/headers"]
        hosts: ["httpbin.example.com"]
EOF


上面的配置生效后,不提供token访问https://httpbin.example.com/headers将被拒绝,但可以访问其他路径。

1
2
3
4
5
curl https://httpbin.example.com/headers -s -o /dev/null -w "%{http_code}\n"
403

curl https://httpbin.example.com/ip -s -o /dev/null -w "%{http_code}\n"
200

可以看到有点api网关的意思了。

参考