Cloud Service Mesh と Traffic Director は Cloud Service Mesh になりました。詳細については、Cloud Service Mesh の概要をご覧ください。

Cloud Service Mesh の例: mTLS

Cloud Service Mesh 1.5 以降では、自動相互 TLS（自動 mTLS）がデフォルトで有効になっています。自動 mTLS の場合、クライアントサイドカープロキシがサーバーにサイドカーがあるかどうかを自動的に検出します。クライアントサイドカーは、サイドカーを含むワークロードには mTLS を送信し、サイドカーを含まないワークロードには平文を送信します。ただし、サービスは平文と mTLS トラフィックの両方を受け入れます。Pod にサイドカープロキシを挿入する場合、mTLS トラフィックのみを受け入れるようにサービスを構成することをおすすめします。

Cloud Service Mesh では、単一の YAML ファイルを適用することで、アプリケーションコードの外部で mTLS を適用できます。Cloud Service Mesh には柔軟性があり、サービスメッシュ全体、Namespace、個々のワークロードに認証ポリシーを適用できます。

相互 mTLS

費用

このドキュメントでは、課金対象である次の Google Cloudコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。

新規の Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

このチュートリアルの終了後に作成したリソースを削除すれば、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

始める前に

プロジェクトの課金を有効にします。
GKE クラスタで Cloud Service Mesh をプロビジョニングします。サポートされている設定方法は次のとおりです。
- Google Cloud上の Fleet API とマネージドコントロールプレーン
- Google Cloud外の asmcli と、非マネージドのクラスタ内コントロールプレーン

リポジトリのクローンを作成します。

git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-samples
cd anthos-service-mesh-samples

Ingress ゲートウェイをデプロイする

kubectl の現在のコンテキストをクラスタに設定します。

注: クラスタがリージョンクラスタの場合は、--zone ではなく --region を使用します。
```
gcloud container clusters get-credentials CLUSTER_NAME  \
--project=PROJECT_ID \
--zone=CLUSTER_LOCATION 
```
Ingress ゲートウェイの名前空間を作成します。
```
kubectl create namespace asm-ingress
```
インジェクションの名前空間を有効にします。手順は、コントロールプレーンの実装によって異なります。
マネージド（TD）
デフォルトのインジェクションラベルを Namespace に適用します。
```
kubectl label namespace asm-ingress \
    istio.io/rev- istio-injection=enabled --overwrite
```
マネージド（Istiod）
推奨: 次のコマンドを実行して、デフォルトのインジェクションラベルを Namespace に適用します。
```
  kubectl label namespace asm-ingress \
      istio.io/rev- istio-injection=enabled --overwrite
```
マネージド Istiod コントロールプレーンを使用している既存のユーザーの場合: デフォルトのインジェクションを使用することをおすすめしますが、リビジョンベースのインジェクションもサポートされています。次の手順を行います。
1. 次のコマンドを実行して、利用可能なリリースチャンネルを探します。
  kubectl -n istio-system get controlplanerevision
  出力は次のようになります。
  NAME AGE asm-managed-rapid 6d7h
  注: 上記のリストで、コントロールプレーンのリビジョンが 2 つ表示されている場合は、一方を削除します。クラスタに複数のコントロールプレーンチャネルを配置することはできません。
  出力の NAME 列の値は、Cloud Service Mesh バージョンで使用可能なリリースチャンネルに対応するリビジョンラベルです。
2. リビジョンラベルを Namespace に適用します。
  kubectl label namespace asm-ingress \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite

anthos-service-mesh-samples リポジトリにサンプルゲートウェイをデプロイします。

kubectl apply -n asm-ingress \
-f docs/shared/asm-ingress-gateway

予想される出力:

serviceaccount/asm-ingressgateway configured
service/asm-ingressgateway configured
deployment.apps/asm-ingressgateway configured
gateway.networking.istio.io/asm-ingressgateway configured

Online Boutique サンプルアプリケーションをデプロイする

まだ行っていない場合は、kubectl の現在のコンテキストをクラスタに設定します。

  gcloud container clusters get-credentials CLUSTER_NAME  \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION

サンプルアプリケーションの名前空間を作成します。
```
  kubectl create namespace onlineboutique
```
Envoy プロキシを自動的に挿入するには、onlineboutique 名前空間にラベルを付けます。自動サイドカーインジェクションを有効にする手順を行います。
サンプルアプリ、フロントエンド用の VirtualService、ワークロードのサービスアカウントをデプロイします。このチュートリアルでは、マイクロサービスデモアプリである Online Boutique をデプロイします。
```
  kubectl apply \
  -n onlineboutique \
  -f docs/shared/online-boutique/virtual-service.yaml
  kubectl apply \
  -n onlineboutique \
  -f docs/shared/online-boutique/service-accounts
```

サービスを表示する

onlineboutique Namespace の Pod を表示します。

kubectl get pods -n onlineboutique

予想される出力:

NAME                                     READY   STATUS    RESTARTS   AGE
adservice-85598d856b-m84m6               2/2     Running   0          2m7s
cartservice-c77f6b866-m67vd              2/2     Running   0          2m8s
checkoutservice-654c47f4b6-hqtqr         2/2     Running   0          2m10s
currencyservice-59bc889674-jhk8z         2/2     Running   0          2m8s
emailservice-5b9fff7cb8-8nqwz            2/2     Running   0          2m10s
frontend-77b88cc7cb-mr4rp                2/2     Running   0          2m9s
loadgenerator-6958f5bc8b-55q7w           2/2     Running   0          2m8s
paymentservice-68dd9755bb-2jmb7          2/2     Running   0          2m9s
productcatalogservice-84f95c95ff-c5kl6   2/2     Running   0          114s
recommendationservice-64dc9dfbc8-xfs2t   2/2     Running   0          2m9s
redis-cart-5b569cd47-cc2qd               2/2     Running   0          2m7s
shippingservice-5488d5b6cb-lfhtt         2/2     Running   0          2m7s

アプリケーションのすべての Pod が稼働状態になり、READY 列に 2/2 が入力されます。これは、Pod に Envoy サイドカープロキシが正常に挿入されたことを示します。数分経っても 2/2 が表示されない場合は、トラブルシューティングガイドをご覧ください。

外部 IP を取得して、変数に設定します。

kubectl get services -n asm-ingress
export FRONTEND_IP=$(kubectl --namespace asm-ingress \
get service --output jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}' \
)

次のような出力が表示されます。

NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                      AGE
asm-ingressgateway   LoadBalancer   10.19.247.233   35.239.7.64   80:31380/TCP,443:31390/TCP,31400:31400/TCP   27m

ウェブブラウザで EXTERNAL-IP のアドレスにアクセスします。ブラウザに Online Boutique のショップが表示されます。

TestCurl Pod を作成する

TestCurl Pod を作成して、テスト用の平文トラフィックを送信します。

  apiVersion: v1
  kind: Pod
  metadata:
    name: testcurl
    namespace: default
    annotations:
      sidecar.istio.io/inject: "false"
  spec:
    containers:
    - name: curl
      image: curlimages/curl
      command: ["sleep", "600"]

Online Boutique にアクセスする

kubectl の現在のコンテキストを、Online Boutique をデプロイしたクラスタに設定します。

gcloud container clusters get-credentials CLUSTER_NAME  \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION

frontend 名前空間のサービスを一覧表示します。
```
kubectl get services -n frontend
```
frontend-external は LoadBalancer であり、外部 IP アドレスがあります。サンプルアプリケーションには、Cloud Service Mesh を使用せずに GKE にデプロイできるようにロードバランサのサービスが含まれています。
frontend-external サービスの外部 IP アドレスを使用して、ブラウザでアプリケーションにアクセスします。
```
http://FRONTEND_EXTERNAL_IP/
```
Cloud Service Mesh では、Ingress ゲートウェイをデプロイできます。Ingress ゲートウェイの外部 IP アドレスを使用して Online Boutique にアクセスすることもできます。アプリケーションの外部 IP を取得します。プレースホルダを次の情報に置き換えます。
- GATEWAY_SERVICE_NAME: Ingress ゲートウェイサービスの名前。サンプルゲートウェイをそのままデプロイしたか、デフォルトの Ingress ゲートウェイをデプロイした場合、名前は istio-ingressgateway になります。
- GATEWAY_NAMESPACE: Ingress ゲートウェイをデプロイした名前空間。デフォルトの Ingress ゲートウェイをデプロイした場合、名前空間は istio-system です。
```
kubectl get service GATEWAY_NAME -n GATEWAY_NAMESPACE
```
ブラウザで別のタブを開き、ingress ゲートウェイの外部 IP アドレスを使用してアプリケーションにアクセスします。
```
http://INGRESS_GATEWAY_EXTERNAL_IP/
```
次のコマンドを実行して、別の Pod からプレーン HTTP で frontend サービスの curl を実行します。サービスが異なる Namespace にあるため、frontend サービスの DNS 名を curl で転送する必要があります。
```
kubectl debug --image istio/base --target istio-proxy -it \
  $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
  -n product-catalog -- \
  curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
```
デフォルトでは TLS と平文の両方のトラフィックが受け入れられるため、ステータス 200 でリクエストが成功します。

名前空間ごとに相互 TLS を有効にする

mTLS を適用するには、kubectl で PeerAuthentication ポリシーを適用します。

次の認証ポリシーを mtls-namespace.yaml として保存します。
```
cat <<EOF > mtls-namespace.yaml
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "namespace-policy"
spec:
  mtls:
    mode: STRICT
EOF
```
YAML の mode: STRICT 行は、mTLS のみを受け入れるようにサービスを構成します。デフォルトでは、mode は PERMISSIVE であり、平文と mTLS の両方を受け入れるようにサービスを構成します。

mTLS のみを受け入れるように、認証ポリシーを適用してすべての Online Boutique サービスを構成します。

for ns in ad cart checkout currency email frontend loadgenerator \
     payment product-catalog recommendation shipping; do
kubectl apply -n $ns -f mtls-namespace.yaml
done

予想される出力:

peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created
peerauthentication.security.istio.io/namespace-policy created

frontend-external サービスの外部 IP アドレスを使用して、Online Boutique にアクセスするブラウザのタブに移動します。
```
http://FRONTEND_EXTERNAL_IP/
```
ページを更新すると、ブラウザに次のエラーが表示されます。

ページを更新すると、平文が frontend サービスに送信されます。STRICT 認証ポリシーにより、サイドカープロキシはサービスに対するリクエストをブロックします。
ブラウザのタブから、istio-ingressgateway の外部 IP アドレスを使用して Online Boutique にアクセスし、ページを更新して正常に表示します。Ingress ゲートウェイを使用して Online Boutique にアクセスする場合、リクエストは次のパスを取得します。

mTLS 認証フロー:
1. ブラウザが平文の HTTP リクエストをサーバーに送信します。
2. Ingress ゲートウェイプロキシコンテナがリクエストをインターセプトします。
3. Ingress ゲートウェイプロキシは、サーバー側プロキシ（この例ではフロントエンドサービス）を使用して TLS handshake を実行します。この handshake には、証明書交換が含まれています。これらの証明書は、Cloud Service Mesh によってプロキシコンテナにあらかじめ読み込まれています。
4. Ingress ゲートウェイプロキシは、サーバーの証明書に対して安全な名前チェックを実行し、認可された ID がサーバーで実行されていることを確認します。
5. Ingress ゲートウェイとサーバープロキシは相互 TLS 接続を確立し、サーバープロキシがリクエストをサーバーアプリケーションコンテナ（フロントエンドサービス）に転送します。
次のコマンドを実行して、別の Pod からプレーン HTTP で frontend サービスの curl を実行します。
```
kubectl exec testcurl -n default -- curl \
  http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
```
STRICT peerAuthentication ポリシーが適用されているサイドカーレスワークロードから平文トラフィックを送信しているため、このリクエストは失敗します。

認証ポリシーを検索して削除する

サービスメッシュ内のすべての PeerAuthentication ポリシーの一覧を表示するには、次のコマンドを実行します。

kubectl get peerauthentication --all-namespaces

出力は次のようになります。

NAMESPACE         NAME               MODE     AGE
ad                namespace-policy   STRICT   17m
cart              namespace-policy   STRICT   17m
checkout          namespace-policy   STRICT   17m
currency          namespace-policy   STRICT   17m
email             namespace-policy   STRICT   17m
frontend          namespace-policy   STRICT   17m
loadgenerator     namespace-policy   STRICT   17m
payment           namespace-policy   STRICT   17m
product-catalog   namespace-policy   STRICT   17m
recommendation    namespace-policy   STRICT   17m
shipping          namespace-policy   STRICT   17m

すべての Online Boutique の名前空間から認証ポリシーを削除します。

for ns in ad cart checkout currency email frontend loadgenerator payment \
  product-catalog recommendation shipping; do
    kubectl delete peerauthentication -n $ns namespace-policy
done;

予想される出力:

peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted
peerauthentication.security.istio.io "namespace-policy" deleted

frontend-external サービスの外部 IP アドレスを使用して Online Boutique にアクセスし、ページを更新します。ページが想定どおりに表示されます。

次のコマンドを実行して、別の Pod からプレーン HTTP で frontend サービスの curl を実行します。

kubectl debug --image istio/base --target istio-proxy -it \
  $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
  -n product-catalog -- \
  curl http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'

デフォルトでは TLS と平文の両方のトラフィックが受け入れられるため、ステータス 200 でリクエストが成功します。

Google Cloud コンソールでページを更新して [ワークロード] リストを表示すると、mTLS ステータスが Permissive であることが示されます。

ワークロードごとに相互 TLS を有効にする

特定のワークロードに PeerAuthentication ポリシーを設定するには、selector セクションを構成し、目的のワークロードに一致するラベルを指定する必要があります。ただし、Cloud Service Mesh は、サービスへのアウトバウンド mTLS トラフィックのワークロードレベルのポリシーを集計できません。この動作を管理するには、宛先ルールを構成する必要があります。

特定のワークロードに認証ポリシーを適用します。次のポリシーでは、ラベルとセレクタを使用して特定の frontend デプロイをターゲットにしていることに注意してください。

cat <<EOF | kubectl apply -n frontend -f -
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "frontend"
  namespace: "frontend"
spec:
  selector:
    matchLabels:
      app: frontend
  mtls:
    mode: STRICT
EOF

予想される出力:

peerauthentication.security.istio.io/frontend created

一致する宛先ルールを構成します。

cat <<EOF | kubectl apply -n frontend -f -
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "frontend"
spec:
  host: "frontend.demo.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
EOF

予想される出力:

destinationrule.networking.istio.io/frontend created

frontend-external サービスの外部 IP アドレスを使用して Online Boutique にアクセスし、ページを更新します。frontend service が STRICT mTLS に設定され、サイドカープロキシがリクエストをブロックしているため、このページは表示されません。
次のコマンドを実行して、別の Pod からプレーン HTTP で frontend サービスの curl を実行します。
```
kubectl exec testcurl -n default -- curl \
  http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
```
STRICT peerAuthentication ポリシーが適用されているサイドカーレスワークロードから平文トラフィックを送信しているため、このリクエストは失敗します。

認証ポリシーを削除します。

kubectl delete peerauthentication -n frontend frontend

予想される出力:

peerauthentication.security.istio.io "frontend" deleted

宛先ルールを削除します。

kubectl delete destinationrule -n frontend frontend

予想される出力:

destinationrule.networking.istio.io "frontend" deleted

メッシュ全体の mTLS を適用する

メッシュ内のすべてのサービスが平文トラフィックを受け入れるのを防ぐには、mTLS モードを STRICT に設定してメッシュ全体の PeerAuthentication ポリシーを設定します。メッシュ全体の PeerAuthentication ポリシーにはセレクタがないため、このポリシーはルート名前空間 istio-system に適用する必要があります。ポリシーをデプロイすると、コントロールプレーンが TLS 証明書を自動的にプロビジョニングし、ワークロードの相互認証を可能にします。

メッシュ全体の mTLS を適用します。

kubectl apply -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "mesh-wide"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT
EOF

予想される出力:

peerauthentication.security.istio.io/mesh-wide created

frontend-external サービスの外部 IP アドレスを使用して Online Boutique にアクセスし、ページを更新します。ページは表示されません。
次のコマンドを実行して、別の Pod からプレーン HTTP で frontend サービスの curl を実行します。
```
kubectl exec testcurl -n default -- curl \
  http://frontend.frontend.svc.cluster.local:80/ -o /dev/null -s -w '%{http_code}\n'
```
STRICT peerAuthentication ポリシーが適用されているサイドカーレスワークロードから平文トラフィックを送信しているため、このリクエストは失敗します。

mesh-wide ポリシーを削除します。

kubectl delete peerauthentication -n istio-system mesh-wide

予想される出力:

peerauthentication.security.istio.io "mesh-wide" deleted

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

追加料金の発生を回避するには、クラスタを削除します。

gcloud container clusters delete  CLUSTER_NAME  \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION

クラスタを維持して Online Boutique のサンプルを削除するには:

アプリケーションの名前空間を削除します。

  kubectl delete -f online-boutique/kubernetes-manifests/namespaces

予想される出力:

namespace "ad" deleted
namespace "cart" deleted
namespace "checkout" deleted
namespace "currency" deleted
namespace "email" deleted
namespace "frontend" deleted
namespace "loadgenerator" deleted
namespace "payment" deleted
namespace "product-catalog" deleted
namespace "recommendation" deleted
namespace "shipping" deleted

サービスエントリを削除します。

  kubectl delete -f online-boutique/istio-manifests/allow-egress-googleapis.yaml

予想される出力:

serviceentry.networking.istio.io "allow-egress-googleapis" deleted
serviceentry.networking.istio.io "allow-egress-google-metadata" deleted

次のステップ

PeerAuthentication ポリシーの構成に関する一般的なガイドについては、トランスポートのセキュリティの構成をご覧ください。

Cloud Service Mesh の例: mTLS コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

費用

始める前に

Ingress ゲートウェイをデプロイする

マネージド（TD）

マネージド（Istiod）

Online Boutique サンプル アプリケーションをデプロイする

サービスを表示する

TestCurl Pod を作成する

Online Boutique にアクセスする

名前空間ごとに相互 TLS を有効にする

認証ポリシーを検索して削除する

ワークロードごとに相互 TLS を有効にする

メッシュ全体の mTLS を適用する

クリーンアップ

次のステップ

Cloud Service Mesh の例: mTLS

Online Boutique サンプルアプリケーションをデプロイする