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

环境准备

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

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代理。

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代理。

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。

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)策略：

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。

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请求头将不会存在。

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

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请求：

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.foo和httpbin.bar的请求将会失败，因为全局的对等认证策略是严格模式，要求客户端与httpbin.foo和httpbin.bar之间的流量必须是双向TLS的。

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

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

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

kubectl delete peerauthentication -n istio-system default

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

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的请求会失败。

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来管理该行为。

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

kubectl delete PeerAuthentication default -n foo

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

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

添加一个目标规则:

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.legacy到httpbin.bar的请求因为同样的原因失败。

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服务暴露到集群外部:

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，确认可以正常访问:

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:

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的情况下进行测试:

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的请求也会被拒绝:

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请求时会被拒绝:

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

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

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将被拒绝，但可以访问其他路径。

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网关的意思了。

参考

• https://istio.io/latest/zh/docs/tasks/security/authentication/authn-policy/
• https://istio.io/latest/docs/tasks/security/authentication/authn-policy/