Testing Istio mutual TLS authentication
6897 ワード
このtaskを通じて、あなたはどのように学ぶことができますか? Istio内相互間のTLS認証設定 を確認する.手動テストアイデンティティ認証
このtaskはk 8 sクラスタがあると仮定します. the Istio installation taskインストールTLSアイデンティティ認証付きIstio.注意「Installation steps」の手順5で「enable Istio mutual TLS Authentication feature」 を選択します.
次のコマンドは、defaultネーミングスペースにサービスが配置されていると仮定します.適用パラメータ
Verifying Istio CA
クラスタレベルのCAが実行されていることを確認します.
「AVAILABLE」列が1の場合はIstio CA起動を示します.
Verifying service configuration
1.コンフィグマップで設定したAuthPolicyを確認します.
行
相互TLS認証のIstio実行を開始すると、あるサービスのEnvoyでcurlを使用して別のサービスにリクエストを送信できます.たとえば、Bookinfoサンプルアプリケーションをオンにすると、sshは
保証podは「Running」です.
2.sshがEnvoy容器に入る
3.鍵/証明書が/etc/certs/ディレクトリにあることを確認します.
その
4.「curl」がインストールされていることを確認する
curlがインストールされている場合は、似たような内容が表示されます.
そうでない場合は、次のコマンドを実行して再開します.
注意:istio proxyミラーはcurlをインストールしていませんが、debugミラーはインストールされています.コマンドで「
5.detailsなどの他のサービスへのリクエストの送信
サービス名とポート定義はhere
Istioは、サービス名よりも強力なセキュリティ(詳細here)を提供するKubernetes service accountをサービスアイデンティティとして使用していることに注意してください.そのためIstioの証明書にはサービス名がありません.これはcurlがサービスアイデンティティを確認する必要がある情報です.したがって、curlの
Istioでクライアントがサービス側のアイデンティティを確認する方法について、hereでセキュリティ名を確認してください.
上記では、サービス側がクライアントから接続を受け入れることを実証し、確認しました.
Before you begin
このtaskはk 8 sクラスタがあると仮定します.
Verifying Istio’s mutual TLS authentication setup
次のコマンドは、defaultネーミングスペースにサービスが配置されていると仮定します.適用パラメータ
-n yournamespaceは、他のネーミングスペースを指定します.Verifying Istio CA
クラスタレベルのCAが実行されていることを確認します.
kubectl get deploy -l istio=istio-ca -n istio-systemNAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
istio-ca 1 1 1 1 1m「AVAILABLE」列が1の場合はIstio CA起動を示します.
Verifying service configuration
1.コンフィグマップで設定したAuthPolicyを確認します.
kubectl get configmap istio -o yaml -n istio-system | grep authPolicy | head -1行
authPolicy: MUTUAL_TLSが注釈されていない場合(#がない場合)、Istio相互TLS認証がオンになることを表す.Testing the authentication setup
相互TLS認証のIstio実行を開始すると、あるサービスのEnvoyでcurlを使用して別のサービスにリクエストを送信できます.たとえば、Bookinfoサンプルアプリケーションをオンにすると、sshは
productpageサービスのEnvoyコンテナに入り、curlを介して他のサービスにリクエストを送信することができます.次の手順は、1.productpage pod名の取得kubectl get pods -l app=productpageNAME READY STATUS RESTARTS AGE
productpage-v1-4184313719-5mxjc 2/2 Running 0 23h保証podは「Running」です.
2.sshがEnvoy容器に入る
kubectl exec -it productpage-v1-4184313719-5mxjc -c istio-proxy /bin/bash3.鍵/証明書が/etc/certs/ディレクトリにあることを確認します.
ls /etc/certs/cert-chain.pem key.pem root-cert.pemその
cert-chain.pemは、他の方に提出する必要があるEnvoy証明書であることに注意してください.key.pemは、cert-chain.pemを組み合わせたEnvoyの秘密鍵である.root-cert.pemは、他方の証明書を確認するルート証明書です.現在CAは1つしかありませんので、すべてのEnvoysは同じroot-cert.pemを持っています.4.「curl」がインストールされていることを確認する
curlcurlがインストールされている場合は、似たような内容が表示されます.
curl: try 'curl --help' or 'curl --manual' for more informationそうでない場合は、次のコマンドを実行して再開します.
kubectl apply -f <(istioctl kube-inject --debug -f samples/bookinfo/kube/bookinfo.yaml)注意:istio proxyミラーはcurlをインストールしていませんが、debugミラーはインストールされています.コマンドで「
–debug」IDを使用すると、debugミラーを使用するサービスが再配置されます.5.detailsなどの他のサービスへのリクエストの送信
curl https://details:9080/details/0 -v --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem -k...
error fetching CN from cert:The requested data were not available.
...
< HTTP/1.1 200 OK
< content-type: text/html; charset=utf-8
< content-length: 1867
< server: envoy
< date: Thu, 11 May 2017 18:59:42 GMT
< x-envoy-upstream-service-time: 2
...サービス名とポート定義はhere
Istioは、サービス名よりも強力なセキュリティ(詳細here)を提供するKubernetes service accountをサービスアイデンティティとして使用していることに注意してください.そのためIstioの証明書にはサービス名がありません.これはcurlがサービスアイデンティティを確認する必要がある情報です.したがって、curlの
‘-k’パラメータを使用して、curlクライアントがサービス側から提供された証明書にサービス名(i.e.,productpage.ns.svc.cluster.local)を発見および確認しないことによる異常な中止を防止します.Istioでクライアントがサービス側のアイデンティティを確認する方法について、hereでセキュリティ名を確認してください.
上記では、サービス側がクライアントから接続を受け入れることを実証し、確認しました.
--keyおよび--certを使用しないことを試み、接続が許可されず、HTTP 200ステータスコードが得られないことを観察します.