Istio安全-認證
認證策略
本節會介紹如何啟用，配置和使用istio的認證策略，了解更多關於認證的底層概念。
首先了解istio的認證策略和相關的mutual TLS認證概念，然后使用default配置安裝istio。
配置
下面例子會創建兩個命名空間foo和bar，以及兩個服務httpbin和sleep，這兩個服務都運行了Envoy代理。其次還在legacy命名空間中運行了不帶sidecar的httpbin和sleep的實例。最好使用自動注入sidecar的方式。
$ 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
$ kubectl 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
$ kubectl apply -f samples/httpbin/httpbin.yaml -n legacy
$ kubectl apply -f samples/sleep/sleep.yaml -n legacy
使用curl驗證配置是否正確，從foo, bar 或legacy中的sleep pod向httpbin.foo, httpbin.bar 或httpbin.legacy發送HTTP請求，所有的請求都應該返回HTTP 200狀態碼。(注：openshift下需要在foo和bar命名空間中創建NetworkAttachmentDefinition)
$ kubectl exec $(kubectl get pod -l app=sleep -n bar -o jsonpath={.items..metadata.name}) -c sleep -n bar -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "%{http_code}\n"
下面命令可以方便地遍歷所有可達性組合：
$ 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
sleep.foo to httpbin.bar: 200
sleep.foo to httpbin.legacy: 200
sleep.bar to httpbin.foo: 200
sleep.bar to httpbin.bar: 200
sleep.bar to httpbin.legacy: 200
sleep.legacy to httpbin.foo: 200
sleep.legacy to httpbin.bar: 200
sleep.legacy to httpbin.legacy: 200
校驗沒有配置對等認證策略：
$ kubectl get peerauthentication --all-namespaces
No resources found.
校驗沒有為例子的服務配置任何destination rules。可以通過校驗現有destination rules是否存在host:來查看是否存在匹配的內容：
$ kubectl get destinationrules.networking.istio.io --all-namespaces -o yaml | grep "host:"
自動mutual TLS
默認情況下，istio會跟蹤遷移到Istio代理的服務器工作負載，並自動配置客戶端代理發送mutual TLS流量到這些負載，以及發送明文流量到沒有sidecar的負載。
因此擁有代理的負載之間的流量會使用mutual TLS。例如，獲取發送到httpbin/header的請求對應的響應，當使用mutual TLS時，代理會在到達后端的上游請求中注入 X-Forwarded-Client-Cert 首部。出現該首部表明使用了mutual TLS：
$ 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
"X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=4b69f5cb0582b9a06f2178666d1fc082ec7538aa76eb29e28a5e048713ced049;Subject=\"\";URI=spiffe://cluster.local/ns/foo/sa/sleep"
當服務端沒有sidecar，則請求中不會被注入 X-Forwarded-Client-Cert 首部，暗示請求使用了明文：
$ kubectl exec $(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name}) -c sleep -n foo -- curl http://httpbin.legacy:8000/headers -s | grep X-Forwarded-Client-Cert
全局啟用istio的mutual TLS STRIC模式
由於istio會自動將代理和負載之間的流量升級到mutual TLS，此時負載仍然接收明文流量。為了防止整個網格中出現非mutual TLS，需要在網格范圍將對等認證策略設置為mutual TLS STRICT。網格范圍的對等認證策略不應該出現selector字段，且必須應用到根命名空間：
$ kubectl apply -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "default"
namespace: "istio-system"
spec:
mtls:
mode: STRICT
EOF
注：上例中將
istio-system假設為根命名空間，如果安裝時選用了不同的命名空間，則使用該命名空間替換istio-system
對等認證策略會產生如下影響：網格中所有的負載只能接收使用TLS加密的請求。由於沒有使用selector字段指定值，因此該策略會應用到網格中的所有負載。
重新執行如下命令：
$ 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
sleep.foo to httpbin.bar: 200
sleep.foo to httpbin.legacy: 200
sleep.bar to httpbin.foo: 200
sleep.bar to httpbin.bar: 200
sleep.bar to httpbin.legacy: 200
sleep.legacy to httpbin.foo: 000
command terminated with exit code 56
sleep.legacy to httpbin.bar: 000
command terminated with exit code 56
sleep.legacy to httpbin.legacy: 200
可以看到不包含代理的客戶端(sleep.legacy)的到包含代理的服務端(httpbin.foo或httpbin.bar.)的請求失敗了。由於此時使用了嚴格的mutual TLS，但不包含代理的負載無法滿足該安全要求。
卸載
$ kubectl delete peerauthentication -n istio-system default
針對單個命名空間或負載啟用mutual TLS
命名空間范圍的策略
為了修改特定命名空間內的所有負載的mutual TLS，需要使用命名空間范圍的策略。命名空間范圍的策略與網格范圍的策略的規范相同，但需要在metadata下指定命名空間。例如，下面在foo命名空間中啟用了嚴格的mutual TLS對等認證策略。
$ kubectl apply -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "default"
namespace: "foo"
spec:
mtls:
mode: STRICT
EOF
由於該策略僅對foo命名空間生效，可以看到只有sleep.legacy(不包含代理)到 httpbin.foo的請求失敗了
$ 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
sleep.foo to httpbin.bar: 200
sleep.foo to httpbin.legacy: 200
sleep.bar to httpbin.foo: 200
sleep.bar to httpbin.bar: 200
sleep.bar to httpbin.legacy: 200
sleep.legacy to httpbin.foo: 000
command terminated with exit code 56
sleep.legacy to httpbin.bar: 200
sleep.legacy to httpbin.legacy: 200
為單個負載啟用mutual TLS
為了給特定的負載設置對等認證策略，需要使用selector字段指定匹配到期望負載的標簽。然而，Istio無法為(到達服務的)出站的mutual TLS流量聚合工作負載級別的策略(可以理解為負載級別的策略僅適用於某個負載，而destination rule則適用於某個服務)，需要配置destination rule管理該行為。
例如，下面對等認證策略和destination rule為httpbin.bar負載啟用了嚴格的mutual TLS。通過DestinationRule配置到服務httpbin.bar.svc.cluster.local的流量必須使用mtls，並使用PeerAuthentication配置bar命名空間下匹配標簽app: httpbin的負載啟用mtls。
$ 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 #啟用istio mutual TLS
EOF
執行探測命令，可以看到sleep.legacy 到httpbin.bar的請求失敗了。
$ 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
sleep.foo to httpbin.bar: 200
sleep.foo to httpbin.legacy: 200
sleep.bar to httpbin.foo: 200
sleep.bar to httpbin.bar: 200
sleep.bar to httpbin.legacy: 200
sleep.legacy to httpbin.foo: 000
command terminated with exit code 56
sleep.legacy to httpbin.bar: 000
command terminated with exit code 56
sleep.legacy to httpbin.legacy: 200
如果要為單個端口設置mutual TLS，則需要配置portLevelMtls字段。例如，下面對等認證策略需要在除了80的端口上啟用mutual TLS
$ cat <<EOF | kubectl apply -n bar -f -
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "httpbin"
namespace: "bar"
spec:
selector: #配置bar命名空間中匹配標簽app: httpbin的負載的對等認證策略，在容器端口80上禁用mutual TLS
matchLabels:
app: httpbin
mtls:
mode: STRICT
portLevelMtls:
80:
mode: DISABLE
EOF
由於上述bar命名空間中的服務httpbin禁用了mTLS，因此需要一個destination rule禁用服務httpbin的mTLS，否則會導致配置不一致。當然，也可以僅使用下面DestinationRule配置到服務httpbin的mtls，而不使用上面的PeerAuthentication。
$ cat <<EOF | kubectl apply -n bar -f -
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
name: "httpbin"
spec:
host: httpbin.bar.svc.cluster.local #對到訪問httpbin.bar.svc.cluster.local:8000的流量禁用TLS
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
portLevelSettings:
- port:
number: 8000
tls:
mode: DISABLE
EOF
- 對等認證策略中的端口值為容器的端口，而destination rule中的值為service的端口
- 僅當端口綁定到服務時才能使用
portLevelMtls。其他情況下，istio會忽略該字段
策略優先級
指定負載的對等認證策略要優先於指定命名空間范圍的策略。可以通過禁用httpbin.foo負載的mutual TLS來測試這種特性。注意，foo命名空間已經啟用了命名空間范圍的mutual TLS，從sleep.legacy 到httpbin.foo的請求會失敗(見上文)。
$ cat <<EOF | kubectl apply -n foo -f -
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "overwrite-example"
namespace: "foo"
spec:
selector:
matchLabels:
app: httpbin
mtls:
mode: DISABLE
EOF
$ cat <<EOF | kubectl apply -n foo -f -
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
name: "overwrite-example"
spec:
host: httpbin.foo.svc.cluster.local
trafficPolicy:
tls:
mode: DISABLE
EOF
重新從sleep.legacy發起請求，可以看到成功返回200，表明指定服務的策略要優先於指定命名空間的策略。
$ kubectl exec $(kubectl get pod -l app=sleep -n legacy -o jsonpath={.items..metadata.name}) -c sleep -n legacy -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "%{http_code}\n"
200
此時foo命名空間中有2個對等認證策略。
$ oc get peerauthentications.security.istio.io
NAME AGE
default 16h
overwrite-example 106s
卸載
$ kubectl delete peerauthentication default overwrite-example -n foo
$ kubectl delete peerauthentication httpbin -n bar
$ kubectl delete destinationrules overwrite-example -n foo
$ kubectl delete destinationrules httpbin -n bar
終端用戶認證
為了試驗該特性，需要一個有效的JWT。JWT必須與使用的JWKS終端相匹配。本節測試JWT test 和JWKS endpoint。
為了方便，通過ingressgateway暴露httpbin.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 gateway implementation
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
EOF
$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: httpbin
namespace: foo
spec:
hosts:
- "*"
gateways:
- httpbin-gateway #將httpbin-gateway上的流量路由到httpbin.foo.svc.cluster.local的8000端口，8000端口即httpbin對應的k8s service端口
http:
- route:
- destination:
port:
number: 8000
host: httpbin.foo.svc.cluster.local
EOF
獲取INGRESS_PORT和INGRESS_HOST
$ export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')
$ export INGRESS_HOST=$(kubectl get po -l istio=ingressgateway -n istio-system -o jsonpath='{.items[0].status.hostIP}')
向ingress pod發送一個測試請求，目的端口為80：
# curl "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
200
為ingress gateway添加一個需要終端用戶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.6/security/tools/jwt/samples/jwks.json"
EOF
將該策略應用到負載(ingressgateway)上，選擇的命名空間為istio-system。
如果在認證首部提供了token，istio會使用公鑰集進行認證，如果token無效，則請求會被拒絕。但是會接收不帶token的請求。為了觀察這種行為，發送不帶token，帶錯誤的token和帶無效token的請求。
# curl "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
200
# curl --header "Authorization: Bearer deadbeef" "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
401
$ TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.7/security/tools/jwt/samples/demo.jwt -s)
$ curl --header "Authorization: Bearer $TOKEN" "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
200
為了觀察JWT驗證的其他方面，使用 gen-jwt.py 生成新的token來測試不同的issuer，audiences，expiry date等。該腳本可以從istio的庫中下載：
$ wget --no-verbose https://raw.githubusercontent.com/istio/istio/release-1.7/security/tools/jwt/samples/gen-jwt.py
此外還需要用到key.pem文件
$ wget --no-verbose https://raw.githubusercontent.com/istio/istio/release-1.7/security/tools/jwt/samples/key.pem
例如，一下命令會創建一個token，5s過期。可以看到istio認證請求一開始是成功的，5s后會被拒絕。
# TOKEN=$(python3 ./gen-jwt.py ./key.pem --expire 5)
for i in $(seq 1 10); do curl --header "Authorization: Bearer $TOKEN" "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"; sleep 1; done
[root@bastion istio-1.7.0]# for i in $(seq 1 10); do curl --header "Authorization: Bearer $TOKEN" "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"; sleep 1; done
200
200
200
200
200
200
401
401
401
401
也可以給ingress gateway配置一個JWT策略。通常用於為綁定到網關的所有服務定義JWT策略，而不只為單個服務定義JWT策略。
請求有效的token
為了拒絕不帶有效token的請求，需要添加一個DENY字段來處理無請求主體的請求，如下的notRequestPrincipals: ["*"]。只有提供了有效的JWT 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: ["*"]
EOF
重新請求，可以發現此時不帶token的請求返回了403錯誤碼：
# curl "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
403
為每條路徑請求有效的token
要使用基於每個主機、路徑或方法的token來優化授權，需要將授權策略更改為只對/headers生效。當授權規則生效時，對 $INGRESS_HOST/headers的請求會返回錯誤碼403，而針對其他路徑的請求則會成功，如$INGRESS_HOST/ip。
$ 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"]
EOF
# curl "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
403
# curl "$INGRESS_HOST:$INGRESS_PORT/ip" -s -o /dev/null -w "%{http_code}\n"
200
卸載
移除認證策略
$ kubectl -n istio-system delete requestauthentication jwt-example
$ kubectl -n istio-system delete authorizationpolicy frontend-ingress
移除pod
$ kubectl delete ns foo bar legacy
Mutual TLS遷移
本節展示如何保證負載遷移到istio后僅使用mutual TLS通信。
當調用其它負載時，istio會自動配置負載sidecar使用mutual TLS。istio默認會使用PERMISSIVE模式配置目標負載。當啟用PERMISSIVE模式時，服務可以同時接收明文和mutual TLS的流量。為了僅允許mutual TLS流量，需要將配置切換為STRICT模式。
可以使用Grafana dashboard校驗哪些負載會發送明文流量到使用PERMISSIVE模式的負載。
配置集群
創建兩個命名空間，foo和bar，部署帶sidecar的httpbin和sleep
$ 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
$ kubectl 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
創建另外一個命名空間legacy，並部署不帶sidecar的sleep
$ kubectl create ns legacy
$ kubectl apply -f samples/sleep/sleep.yaml -n legacy
從三個命名空間的sleep pod中發送請求到httpbin.foo，所有的請求都應該返回HTTP 200狀態碼。
$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar"; 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
sleep.foo to httpbin.bar: 200
sleep.bar to httpbin.foo: 200
sleep.bar to httpbin.bar: 200
sleep.legacy to httpbin.foo: 200
sleep.legacy to httpbin.bar: 200
保證沒有認證策略或destination rules
$ kubectl get peerauthentication --all-namespaces | grep -v istio-system
NAMESPACE NAME AGE
$ kubectl get destinationrule --all-namespaces
No resources found.
按命名空間鎖定mutual TLS
在將所有的客戶端遷移到istio並注入Envoy sidecar后，配置foo命名空間僅允許接收mutual TLS流量。
$ kubectl apply -n foo -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "default"
spec:
mtls:
mode: STRICT
EOF
此時從 sleep.legacy 到 httpbin.foo 的請求會失敗：
$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar"; 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
sleep.foo to httpbin.bar: 200
sleep.bar to httpbin.foo: 200
sleep.bar to httpbin.bar: 200
sleep.legacy to httpbin.foo: 000
command terminated with exit code 56
sleep.legacy to httpbin.bar: 200
如果在安裝istio時啟用了 values.global.proxy.privileged=true，則可以使用tcpdump校驗流量是否加密。
$ kubectl exec -nfoo "$(kubectl get pod -nfoo -lapp=httpbin -ojsonpath={.items..metadata.name})" -c istio-proxy -it -- sudo tcpdump dst port 80 -A
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
如果無法將所有的服務遷移到istio，則需要使用PERMiISSIVE模式。但是如果使用了PERMISSIVE模式，則不會使用任何認證和授權，默認使用明文流量。推薦使用istio認證為不同的路徑配置不同的策略。
為整個網格鎖定mutual TLS
$ kubectl apply -n istio-system -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "default"
spec:
mtls:
mode: STRICT
EOF
現在 foo 和bar命名空間會強制使用mutual TLS流量，因此從sleep.legacy發出的所有請求都會失敗。
$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar"; 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
sleep.foo to httpbin.bar: 200
sleep.bar to httpbin.foo: 200
sleep.bar to httpbin.bar: 200
sleep.legacy to httpbin.foo: 000
command terminated with exit code 56
sleep.legacy to httpbin.bar: 000
command terminated with exit code 56
卸載
$ kubectl delete peerauthentication --all-namespaces --all
$ kubectl delete ns foo bar legacy
總結
本章介紹了兩種認證策略：對等認證和請求認證。前者主要是基於istio提供的mTLS，可以在不同網格范圍內設置對等認證，如網格范圍，命名空間范圍，以及指定負載等。注意它與destination rule的配置，destination rule可以配置執行服務的TLS；后者主要基於JWT的終端用戶認證，可以跨網格使用。
最后好可以使用授權策略進行授權