kubernetes - kubernetes で istio との mTLS 通信をデバッグするには?

Question

私は Istio に非常に慣れていないため、単純な質問かもしれませんが、Istio に関していくつか混乱があります。k8s に Istio 1.8.0 と 1.19 を使用しています。複数の質問で申し訳ありませんが、最善のアプローチを明確にするのを手伝っていただければ幸いです。 .

Istio を注入した後、ポッド内でサービスからサービスに直接アクセスできなかったと思いますが、以下に示すようにアクセスできます。誤解しているかもしれませんが、それは期待される動作ですか？一方、サービスが mTLS を使用して envoy プロキシを介して互いに通信するかどうかをデバッグするにはどうすればよいですか? モードを使用してSTRICTいますが、これを回避するには、マイクロサービスが実行されている名前空間にピア認証をデプロイする必要がありますか?
```
 kubectl get peerauthentication --all-namespaces
 NAMESPACE      NAME      AGE
 istio-system   default   26h
```
トラフィックを制限するにはどうすればよいですか? api-dev サービスは auth-dev にアクセスするべきではありませんが、backend-dev にアクセスできますか?
database一部のマイクロサービスは、名前空間でも実行されているデータベースと通信する必要があります。同じデータベースを使用して istio を注入したくないものもありますか? では、データベースも istio インジェクションがあるのと同じ名前空間にデプロイする必要がありますか? はいの場合、残りのサービスのために別のデータベースインスタンスをデプロイする必要があるということですか?

    $ kubectl get ns --show-labels
    NAME              STATUS   AGE    LABELS
    database          Active   317d   name=database
    hub-dev           Active   15h    istio-injection=enabled
    dev               Active   318d   name=dev


    capel0068340585:~ semural$ kubectl get pods -n hub-dev
    NAME                                     READY   STATUS    RESTARTS   AGE
    api-dev-5b9cdfc55c-ltgqz                  3/3     Running   0          117m
    auth-dev-54bd586cc9-l8jdn                 3/3     Running   0          13h
    backend-dev-6b86994697-2cxst              2/2     Running   0          120m
    cronjob-dev-7c599bf944-cw8ql              3/3     Running   0          137m
    mp-dev-59cb8d5589-w5mxc                   3/3     Running   0          117m
    ui-dev-5884478c7b-q8lnm                   2/2     Running   0          114m
    redis-hub-master-0                        2/2     Running   0           2m57s
    
    $ kubectl get svc -n hub-dev
    NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
    api-dev                ClusterIP   xxxxxxxxxxxxx      <none>        80/TCP    13h
    auth-dev               ClusterIP   xxxxxxxxxxxxx      <none>        80/TCP    13h
    backend-dev            ClusterIP   xxxxxxxxxxxxx      <none>        80/TCP    14h
    cronjob-dev            ClusterIP   xxxxxxxxxxxxx      <none>        80/TCP    14h
    mp-dev                 ClusterIP   xxxxxxxxxxxxx      <none>        80/TCP    13h
    ui-dev                 ClusterIP   xxxxxxxxxxxxx      <none>        80/TCP    13h
    redis-hub-master       ClusterIP   xxxxxxxxxxxxx      <none>        6379/TCP  3m47s
    


----------


    $ kubectl exec -ti ui-dev-5884478c7b-q8lnm -n hub-dev sh
    Defaulting container name to oneapihub-ui.
    Use 'kubectl describe pod/ui-dev-5884478c7b-q8lnm -n hub-dev' to see all of the containers in this pod.
    /usr/src/app $ curl -vv  http://hub-backend-dev
    *   Trying 10.254.78.120:80...
    * TCP_NODELAY set
    * Connected to backend-dev (10.254.78.120) port 80 (#0)
    > GET / HTTP/1.1
    > Host: backend-dev
    > User-Agent: curl/7.67.0
    > Accept: */*
    >
    * Mark bundle as not supporting multiuse
    < HTTP/1.1 404 Not Found
    < content-security-policy: default-src 'self'

    <
    <!DOCTYPE html>
    <html lang="en">
    <head>
    <meta charset="utf-8">
    <title>Error</title>
    </head>
    <body>
    <pre>Cannot GET /</pre>
    </body>
    </html>
    * Connection #0 to host oneapihub-backend-dev left intact
    /usr/src/app $

score 2 · Accepted Answer

ドキュメントによると、 STRICTmtlsを使用する場合、ワークロードは暗号化されたトラフィックのみを受け入れる必要があります。

ピア認証

ピア認証ポリシーは、Istio がターゲットワークロードに適用する相互 TLS モードを指定します。次のモードがサポートされています。

PERMISSIVE: ワークロードは、相互 TLS トラフィックとプレーンテキストトラフィックの両方を受け入れます。このモードは、サイドカーのないワークロードが相互 TLS を使用できない移行時に最も役立ちます。ワークロードがサイドカーインジェクションで移行されたら、モードを STRICT に切り替える必要があります。

STRICT: ワークロードは相互 TLS トラフィックのみを受け入れます。

無効: 相互 TLS を無効にします。セキュリティの観点から、独自のセキュリティソリューションを提供しない限り、このモードを使用しないでください。

モードが設定されていない場合、親スコープのモードが継承されます。モードが設定されていないメッシュ全体のピア認証ポリシーは、デフォルトで PERMISSIVE モードを使用します。

また、バンザイクラウドによってここで非常によく説明されているので、ここも見てみる価値があります。

厳格な mtls モードをグローバルに有効にすることができますが、特定の名前空間またはワークロードごとに有効にすることもできます。

istio Authorization Policyを使用してそれを行うことができます。

Istio Authorization Policy は、メッシュ内のワークロードに対するアクセス制御を有効にします。

例があります。

以下は、アクションを「DENY」に設定して拒否ポリシーを作成する別の例です。「foo」名前空間のすべてのワークロードで、「dev」名前空間から「POST」メソッドへのリクエストを拒否します。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 action: DENY
 rules:
 - from:
   - source:
       namespaces: ["dev"]
   to:
   - operation:
       methods: ["POST"]

注入せずにデータベースをセットアップし、ServiceEntry オブジェクトを使用して Istio レジストリに追加して、残りの istio サービスと通信できるようにすることができます。

ServiceEntry を使用すると、Istio の内部サービスレジストリに追加のエントリを追加できるため、メッシュ内の自動検出されたサービスがこれらの手動で指定されたサービスにアクセス/ルーティングできるようになります。サービスエントリは、サービスのプロパティ (DNS 名、VIP、ポート、プロトコル、エンドポイント) を記述します。これらのサービスは、メッシュの外部 (例: Web API) またはプラットフォームのサービスレジストリの一部ではないメッシュ内部のサービス (例: Kubernetes のサービスと通信する一連の VM) である可能性があります。さらに、workloadSelector フィールドを使用して、サービスエントリのエンドポイントを動的に選択することもできます。これらのエンドポイントは、WorkloadEntry オブジェクトまたは Kubernetes ポッドを使用して宣言された VM ワークロードにすることができます。

istio のドキュメントに例があります。

mtls 通信のデバッグ方法に関する主な質問に答えるには

最も基本的なテストは、たとえば、curl を使用して、注入されていないポッドから注入されたポッドへの呼び出しを試みることです。それに関するistioドキュメントがあります。

も使用できます。istioctl x describe詳細については、こちらを参照してください。

の何が問題なのかはcurl -vv http://hub-backend-devわかりませんが、404 であるため、間違った仮想サービス構成など、istio の依存関係に問題がある可能性があると思われます。

kubernetes - kubernetes で istio との mTLS 通信をデバッグするには?

1 に答える 1

ピア認証

Related

Reference