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

このページは Cloud Translation API によって翻訳されました。

Cloud Service Mesh の例: 承認

このチュートリアルでは、認可とは何か、Cloud Service Meshを使ってサンプル・アプリケーションで認可ポリシーを有効にする方法と、マイクロサービスに対して認可ポリシーを有効にする方法を説明ます。マイクロサービスへの AuthorizationPolicy から DENY へのアクセスを作成し、次にマイクロサービスへの AuthorizationPolicy から ALLOW への特定のアクセスを作成します。

認可とは

認証では本人確認（このサービスを使用する人は自分を誰だと言っているかの確認）を行います。認可では権限を確認（このサービスで何が許可されているのかの確認）を行います。ID はこの考え方の根幹を担っています。Cloud Service Mesh では、AuthorizationPolicies がメッシュ内のワークロード間通信を制御し、セキュリティとアクセスを向上させます。

マイクロサービスアーキテクチャでは、ネットワークの境界を越えて呼び出しが行われ、IP ベースのファイアウォールルールではワークロード間のアクセスを保護するのに不十分であることがよくあります。Cloud Service Mesh では、認可ルールを次のように設定できます。

メッシュ内のワークロードへのアクセス（ワークロード間またはエンドユーザーからワークロード間）の制御
ニーズに応じて、幅広く（または細かく）ポリシーを定義します。

ポリシーとベストプラクティスの構成の詳細については、Cloud Service Mesh による認可をご覧ください。

費用

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

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

始める前に

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

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

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）
デフォルトのインジェクションラベルを名前空間に適用します。
```
kubectl label namespace asm-ingress \
    istio.io/rev- istio-injection=enabled --overwrite
```
マネージド（Istiod）
推奨: 次のコマンドを実行して、デフォルトのインジェクションラベルを名前空間に適用します。
```
  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 つ表示されている場合は、1 つを削除します。クラスタに複数のコントロールプレーンチャネルを配置することはできません。
  出力で、NAME 列の値は、Cloud Service Mesh バージョンで使用可能なリリースチャンネルに対応するリビジョンラベルです。
2. リビジョンラベルを名前空間に適用します。
  kubectl label namespace asm-ingress \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
クラスタ内
推奨: 次のコマンドを実行して、デフォルトのインジェクションラベルを名前空間に適用します。
```
  kubectl label namespace asm-ingress \
      istio.io/rev- istio-injection=enabled --overwrite
```
デフォルトのインジェクションを使用することをおすすめしますが、リビジョンベースのインジェクションがサポートされています。 次の手順を使用します。
1. 次のコマンドを使用して、istiod のリビジョンラベルを探します。
  kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
2. リビジョンラベルを名前空間に適用します。次のコマンドで、REVISION_LABEL は前の手順でメモした istiod リビジョンラベルの値です。
  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 のショップが表示されます。

ワークロードの DenyAll 認可

このセクションでは、AuthorizationPolicy を追加して通貨サービスへのすべての受信トラフィックを拒否します。AuthorizationPolicies は、AuthorizationPolicies を Envoy で読み取り可能な構成に変換し、その構成をサイドカープロキシに適用することで機能します。これにより、Envoy プロキシはサービスへの受信リクエストを認可または拒否できます。

AuthorizationPolicy を currencyservice に適用します。YAML ファイルの currencyservice というラベルが一致していることに注意してください。

kubectl apply -f docs/authorization/currency-deny-all.yaml -n onlineboutique

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: currency-policy
spec:
  selector:
    matchLabels:
      app: currencyservice

ゲートウェイの EXTERNAL-IP にアクセスして、ウェブブラウザで Online Boutique を表示してみます。currency service からの認可エラー（500 内部サービスエラー）が表示されます。

サイドカープロキシのログを観察する

サイドカープロキシで何が起こっているかを確認するには、Pod のログを確認します。

currencyservice Pod の名前を取得します。

CURRENCY_POD=$(kubectl get pod -n onlineboutique |grep currency|awk '{print $1}')

トレースレベルのログを許可するように Envoy プロキシを設定します。デフォルトでは、ブロックされた認可呼び出しはログに記録されません。
```
kubectl debug --image istio/base --target istio-proxy -it $CURRENCY_POD -n onlineboutique -- curl -X POST "http://localhost:15000/logging?level=trace"
```
予想される出力: none {:.devsite-disable-click-to-copy} active loggers: admin: trace alternate_protocols_cache: trace ... tracing: trace upstream: trace udp: trace wasm: trace
curl を使用して EXTERNAL_IP にトラフィックを送信し、ログを生成します。
```
for i in {0..10}; do
curl -s -I $FRONTEND_IP ; done
```

istio-proxy でロールベースのアクセス制御（RBAC）関連のログを表示します。

kubectl logs -n onlineboutique $CURRENCY_POD -c istio-proxy | grep -m5 rbac

予想される出力:

2022-07-08T14:19:20.442920Z     debug   envoy rbac      checking request: requestedServerName: outbound_.7000_._.currencyservice.onlineboutique.svc.cluster.local, sourceIP: 10.8.8.5:34080, directRemoteIP: 10.8.8.5:34080, remoteIP: 10.8.8.5:34080,localAddress: 10.8.0.6:7000, ssl: uriSanPeerCertificate: spiffe://christineskim-tf-asm.svc.id.goog/ns/onlineboutique/sa/default, dnsSanPeerCertificate: , subjectPeerCertificate: OU=istio_v1_cloud_workload,O=Google LLC,L=Mountain View,ST=California,C=US, headers: ':method', 'POST'
2022-07-08T14:19:20.442944Z     debug   envoy rbac      enforced denied, matched policy none
2022-07-08T14:19:20.442965Z     debug   envoy http      [C73987][S13078781800499437460] Sending local reply with details rbac_access_denied_matched_policy[none]
  ```

ログに enforced denied というメッセージが出力されます。これは、currencyservice が受信リクエストをブロックするように設定されていることを表しています。

制限付きアクセスを許可する

DENYALL ポリシーの代わりに、特定のワークロードのみを許可するようにアクセスを設定できます。これは、認可されたサービス間の通信のみを許可するマイクロサービスアーキテクチャに関連します。

このセクションでは、frontend と checkout サービスが currency サービスと通信できるようにします。

次のファイルでは、特定の source.principal（クライアント）が currencyservice へのアクセスを許可されています。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: currency-policy
spec:
  selector:
    matchLabels:
      app: currencyservice
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/onlineboutique/sa/frontend"]
  - from:
    - source:
        principals: ["cluster.local/ns/onlineboutique/sa/checkoutservice"]

ポリシーを適用します。

kubectl apply -f docs/authorization/currency-allow-frontend-checkout.yaml -n onlineboutique

ウェブブラウザで EXTERNAL-IP にアクセスすると、Online Boutique にアクセスできるようになります。

クリーンアップ

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

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

プロジェクトの削除

Cloud Shell で、プロジェクトを削除します。

gcloud projects delete PROJECT_ID

リソースを削除する

クラスタを維持して Online Boutique のサンプルを削除するには:
1. アプリケーションの名前空間を削除します。
```
kubectl delete namespace onlineboutique
```
  予想される出力:
```
namespace "onlineboutique" deleted
```
2. Ingress ゲートウェイの Namespace を削除します。
```
kubectl delete namespace asm-ingress
```
  予想される出力:
```
amespace "asm-ingress" deleted
```

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

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

次のステップ

PeerAuthentication ポリシーの構成に関する一般的なガイドについては、トランスポートのセキュリティの構成をご覧ください。
メッシュセキュリティをモニタリングするで、メッシュのセキュリティダッシュボードを確認します。
認可ポリシーの高度な機能を構成するで、認可ポリシーの詳細を確認します。
Cloud Service Mesh のセキュリティベストプラクティスについて十分に理解します。

Cloud Service Mesh の例: 承認

認可とは

費用

始める前に

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

マネージド（TD）

マネージド（Istiod）

クラスタ内

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

サービスを表示する

ワークロードの DenyAll 認可

サイドカー プロキシのログを観察する

制限付きアクセスを許可する

クリーンアップ

プロジェクトの削除

リソースを削除する

次のステップ

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

サイドカープロキシのログを観察する