Envoy とロードバランシング API を使用してサービスのセキュリティを設定する

このガイドでは、ロードバランシング API を使用して、Traffic Director と Envoy プロキシでデプロイされたサービスの認証と認可を構成する手順について説明します。サービスルーティング API を使用する場合は、Envoy を使用したサービスセキュリティの設定をご覧ください。

Traffic Director サービスのセキュリティの詳細については、Traffic Director サービスセキュリティをご覧ください。

要件

Envoy で Traffic Director サービスのセキュリティを構成する前に、次の前提条件を満たしていることを確認してください。

xDS v3 API では Envoy バージョン 1.16.4 以降を使用します。
Traffic Director をデプロイするためのすべての要件を満たすことができます。これらの要件の詳細については、Envoy を使用して Traffic Director を設定する準備をするをご覧ください。
Envoy を使用して Traffic Director を設定する準備をするで説明されているように、サービスセキュリティを使用するための Traffic Director と Google Cloud サービスメッシュリソースを作成または更新するための十分な権限があります。

設定を準備する

以降のセクションでは、Traffic Director セキュリティサービスを設定する前に完了しておく必要のあるタスクについて説明します。タスクは次のとおりです。

Google Cloud CLI の更新
変数の設定
Traffic Director が Certificate Authority Service と連携するために必要な API の有効化

`gcloud` コマンドラインツールを更新する

Google Cloud CLI を更新するには、ローカルマシンで次のコマンドを実行します。

gcloud components update

環境変数を設定する

このドキュメントの例では、一貫した値を含むコードをコピーして貼り付けできるように、次の変数を設定します。次の値を使用します。

PROJECT_ID: プロジェクトの ID に置き換えます。
CLUSTER_NAME: 使用するクラスタ名（secure-td-cluster など）に置き換えます。
ZONE: クラスタが配置されているゾーンに置き換えます。
GKE_CLUSTER_URL: https://container.googleapis.com/v1/projects/PROJECT_ID/locations/ZONE/clusters/CLUSTER_NAME に置き換えます。
WORKLOAD_POOL: PROJECT_ID.svc.id.goog に置き換えます。
K8S_NAMESPACE: default に置き換えます。
DEMO_CLIENT_KSA: 実際のクライアントの Kubernetes サービスアカウントの名前に置き換えます。
DEMO_SERVER_KSA: 実際のサーバーの Kubernetes サービスアカウントの名前に置き換えます。
PROJNUM: プロジェクトのプロジェクト番号に置き換えます。プロジェクト番号は、Google Cloud Console または次のコマンドで確認できます。
```
gcloud projects describe PROJECT_ID --format="value(projectNumber)"
```
SA_GKE: service-PROJNUM@container-engine-robot.iam.gserviceaccount.com に置き換えます。
CLUSTER_VERSION: 利用可能な最新のバージョンに置き換えます。詳細については、Rapid チャンネルのリリースノートをご覧ください。必要な最小バージョンは 1.21.4-gke.1801 です。これは、この例で使用する GKE クラスタバージョンです。

ここで値を設定します。

# Substitute your project ID
PROJECT_ID=PROJECT_ID

# GKE cluster name and zone for this example.
CLUSTER_NAME=CLUSTER_NAME
ZONE=ZONE

# GKE cluster URL derived from the above
GKE_CLUSTER_URL="https://container.googleapis.com/v1/projects/PROJECT_ID/locations/ZONE/clusters/CLUSTER_NAME"

# Workload pool to be used with the GKE cluster
WORKLOAD_POOL="PROJECT_ID.svc.id.goog"

# Kubernetes namespace to run client and server demo.
K8S_NAMESPACE=K8S_NAMESPACE
DEMO_CLIENT_KSA=DEMO_CLIENT_KSA
DEMO_SERVER_KSA=DEMO_SERVER_KSA

# Compute other values
# Project number for your project
PROJNUM=PROJNUM

CLUSTER_VERSION=CLUSTER_VERSION
SA_GKE=service-PROJNUM@container-engine-robot.iam.gserviceaccount.com

API を有効にする

gcloud services enable コマンドを使用して、Certificate Authority Service で Traffic Director のセキュリティを設定するために必要なすべての API を有効にします。

gcloud services enable \
   container.googleapis.com \
   cloudresourcemanager.googleapis.com \
   compute.googleapis.com \
   trafficdirector.googleapis.com \
   networkservices.googleapis.com \
   networksecurity.googleapis.com \
   privateca.googleapis.com \
   gkehub.googleapis.com

GKE クラスタを作成または更新する

Traffic Director サービスのセキュリティは、GKE と CA Service の統合に依存します。GKE クラスタは、設定要件に加えて、次の要件を満たしている必要があります。

1.21.4-gke.1801 の最小クラスタバージョンを使用します。新しいバージョンの機能が必要な場合は、Rapid リリースチャンネルからそのバージョンを取得できます。
証明書を発行する認証局の作成で説明されているように、GKE クラスタを有効にして、メッシュ証明書で構成する必要があります。

Workload Identity を使用する新しいクラスタを作成します。既存のクラスタを更新する場合は、次のステップに進みます。--tags に指定する値は、Cloud Load Balancing コンポーネントを使用して Traffic Director を構成するのセクションで説明している firewall-rules create コマンドの --target-tags フラグに渡された名前と一致している必要があります。
```
# Create a GKE cluster with GKE managed mesh certificates.
gcloud container clusters create CLUSTER_NAME \
  --release-channel=rapid \
  --scopes=cloud-platform \
  --image-type=cos_containerd \
  --machine-type=e2-standard-2 \
  --zone=ZONE \
  --workload-pool=PROJECT_ID.svc.id.goog \
  --enable-mesh-certificates \
  --cluster-version=CLUSTER_VERSION \
  --enable-ip-alias \
  --tags=allow-health-checks \
  --workload-metadata=GKE_METADATA
```
クラスタの作成が完了するまでに数分かかることがあります。
既存のクラスタを使用している場合は、Workload Identity と GKE メッシュ証明書を有効にします。クラスタが --enable-ip-alias フラグで作成されていることを確認してください。このフラグは、update コマンドでは使用できません。
```
gcloud container clusters update CLUSTER_NAME \
  --enable-mesh-certificates
```
次のコマンドを実行して、kubectl コマンドのデフォルトクラスタとして新しいクラスタに切り替えます。
```
gcloud container clusters get-credentials CLUSTER_NAME \
  --zone ZONE
```

マルチクラスタ環境でのデプロイ

マルチクラスタ環境にデプロイする場合は、このセクションで説明する一般的な手順を行います。以下の手順は、一方のクラスタでクライアント Pod が実行され、もう一方のクラスタでサーバー Pod が実行されていることを前提としています。

前のセクションの手順に沿って、クラスタを作成または更新します。

次のコマンドを使用して、各クラスタの Pod IP アドレス範囲を取得します。

gcloud compute firewall-rules list \
  --filter="name~gke-{CLUSTER_NAME}-[0-9a-z]*-all" \
  --format="value(sourceRanges)"

たとえば、cluster-a と cluster-b という名前のクラスタの場合、次のような結果が返されます。

cluster-a, pod CIDR: 10.4.0.0/14, node network tag: gke-cluster-a-9cd18751-node
cluster-b, pod CIDR: 10.8.0.0/14, node network tag: gke-cluster-b-acd14479-node

クラスタが互いに通信できるようにする VPC ファイアウォールルールを作成します。たとえば、次のコマンドは、cluster-a Pod IP アドレスが cluster-b ノードと通信できるようにするファイアウォールルールを作成します。
```
gcloud compute firewall-rules create per-cluster-a-pods \
  --allow="tcp,udp,icmp,esp,ah,sctp" \
  --target-tags="gke-cluster-b-acd14479-node"
```
次のコマンドは、cluster-b Pod IP アドレスが cluster-a ノードと通信することを許可するファイアウォールルールを作成します。
```
gcloud compute firewall-rules create per-cluster-b-pods \
  --allow="tcp,udp,icmp,esp,ah,sctp" \
  --target-tags="gke-cluster-a-9cd18751-node"
```

フリートにクラスタを登録する

GKE クラスタの作成で作成または更新したクラスタをフリートに登録します。クラスタを登録すると、複数のプロジェクトにまたがるクラスタを簡単に構成できるようになります。

各ステップが完了するまでに最大で 10 分かかることがあります。

クラスタをフリートに登録します。
```
gcloud container fleet memberships register CLUSTER_NAME \
  --gke-cluster=ZONE/CLUSTER_NAME \
  --enable-workload-identity --install-connect-agent \
  --manifest-output-file=MANIFEST-FILE_NAME
```
変数を、次のように置き換えます。
- CLUSTER_NAME: クラスタの名前。
- ZONE: クラスタのゾーン。
- MANIFEST-FILE_NAME: これらのコマンドが登録用のマニフェストを生成するファイルパス。
登録プロセスが成功すると、次のようなメッセージが表示されます。
```
Finished registering the cluster CLUSTER_NAME with the fleet.
```

生成されたマニフェストファイルをクラスタに適用します。

kubectl apply -f MANIFEST-FILE_NAME

適用プロセスが成功すると、次のようなメッセージが表示されます。

namespace/gke-connect created
serviceaccount/connect-agent-sa created
podsecuritypolicy.policy/gkeconnect-psp created
role.rbac.authorization.k8s.io/gkeconnect-psp:role created
rolebinding.rbac.authorization.k8s.io/gkeconnect-psp:rolebinding created
role.rbac.authorization.k8s.io/agent-updater created
rolebinding.rbac.authorization.k8s.io/agent-updater created
role.rbac.authorization.k8s.io/gke-connect-agent-20210416-01-00 created
clusterrole.rbac.authorization.k8s.io/gke-connect-impersonation-20210416-01-00 created
clusterrolebinding.rbac.authorization.k8s.io/gke-connect-impersonation-20210416-01-00 created
clusterrolebinding.rbac.authorization.k8s.io/gke-connect-feature-authorizer-20210416-01-00 created
rolebinding.rbac.authorization.k8s.io/gke-connect-agent-20210416-01-00 created
role.rbac.authorization.k8s.io/gke-connect-namespace-getter created
rolebinding.rbac.authorization.k8s.io/gke-connect-namespace-getter created
secret/http-proxy created
deployment.apps/gke-connect-agent-20210416-01-00 created
service/gke-connect-monitoring created
secret/creds-gcp create

クラスタからメンバーリソースを取得します。
```
kubectl get memberships membership -o yaml
```
出力には、フリートによって割り当てられた Workoad Identity プールが含まれています。ここで、PROJECT_ID はプロジェクト ID です。
```
workload_identity_pool: PROJECT_ID.svc.id.goog
```
これは、クラスタが正常に登録されたことを意味します。

証明書を発行する認証局を作成する

Pod に対して証明書を発行するには、CA Service プールと次の認証局（CA）を作成します。

ルート CA。これは、発行されるすべてのメッシュ証明書のルートオブトラストです。既存のルート CA が存在する場合はそれを使用できます。ルート CA を enterprise 階層に作成します。ルート CA は有効期間が長く、少量の証明書の発行に適しています。
下位 CA。この CA はワークロード用の証明書を発行します。クラスタがデプロイされるリージョンで下位 CA を作成します。下位 CA を devops 階層に作成します。下位 CA は有効期間が短く、大量の証明書の発行に適しています。

下位 CA の作成は任意ですが、GKE メッシュの証明書を発行するためにルート CA を使用するよりも、下位 CA を作成することを強くおすすめします。ルート CA を使用してメッシュ証明書を発行する場合は、デフォルトの構成ベースの発行モードが引き続き許可されることを確認してください。

下位 CA はクラスタと異なるリージョンに設定できますが、パフォーマンスを最適化するために、クラスタと同じリージョンに作成することをおすすめします。ただし、ルート CA または下位 CA は別々のリージョンに作成でき、それによるパフォーマンスや可用性への影響はありません。

CA Service では、以下のリージョンがサポートされます。

リージョン名	リージョンの説明
`asia-east1`	台湾
`asia-east2`	香港
`asia-northeast1`	東京
`asia-northeast2`	大阪
`asia-northeast3`	ソウル
`asia-south1`	ムンバイ
`asia-south2`	デリー
`asia-southeast1`	シンガポール
`asia-southeast2`	ジャカルタ
`australia-southeast1`	シドニー
`australia-southeast2`	メルボルン
`europe-central2`	ワルシャワ
`europe-north1`	フィンランド
`europe-southwest1`	マドリッド
`europe-west1`	ベルギー
`europe-west2`	ロンドン
`europe-west3`	フランクフルト
`europe-west4`	オランダ
`europe-west6`	チューリッヒ
`europe-west8`	ミラノ
`europe-west9`	パリ
`europe-west10`	ベルリン
`europe-west12`	トリノ
`me-central1`	ドーハ
`me-central2`	ダンマーム
`me-west1`	テルアビブ
`northamerica-northeast1`	モントリオール
`northamerica-northeast2`	トロント
`southamerica-east1`	サンパウロ
`southamerica-west1`	サンティアゴ
`us-central1`	アイオワ
`us-east1`	サウスカロライナ
`us-east4`	北バージニア
`us-east5`	コロンバス
`us-south1`	ダラス
`us-west1`	オレゴン
`us-west2`	ロサンゼルス
`us-west3`	ソルトレイクシティ
`us-west4`	ラスベガス

サポートされているロケーションのリストを確認するには、次のコマンドを実行します。

gcloud privateca locations list

CA プールと CA を作成する個人に IAM roles/privateca.caManager を付与します。MEMBER の正しい形式は user:userid@example.com です。その個人が現在のユーザーであれば、シェルコマンド $(gcloud auth list --filter=status:ACTIVE --format="value(account)") を使用してユーザー ID を取得できます。
```
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=MEMBER \
  --role=roles/privateca.caManager
```
IAM ポリシーを変更する必要があるユーザーに CA Service のロール role/privateca.admin を付与します。MEMBER は、このアクセスを必要とするユーザーです（特に、privateca.auditor ロールと privateca.certificateManager ロールを付与する次の手順を行うユーザーです）。
```
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=MEMBER \
  --role=roles/privateca.admin
```

ルート CA Service プールを作成します。

gcloud privateca pools create ROOT_CA_POOL_NAME \
  --location ROOT_CA_POOL_LOCATION \
  --tier enterprise

ルート CA を作成します。

gcloud privateca roots create ROOT_CA_NAME --pool ROOT_CA_POOL_NAME \
  --subject "CN=ROOT_CA_NAME, O=ROOT_CA_ORGANIZATION" \
  --key-algorithm="ec-p256-sha256" \
  --max-chain-length=1 \
  --location ROOT_CA_POOL_LOCATION

このデモ設定では、変数に次の値を使用します。

ROOT_CA_POOL_NAME=td_sec_pool
ROOT_CA_NAME=pkcs2-ca
ROOT_CA_POOL_LOCATION=us-east1
ROOT_CA_ORGANIZATION="TestCorpLLC"

下位プールと下位 CA を作成します。デフォルトの構成ベースの発行モードが許可されることを確認します。

gcloud privateca pools create SUBORDINATE_CA_POOL_NAME \
  --location SUBORDINATE_CA_POOL_LOCATION \
  --tier devops

gcloud privateca subordinates create SUBORDINATE_CA_NAME \
  --pool SUBORDINATE_CA_POOL_NAME \
  --location SUBORDINATE_CA_POOL_LOCATION \
  --issuer-pool ROOT_CA_POOL_NAME \
  --issuer-location ROOT_CA_POOL_LOCATION \
  --subject "CN=SUBORDINATE_CA_NAME, O=SUBORDINATE_CA_ORGANIZATION" \
  --key-algorithm "ec-p256-sha256" \
  --use-preset-profile subordinate_mtls_pathlen_0

このデモ設定では、変数に次の値を使用します。

SUBORDINATE_CA_POOL_NAME="td-ca-pool"
SUBORDINATE_CA_POOL_LOCATION=us-east1
SUBORDINATE_CA_NAME="td-ca"
SUBORDINATE_CA_ORGANIZATION="TestCorpLLC"
ROOT_CA_POOL_NAME=td_sec_pool
ROOT_CA_POOL_LOCATION=us-east1

GKE サービスアカウントからのアクセスを許可するために、ルート CA プールの IAM privateca.auditor ロールを付与します。

gcloud privateca pools add-iam-policy-binding ROOT_CA_POOL_NAME \
 --location ROOT_CA_POOL_LOCATION \
 --role roles/privateca.auditor \
 --member="serviceAccount:service-PROJNUM@container-engine-robot.iam.gserviceaccount.com"

GKE サービスアカウントからのアクセスを許可するために、下位 CA プールの IAM privateca.certificateManager ロールを付与します。

gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_NAME \
  --location SUBORDINATE_CA_POOL_LOCATION \
  --role roles/privateca.certificateManager \
  --member="serviceAccount:service-PROJNUM@container-engine-robot.iam.gserviceaccount.com"

次の WorkloadCertificateConfig YAML 構成を保存して、メッシュ証明書を発行する方法をクラスタに指示します。

apiVersion: security.cloud.google.com/v1
kind: WorkloadCertificateConfig
metadata:
  name: default
spec:
  # Required. The CA service that issues your certificates.
  certificateAuthorityConfig:
    certificateAuthorityServiceConfig:
      endpointURI: ISSUING_CA_POOL_URI

  # Required. The key algorithm to use. Choice of RSA or ECDSA.
  #
  # To maximize compatibility with various TLS stacks, your workloads
  # should use keys of the same family as your root and subordinate CAs.
  #
  # To use RSA, specify configuration such as:
  #   keyAlgorithm:
  #     rsa:
  #       modulusSize: 4096
  #
  # Currently, the only supported ECDSA curves are "P256" and "P384", and the only
  # supported RSA modulus sizes are 2048, 3072 and 4096.
  keyAlgorithm:
    rsa:
      modulusSize: 4096

  # Optional. Validity duration of issued certificates, in seconds.
  #
  # Defaults to 86400 (1 day) if not specified.
  validityDurationSeconds: 86400

  # Optional. Try to start rotating the certificate once this
  # percentage of validityDurationSeconds is remaining.
  #
  # Defaults to 50 if not specified.
  rotationWindowPercentage: 50

次のように置き換えます。

クラスタが実行されるプロジェクトのプロジェクト ID:
```
PROJECT_ID
```
メッシュ証明書を発行する CA の完全修飾 URI（ISSUING_CA_POOL_URI）。下位 CA（推奨）またはルート CA のいずれかを指定できます。形式は次のとおりです。
```
//privateca.googleapis.com/projects/PROJECT_ID/locations/SUBORDINATE_CA_POOL_LOCATION/caPools/SUBORDINATE_CA_POOL_NAME
```

次の TrustConfig YAML 構成を保存して、発行済み証明書を信頼する方法をクラスタに指示します。

apiVersion: security.cloud.google.com/v1
kind: TrustConfig
metadata:
  name: default
spec:
  # You must include a trustStores entry for the trust domain that
  # your cluster is enrolled in.
  trustStores:
  - trustDomain: PROJECT_ID.svc.id.goog
    # Trust identities in this trustDomain if they appear in a certificate
    # that chains up to this root CA.
    trustAnchors:
    - certificateAuthorityServiceURI: ROOT_CA_POOL_URI

次のように置き換えます。

クラスタが実行されるプロジェクトのプロジェクト ID:
```
PROJECT_ID
```

ルート CA プールの完全修飾 URI（ROOT_CA_POOL_URI）。形式は次のとおりです。

//privateca.googleapis.com/projects/PROJECT_ID/locations/ROOT_CA_POOL_LOCATION/caPools/ROOT_CA_POOL_NAME

この構成をクラスタに適用します。

kubectl apply -f WorkloadCertificateConfig.yaml
kubectl apply -f TrustConfig.yaml

Identity and Access Management を構成する

設定に必要なリソースを作成するには、compute.NetworkAdmin ロールが必要です。このロールには、必要なリソースの作成、更新、削除、一覧表示、使用（他のリソースでの参照）に必要なすべての権限が含まれています。プロジェクトのオーナー編集者には、このロールが自動的に付与されます。

これらのリソースをバックエンドサービスとターゲット HTTPS プロキシリソースで参照する場合、networksecurity.googleapis.com.clientTlsPolicies.use と networksecurity.googleapis.com.serverTlsPolicies.use は適用されません。

今後これらの権限が適用され、compute.NetworkAdmin ロールを使用している場合、このチェックの適用時に問題は検出されません。

カスタムロールを使用していて、今後このチェックが適用される場合は、各 .use 権限を含める必要があります。そうしないと、今後、バックエンドサービスまたはターゲット HTTPS プロキシからそれぞれ clientTlsPolicy または serverTlsPolicy を参照するために必要な権限がカスタムロールに含まれなくなる場合があります。

次の手順では、デフォルトのサービスアカウントで Traffic Director のセキュリティ API にアクセスし、Kubernetes サービスアカウントを作成します。

デフォルトのサービスアカウントが Traffic Director のセキュリティ API にアクセスできるように IAM を構成します。

GSA_EMAIL=$(gcloud iam service-accounts list --format='value(email)' \
   --filter='displayName:Compute Engine default service account')

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member serviceAccount:${GSA_EMAIL} \
  --role roles/trafficdirector.client

Kubernetes サービスアカウントを設定します。次のセクションで説明するクライアントとサーバーのデプロイでは、Kubernetes サーバーとクライアントのサービスアカウント名を使用します。
```
kubectl create serviceaccount --namespace K8S_NAMESPACE DEMO_SERVER_KSA
kubectl create serviceaccount --namespace K8S_NAMESPACE DEMO_CLIENT_KSA
```
Kubernetes サービスアカウントがデフォルトの Compute Engine サービスアカウントの権限を借用できるようにするには、両者の間に IAM ポリシーバインディングを作成します。このバインディングにより、Kubernetes サービスアカウントがデフォルトの Compute Engine サービスアカウントとして機能します。
```
gcloud iam service-accounts add-iam-policy-binding  \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/DEMO_SERVER_KSA]" ${GSA_EMAIL}

gcloud iam service-accounts add-iam-policy-binding  \
  --role roles/iam.workloadIdentityUser  \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/DEMO_CLIENT_KSA]" ${GSA_EMAIL}
```

Kubernetes サービスアカウントにアノテーションを付け、デフォルトの Compute Engine サービスアカウントに関連付けます。

kubectl annotate --namespace K8S_NAMESPACE \
  serviceaccount DEMO_SERVER_KSA \
  iam.gke.io/gcp-service-account=${GSA_EMAIL}

kubectl annotate --namespace K8S_NAMESPACE \
  serviceaccount DEMO_CLIENT_KSA \
  iam.gke.io/gcp-service-account=${GSA_EMAIL}

Traffic Director を設定する

次の手順に沿って、サイドカーインジェクタをインストールし、テストサービスを設定して、他のデプロイタスクを完了します。

クラスタに Envoy サイドカーインジェクタをインストールする

自動 Envoy インジェクションによる GKE Pod での Traffic Director の設定の以下の両セクションの手順に沿って、クラスタで Envoy サイドカーインジェクションをデプロイして有効にします。

テストサービスを設定する前に、両方の手順が完了していることを確認してください。

テストサービスを設定する

Envoy サイドカーインジェクタをインストールしたら、次の手順で Deployment のテストサービスを設定します。

wget -q -O -  https://storage.googleapis.com/traffic-director/security/ga/service_sample.yaml | sed -e s/DEMO_SERVER_KSA_PLACEHOLDER/DEMO_SERVER_KSA/g > service_sample.yaml

kubectl apply -f service_sample.yaml

ファイル service_sample.yaml には、デモサーバーアプリケーションの PodSpec が含まれています。Traffic Director のセキュリティに固有のアノテーションも含まれます。

Traffic Director のプロキシメタデータ

PodSpec は proxyMetadata アノテーションを指定します。

spec:
...
      annotations:
        cloud.google.com/proxyMetadata: '{"app": "payments"}'
...

Pod が初期化されると、サイドカープロキシはこのアノテーションを取得し、Traffic Director に送信します。Traffic Director はこの情報を使用して、フィルタされた構成を返します。

このガイドの後半では、エンドポイントポリシーでエンドポイントマッチャーが指定されます。
エンドポイントマッチャーは、名前が app、値が payments のラベルを持つクライアントだけがフィルタされた構成を受信するよう指定します。

CA Service によって署名されたメッシュ証明書と鍵を使用する

PodSpec は enableManagedCerts アノテーションを指定します。

spec:
...
      annotations:
        ...
        cloud.google.com/enableManagedCerts: "true"
...

Pod が初期化されると、CA Service の署名付き証明書と鍵が自動的にローカルサイドカープロキシファイルシステムにマウントされます。

受信トラフィックインターセプトポートの構成

PodSpec は includeInboundPorts アノテーションを指定します。

spec:
...
      annotations:
        ...
        cloud.google.com/includeInboundPorts: "8000"
...

これは、サーバーアプリケーションが接続をリッスンするポートです。Pod が初期化されると、サイドカープロキシはこのアノテーションを取得し、Traffic Director に送信します。Traffic Director はこの情報を使用してフィルタされた構成を返します。これにより、このポートへのすべての着信トラフィックが傍受され、セキュリティポリシーを適用できます。

ヘルスチェックポートはアプリケーションポートとは異なるものにする必要があります。そうしないと、ヘルスチェックポートへの受信接続に同じセキュリティポリシーが適用され、接続が拒否されてサーバーが誤って異常としてマークされる可能性があります。

NEG を使用して GKE サービスを構成する

GKE サービスは、Traffic Director バックエンドサービスのバックエンドとして構成できるように、ネットワークエンドポイントグループ（NEG）で公開されている必要があります。この設定ガイドで提供されている service_sample.yaml パッケージは、次のアノテーションで NEG 名 service-test-neg を使用します。

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "service-test-neg"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

service_sample.yaml ファイルを変更する必要はありません。

NEG の名前を保存する

NEG の名前を NEG_NAME 変数に保存します。

NEG_NAME="service-test-neg"

クライアントアプリケーションを GKE にデプロイする

次のコマンドを実行して、Envoy プロキシをサイドカーとして使用するデモクライアントを起動します。これは、セキュリティ機能のデモに必要です。

wget -q -O -  https://storage.googleapis.com/traffic-director/security/ga/client_sample.yaml | sed -e s/DEMO_CLIENT_KSA_PLACEHOLDER/DEMO_CLIENT_KSA/g > client_sample.yaml

kubectl apply -f client_sample.yaml

クライアント PodSpec には、enableManagedCerts アノテーションのみが含まれます。これは、CA Service インスタンスによって署名された GKE マネージドメッシュ証明書と鍵に必要なボリュームをマウントするために必要です。

Traffic Director の Google Cloud リソースを構成する

Cloud Load Balancing コンポーネントを使用して Traffic Director を構成するの手順を行います。サンプルクライアントからのトラフィックがサンプルサービスにルーティングされていることを確認します。

Traffic Director の構成が完了し、認証ポリシーと認可ポリシーを構成できるようになりました。

サービス間のセキュリティを設定する

サービス間のセキュリティを設定するには、次のセクションの手順を使用します。

メッシュで mTLS を有効にする

メッシュに mTLS を設定するには、バックエンドサービスへの送信トラフィックを保護し、エンドポイントへの着信トラフィックを保護する必要があります。

ポリシー参照の形式

サーバー TLS ポリシー、クライアント TLS ポリシー、認証ポリシーを参照する場合は、次の形式にする必要があります。

projects/PROJECT_ID/locations/global/[serverTlsPolicies|clientTlsPolicies|authorizationPolicies]/[server-tls-policy|client-mtls-policy|authz-policy]

次に例を示します。

projects/PROJECT_ID/locations/global/serverTlsPolicies/server-tls-policy

projects/PROJECT_ID/locations/global/clientTlsPolicies/client-mtls-policy

projects/PROJECT_ID/locations/global/authorizationPolicies/authz-policy

バックエンドサービスへの送信トラフィックを保護する

送信トラフィックを保護するには、まず次のことを行うクライアント TLS ポリシーを作成します。

clientCertificate のプラグインとして google_cloud_private_spiffe を使用します。このプラグインは、Envoy が GKE マネージドメッシュ証明書をクライアント ID として使用するようにプログラミングします。
serverValidationCa のプラグインとして google_cloud_private_spiffe を使用します。このプラグインは、Envoy が GKE マネージドメッシュ証明書をサーバー検証に使用するようにプログラミングします。

次に、バックエンドサービスにクライアント TLS ポリシーを接続します。これにより、以下が実行されます。

クライアント TLS ポリシーの認証ポリシーを、バックエンドサービスのエンドポイトへの送信接続に適用します。
SAN（サブジェクト代替名）は、接続先サーバーの正確な ID を表明するようにクライアントに指示します。

client-mtls-policy.yaml ファイルにクライアント TLS ポリシーを作成します。

name: "client-mtls-policy"
clientCertificate:
  certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe
serverValidationCa:
- certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe

クライアント TLS ポリシーをインポートします。

gcloud network-security client-tls-policies import client-mtls-policy \
    --source=client-mtls-policy.yaml --location=global

クライアント TLS ポリシーをバックエンドサービスに接続します。これにより、クライアントからこのバックエンドサービスへのすべての送信リクエストに mTLS 認証が適用されます。

gcloud compute backend-services export td-gke-service \
    --global --destination=demo-backend-service.yaml

次の行を demo-backend-service.yaml に追加します。

securitySettings:
  clientTlsPolicy: projects/PROJECT_ID/locations/global/clientTlsPolicies/client-mtls-policy
  subjectAltNames:
    - "spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA"

次の値をインポートします。

gcloud compute backend-services import td-gke-service \
    --global --source=demo-backend-service.yaml

必要に応じて、次のコマンドを実行して、リクエストが失敗するかどうかを確認します。クライアントがエンドポイントからの証明書を要求しているものの、エンドポイントがセキュリティポリシーでプログラミングされていないため、これは想定内の失敗となります。

# Get the name of the Podrunning Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test.
TEST_CMD="wget -q -O - service-test; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

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

wget: server returned error: HTTP/1.1 503 Service Unavailable

エンドポイントへの受信トラフィックを保護する

受信トラフィックを保護するには、まず、次のことを行うサーバー TLS ポリシーを作成します。

serverCertificate のプラグインとして google_cloud_private_spiffe を使用します。このプラグインは、Envoy が GKE マネージドメッシュ証明書をサーバー ID として使用するようにプログラミングします。
clientValidationCa のプラグインとして google_cloud_private_spiffe を使用します。これは、Envoy が GKE マネージドメッシュ証明書をクライアント検証に使用するようにプログラミングします。

サーバーの TLS ポリシー値を server-mtls-policy.yaml というファイルに保存します。

name: "server-mtls-policy"
serverCertificate:
  certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe
mtlsPolicy:
  clientValidationCa:
  - certificateProviderInstance:
      pluginInstance: google_cloud_private_spiffe

サーバーの TLS ポリシーを作成します。

gcloud network-security server-tls-policies import server-mtls-policy \
    --source=server-mtls-policy.yaml --location=global

エンドポイントマッチャーを含む ep_mtls.yaml というファイルを作成し、サーバーの TLS ポリシーを接続します。

endpointMatcher:
  metadataLabelMatcher:
    metadataLabelMatchCriteria: MATCH_ALL
    metadataLabels:
    - labelName: app
      labelValue: payments
name: "ep"
serverTlsPolicy: projects/PROJECT_ID/locations/global/serverTlsPolicies/server-mtls-policy
type: SIDECAR_PROXY

エンドポイントマッチャーをインポートします。

gcloud network-services endpoint-policies import ep \
    --source=ep_mtls.yaml --location=global

設定を検証する

次の curl コマンドを実行します。リクエストが正常に完了すると、出力に x-forwarded-client-cert が表示されます。ヘッダーは、接続が mTLS 接続の場合にのみ出力されます。

# Get the name of the Podrunning Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test.
TEST_CMD="wget -q -O - service-test; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

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

GET /get HTTP/1.1
Host: service-test
content-length: 0
x-envoy-internal: true
accept: */*
x-forwarded-for: 10.48.0.6
x-envoy-expected-rq-timeout-ms: 15000
user-agent: curl/7.35.0
x-forwarded-proto: http
x-request-id: redacted
x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA

x-forwarded-client-cert ヘッダーはサーバー側の Envoy によって挿入され、独自の ID（サーバー）とソースクライアントの ID が含まれます。クライアント ID とサーバー ID の両方が表示されているため、これは mTLS 接続のシグナルです。

認可ポリシーでサービスレベルのアクセスを構成する

この手順では、ホスト名が service-test、ポートが 8000、HTTP メソッドが GET の DEMO_CLIENT_KSA アカウントによってリクエストが送信されることを許可する認可ポリシーを作成します。認可ポリシーを作成する前に、認可を使用してアクセスを制限するの注意事項をお読みください。

authz-policy.yaml という名前のファイルを作成して認可ポリシーを作成します。

action: ALLOW
name: authz-policy
rules:
- sources:
  - principals:
    - spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
  destinations:
  - hosts:
    - service-test
    ports:
    - 8000
    methods:
    - GET

ポリシーをインポートします。

gcloud network-security authorization-policies import authz-policy \
  --source=authz-policy.yaml \
  --location=global

ep_mtls.yaml ファイルに次の行を追加して、新しい承認ポリシーを参照するようにエンドポイントポリシーを更新します。
```
authorizationPolicy: projects/PROJECT_ID/locations/global/authorizationPolicies/authz-policy
```
エンドポイントポリシーでは、Envoy サイドカープロキシが app:payments というラベルを持つ Pod への受信リクエストに対して、mTLS と承認ポリシーの両方を適用する必要があることを指定しています。

ポリシーをインポートします。

gcloud network-services endpoint-policies import ep \
    --source=ep_mtls.yaml --location=global

設定を検証する

次のコマンドを実行して設定を検証します。

# Get the name of the Podrunning Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test.
# This is a valid request and will be allowed.
TEST_CMD="wget -q -O - service-test; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

予想される出力は次のようになります。

GET /get HTTP/1.1
Host: service-test
content-length: 0
x-envoy-internal: true
accept: */*
x-forwarded-for: redacted
x-envoy-expected-rq-timeout-ms: 15000
user-agent: curl/7.35.0
x-forwarded-proto: http
x-request-id: redacted
x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA

次のコマンドを実行して、承認ポリシーが無効なリクエストを正しく却下するどうかをテストします。

# Failure case
# Command to execute that tests connectivity to the service service-test.
# This is an invalid request and server will reject because the server
# authorization policy only allows GET requests.
TEST_CMD="wget -q -O - service-test --post-data='' ; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

予想される出力は次のようになります。

<RBAC: access denied HTTP/1.1 403 Forbidden>

Ingress ゲートウェイセキュリティを設定する

このセクションは、サイドカー自動インジェクタを使用した GKE クラスタの設定、認証局の作成、エンドポイントポリシーの作成など、サービス間のセキュリティセクションを完了していることを前提としています。

このセクションでは、TLS 接続を終端し、クラスタの内部クライアントからのリクエストを承認する Ingress ゲートウェイとして Envoy プロキシをデプロイします。

TLS を終端するように Ingress ゲートウェイを設定する手順は次のとおりです。

クラスタの内部 IP アドレスを使用して到達可能な Kubernetes Service をデプロイします。
1. このデプロイは、Kubernetes Service として公開され、Traffic Director に接続するスタンドアロンの Envoy プロキシで構成されています。
TLS を終端するサーバー TLS ポリシーを作成します。
受信リクエストを承認する認可ポリシーを作成します。

Ingress ゲートウェイサービスを GKE にデプロイする

次のコマンドを実行して、GKE に Ingress ゲートウェイサービスをデプロイします。

wget -q -O -  https://storage.googleapis.com/traffic-director/security/ga/gateway_sample_xdsv3.yaml | sed -e s/PROJECT_NUMBER_PLACEHOLDER/PROJNUM/g | sed -e s/NETWORK_PLACEHOLDER/default/g | sed -e s/DEMO_CLIENT_KSA_PLACEHOLDER/DEMO_CLIENT_KSA/g > gateway_sample.yaml

kubectl apply -f gateway_sample.yaml

ファイル gateway_sample.yaml は Ingress ゲートウェイの仕様です。以下のセクションでは、この仕様への追加について説明します。

Traffic Director サイドカーインジェクションの無効化

gateway_sample.yaml 仕様では、Envoy プロキシを唯一のコンテナとしてデプロイします。前のステップでは、Envoy をサイドカーとしてアプリケーションコンテナに挿入しました。複数の Envoy でリクエストを処理しないように、次のステートメントを使用して、この Kubernetes Service のサイドカーインジェクションを無効にできます。

sidecar.istio.io/inject: "false"

正しいボリュームをマウントする

gateway_sample.yaml 仕様ではボリューム gke-workload-certificates をマウントします。このボリュームはサイドカーのデプロイでも使用されますが、アノテーション cloud.google.com/enableManagedCerts: "true" が検出されると、サイドカーインジェクタによって自動的に追加されます。gke-workload-certificates ボリュームには、設定した CA Service インスタンスによって署名される GKE マネージド SPIFFE 証明書と鍵が含まれます。

クラスタの内部 IP アドレスを設定する

ClusterInternal タイプのサービスを使用して Ingress ゲートウェイを構成します。これにより、mesh-gateway の内部解決可能な DNS ホスト名が作成されます。クライアントが mesh-gateway:443 にリクエストを送信すると、Kubernetes はすぐにリクエストを Ingress ゲートウェイの Envoy Deployment のポート 8080 に転送します。

Ingress ゲートウェイで TLS を有効にする

Ingress ゲートウェイで TLS を有効にする手順は次のとおりです。

server-tls-policy.yaml という名前のファイル内の値を使用して、TLS 接続を終了するサーバー TLS ポリシーリソースを作成します。
```
description: tls server policy
name: server-tls-policy
serverCertificate:
  certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe
```

サーバーの TLS ポリシーをインポートします。

gcloud network-security server-tls-policies import server-tls-policy \
    --source=server-tls-policy.yaml --location=global

すべてのリクエストを td-gke-service バックエンドサービスにルーティングする新しい URL マップを作成します。Ingress ゲートウェイは、受信リクエストを処理して、td-gke-service バックエンドサービスに属する Pod に送信します。
```
gcloud compute url-maps create td-gke-ig-url-map \
   --default-service=td-gke-service
```
ファイル td-gke-https-proxy.yaml で新しいターゲット HTTPS プロキシを作成し、前もって作成した URL マップとサーバーの TLS ポリシーを接続します。これにより、受信 TLS トラフィックを終了するように Envoy の Ingress ゲートウェイを構成します。
```
kind: compute#targetHttpsProxy
name: td-gke-https-proxy
proxyBind: true
urlMap: https://www.googleapis.com/compute/beta/projects/PROJECT_ID/global/urlMaps/td-gke-ig-url-map
serverTlsPolicy: projects/PROJECT_ID/locations/global/serverTlsPolicies/server-tls-policy
```

ポリシーをインポートします。

gcloud compute target-https-proxies import td-gke-https-proxy \
   --global --source=td-gke-https-proxy.yaml

新しい転送ルールを作成し、ターゲット HTTPS プロキシを接続します。これにより、Envoy プロキシがポート 8080 でリッスンし、td-gke-https-proxy で定義されたルーティングポリシーとセキュリティポリシーを適用します。
```
gcloud compute forwarding-rules create td-gke-gateway-forwarding-rule --global \
  --load-balancing-scheme=INTERNAL_SELF_MANAGED --address=0.0.0.0 \
  --target-https-proxy=td-gke-https-proxy --ports 8080 \
  --network default
```
必要に応じて、以下のすべての条件が満たされる場合に、バックエンドの承認ポリシーを更新し、リクエストを許可します。
- DEMO_CLIENT_KSA によって送信されたリクエスト。（Ingress ゲートウェイのデプロイでは、DEMO_CLIENT_KSA サービスアカウントが使用されます。）
- ホストが mesh-gateway または service-test のリクエスト
- ポート: 8000
バックエンドの承認ポリシーを構成していない限り、これらのコマンドを実行する必要はありません。エンドポイントに承認ポリシーがない場合、または承認ポリシーにホストまたはソースのプリンシパルの一致が含まれない場合、このステップなしでリクエストが許可されます。これらの値を authz-policy.yaml に追加します。
```
action: ALLOW
name: authz-policy
rules:
- sources:
  - principals:
    - spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
  destinations:
  - hosts:
    - service-test
    - mesh-gateway
    ports:
    - 8000
    methods:
    - GET
```

ポリシーをインポートします。

gcloud network-security authorization-policies import authz-policy \
  --source=authz-policy.yaml \
  --location=global

Ingress ゲートウェイの Deployment を検証する

debug という新しいコンテナを使用して Ingress ゲートウェイにリクエストを送信し、Deployment を検証します。

次の仕様では、アノテーション "sidecar.istio.io/inject":"false" によって Traffic Director サイドカーインジェクタがサイドカープロキシを自動的に挿入しないようにしています。リクエストルーティングで debug コンテナをサポートするサイドカーはありません。コンテナは、ルーティングのために Ingress ゲートウェイに接続する必要があります。

この仕様には、サーバー証明書の検証を無視する --no-check-certificate フラグが含まれています。debug コンテナには、TLS を終了するために Ingress ゲートウェイが使用する、CA Service によって署名された有効な証明書に必要な認証局検証証明書がありません。

本番環境では、CA Service の検証証明書をダウンロードし、それをクライアントにマウントまたはインストールすることをおすすめします。検証証明書をインストールしたら、wget コマンドの --no-check-certificate オプションを削除します。

次のコマンドを実行します。

kubectl run -i --tty --rm debug --image=busybox --restart=Never  --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }'  -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway; echo"

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

GET / HTTP/1.1
Host: 10.68.7.132
x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
x-envoy-expected-rq-timeout-ms: 15000
x-envoy-internal: true
x-request-id: 5ae429e7-0e18-4bd9-bb79-4e4149cf8fef
x-forwarded-for: 10.64.0.53
x-forwarded-proto: https
content-length: 0
user-agent: Wget

次のネガティブテストコマンドを実行します。

# Negative test
# Expect this to fail because gateway expects TLS.
kubectl run -i --tty --rm debug --image=busybox --restart=Never  --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }'  -- /bin/sh -c "wget --no-check-certificate -qS -O - http://mesh-gateway:443/headers; echo"

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

wget: error getting response: Connection reset by peer

次のネガティブテストコマンドを実行します。

# Negative test.
# AuthorizationPolicy applied on the endpoints expect a GET request. Otherwise
# the request is denied authorization.
kubectl run -i --tty --rm debug --image=busybox --restart=Never  --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }'  -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway --post-data=''; echo"

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

HTTP/1.1 403 Forbidden
wget: server returned error: HTTP/1.1 403 Forbidden

Ingress ゲートウェイの承認ポリシーの設定

ここで設定した承認ポリシーでは、次の条件がすべて満たされている場合、Ingress ゲートウェイでメッシュへのリクエストが許可されます。

ホスト: mesh-gateway
ポート: 8080
パス: *
HTTP メソッド GET

ファイル authz-gateway-policy.yaml で承認ポリシーを作成します。

action: ALLOW
name: authz-gateway-policy
rules:
- destinations:
  - hosts:
    - mesh-gateway
    ports:
    - 8080
    methods:
    - GET

ファイル内の値をインポートします。

gcloud network-security authorization-policies import authz-gateway-policy \
   --source=authz-gateway-policy.yaml  --location=global

次の行を追加して、ファイル td-gke-https-proxy.yaml を編集します。

authorizationPolicy: projects/PROJECT_ID/locations/global/authorizationPolicies/authz-gateway-policy

ファイル td-gke-https-proxy.yaml をもう一度インポートします。

gcloud compute target-https-proxies import td-gke-https-proxy \
   --global --source=td-gke-https-proxy.yaml

Deployment を検証する

次のコマンドを実行して、Deployment を検証します。

# On your localhost.
kubectl run -i --tty --rm debug --image=busybox --restart=Never  --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }'  -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway; echo"

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

GET / HTTP/1.1
Host: 35.196.50.2
x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
x-envoy-expected-rq-timeout-ms: 15000
user-agent: curl/7.72.0
x-forwarded-proto: https
content-length: 0
x-envoy-internal: true
x-request-id: 98bec135-6df8-4082-8edc-b2c23609295a
accept: */*
x-forwarded-for: 10.142.0.7

次のネガティブテストコマンドを実行します。

# Negative test. Expect failure because only POST method is allowed by \
# authz-gateway-policy
kubectl run -i --tty --rm debug --image=busybox --restart=Never  --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }'  -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway/ --post-data=''; echo"

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

wget: server returned error: HTTP/1.1 403 Forbidden

Deployment を削除する

必要に応じて、これらのコマンドを実行して、このガイドに従って作成した Deployment を削除できます。

クラスタを削除するには、次のコマンドを実行します。

gcloud container clusters delete CLUSTER_NAME --zone ZONE --quiet

作成したリソースを削除するには、次のコマンドを実行します。

gcloud compute forwarding-rules delete td-gke-forwarding-rule --global --quiet
gcloud compute forwarding-rules delete td-gke-gateway-forwarding-rule --global \
    --quiet
gcloud compute target-http-proxies delete td-gke-proxy  --quiet
gcloud compute target-https-proxies delete td-gke-https-proxy  --quiet
gcloud compute url-maps delete td-gke-url-map  --quiet
gcloud compute url-maps delete td-gke-ig-url-map  --quiet
gcloud compute backend-services delete td-gke-service --global --quiet
cloud compute network-endpoint-groups delete service-test-neg --zone ZONE --quiet
gcloud compute firewall-rules delete fw-allow-health-checks --quiet
gcloud compute health-checks delete td-gke-health-check --quiet
gcloud network-services endpoint-policies delete ep \
    --location=global --quiet
gcloud network-security authorization-policies delete authz-gateway-policy \
   --location=global --quiet
gcloud network-security authorization-policies delete authz-policy \
    --location=global --quiet
gcloud network-security client-tls-policies delete client-mtls-policy \
    --location=global --quiet
gcloud network-security server-tls-policies delete server-tls-policy \
    --location=global --quiet
gcloud network-security server-tls-policies delete server-mtls-policy \
    --location=global --quiet

制限事項

Traffic Director サービスのセキュリティは GKE でのみサポートされています。Compute Engine ではサービスのセキュリティをデプロイできません。

トラブルシューティング

このセクションでは、セキュリティサービスの設定中に発生した問題を修正する方法について説明します。

接続エラー

upstream connect エラーまたは disconnect/reset before headers エラーで接続が失敗した場合は、Envoy のログを調べます。次のいずれかのログメッセージが表示される場合があります。

gRPC config stream closed: 5, Requested entity was not found

gRPC config stream closed: 2, no credential token is found

Envoy のログにこれらのエラーが記録されている場合は、サービスアカウントトークンが正しくマウントされていないか、別の audience が使用されている、またはその両方の可能性があります。

詳細については、Envoy のログのエラーメッセージが構成の問題を示しているをご覧ください。

Pod が作成されない

この問題のトラブルシューティングを行うには、GKE Pod の自動デプロイのトラブルシューティングをご覧ください。

Envoy が Traffic Director で認証されていない

Envoy（envoy-proxy）は、Traffic Director に接続して xDS 構成を取得する場合、（ブートストラップが変更されている場合を除き）Workload Identity（WI）と Compute Engine VM のデフォルトサービスアカウントを使用します。認証に失敗した場合、Envoy は準備完了状態になりません。

`--workload-identity-certificate-authority flag` を指定してクラスタを作成できない

このエラーが表示された場合は、Google Cloud CLI の最新バージョンを実行していることを確認してください。

gcloud components update

###

設定プロセス中に Pod が保留状態のままである場合は、デプロイ仕様の Pod の CPU とメモリリソースを増やします。

`--enable-mesh-certificates` フラグを指定してクラスタを作成できない

gcloud CLI の最新バージョンを実行していることを確認します。

gcloud components update

--enable-mesh-certificates フラグは gcloud beta でのみ機能します。

Pod が起動しない

証明書のプロビジョニングが失敗した場合、GKE メッシュ証明書を使用する Pod が起動しない可能性があります。これは、次のような状況で発生します。

WorkloadCertificateConfig または TrustConfig が正しく構成されていないか、存在しない。
CSR が承認されていない。

証明書のプロビジョニングが失敗するかどうかを確認するには、Pod イベントを確認します。

Pod のステータスを確認します。
```
kubectl get pod -n POD_NAMESPACE POD_NAME
```
次のように置き換えます。
- POD_NAMESPACE: Pod の名前空間。
- POD_NAME: Pod の名前。

Pod の最近のイベントを確認します。

kubectl describe pod -n POD_NAMESPACE POD_NAME

証明書のプロビジョニングに失敗した場合、Type=Warning、Reason=FailedMount、From=kubelet が含まれるイベントと、先頭が MountVolume.SetUp failed for volume "gke-workload-certificates" の Message フィールドが表示されます。Message フィールドにはトラブルシューティング情報が含まれています。

Events:
  Type     Reason       Age                From       Message
  ----     ------       ----               ----       -------
  Warning  FailedMount  13s (x7 over 46s)  kubelet    MountVolume.SetUp failed for volume "gke-workload-certificates" : rpc error: code = Internal desc = unable to mount volume: store.CreateVolume, err: unable to create volume "csi-4d540ed59ef937fbb41a9bf5380a5a534edb3eedf037fe64be36bab0abf45c9c": caPEM is nil (check active WorkloadCertificateConfig)

Pod が起動しない原因がオブジェクトの構成が適切でないか、CSR が拒否されたことである場合は、以下のトラブルシューティングの手順をご覧ください。

`WorkloadCertificateConfig` または `TrustConfig` の構成に誤りがある

WorkloadCertificateConfig オブジェクトと TrustConfig オブジェクトが正しく作成されていることを確認してください。kubectl を使用して、これらのオブジェクトの構成ミスを診断できます。

現在のステータスを取得します。

WorkloadCertificateConfig:

kubectl get WorkloadCertificateConfig default -o yaml

TrustConfig:

kubectl get TrustConfig default -o yaml

ステータスの出力を検査します。有効なオブジェクトには、type: Ready と status: "True" の条件が設定されます。
```
status:
  conditions:
  - lastTransitionTime: "2021-03-04T22:24:11Z"
    message: WorkloadCertificateConfig is ready
    observedGeneration: 1
    reason: ConfigReady
    status: "True"
    type: Ready
```
無効なオブジェクトの場合は、status: "False" が代わりに表示されます。reason フィールドと message フィールドには、追加のトラブルシューティングの詳細が含まれます。

CSR が承認されていない

CSR 承認プロセス中に問題が発生した場合は、CSR の type: Approved 条件と type: Issued 条件でエラーの詳細を確認できます。

kubectl を使用して、関連する CSR を一覧表示します。

kubectl get csr \
  --field-selector='spec.signerName=spiffe.gke.io/spiffe-leaf-signer'

Approved で Issued ではない CSR、または Approved でない CSR を選択します。
kubectl を使用して、選択した CSR の詳細を取得します。
```
kubectl get csr CSR_NAME -o yaml
```
CSR_NAME を、選択した CSR の名前に置き換えます。

有効な CSR には、type: Approved と status: "True" の条件と、status.certificate フィールドに有効な証明書があります。

status:
  certificate: <base64-encoded data>
  conditions:
  - lastTransitionTime: "2021-03-04T21:58:46Z"
    lastUpdateTime: "2021-03-04T21:58:46Z"
    message: Approved CSR because it is a valid SPIFFE SVID for the correct identity.
    reason: AutoApproved
    status: "True"
    type: Approved

無効な CSR のトラブルシューティング情報が message フィールドと reason フィールドに表示されます。

アプリケーションで発行済みの mTLS 認証情報を使用できない

証明書の有効期限が切れていないことを確認します。

cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"

使用しているキータイプがアプリケーションでサポートされていることを確認します。

cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Public Key Algorithm" -A 3

発行 CA が証明書鍵と同じ鍵ファミリーを使用していることを確認します。
1. CA Service（プレビュー）インスタンスのステータスを取得します。
```
gcloud privateca ISSUING_CA_TYPE describe ISSUING_CA_NAME \
  --location ISSUING_CA_LOCATION
```
  次のように置き換えます。
  - ISSUING_CA_TYPE: 発行 CA のタイプ（subordinates または roots のいずれか）。
  - ISSUING_CA_NAME: 発行 CA の名前。
  - ISSUING_CA_LOCATION: 発行 CA のリージョン。
2. 出力の keySpec.algorithm が WorkloadCertificateConfig YAML マニフェストで定義したのと同じ鍵アルゴリズムであることを確認します。出力は次のようになります。
```
config:
  ...
  subjectConfig:
    commonName: td-sub-ca
    subject:
      organization: TestOrgLLC
    subjectAltName: {}
createTime: '2021-05-04T05:37:58.329293525Z'
issuingOptions:
  includeCaCertUrl: true
keySpec:
  algorithm: RSA_PKCS1_2048_SHA256
 ...
```

証明書が拒否される

ピアアプリケーションが同じ信頼バンドルを使用して証明書を検証することを確認します。

証明書の有効期限が切れていないことを確認します。

cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"

gRPC Go Credentials Reloading API を使用していない場合、クライアントコードがファイルシステムから認証情報を定期的に更新することを確認します。
ワークロードが CA と同じ信頼ドメインに存在することを確認します。GKE メッシュ証明書は、単一の信頼ドメインにあるワークロード間の通信をサポートします。

Envoy とロード バランシング API を使用してサービスのセキュリティを設定する

要件

設定を準備する

gcloud コマンドライン ツールを更新する

環境変数を設定する

API を有効にする

GKE クラスタを作成または更新する

マルチクラスタ環境でのデプロイ

フリートにクラスタを登録する

証明書を発行する認証局を作成する

Identity and Access Management を構成する

Traffic Director を設定する

クラスタに Envoy サイドカー インジェクタをインストールする

テストサービスを設定する

Traffic Director のプロキシ メタデータ

CA Service によって署名されたメッシュ証明書と鍵を使用する

受信トラフィック インターセプト ポートの構成

NEG を使用して GKE サービスを構成する

NEG の名前を保存する

クライアント アプリケーションを GKE にデプロイする

Traffic Director の Google Cloud リソースを構成する

サービス間のセキュリティを設定する

メッシュで mTLS を有効にする

ポリシー参照の形式

バックエンド サービスへの送信トラフィックを保護する

エンドポイントへの受信トラフィックを保護する

設定を検証する

認可ポリシーでサービスレベルのアクセスを構成する

設定を検証する

Ingress ゲートウェイ セキュリティを設定する

Ingress ゲートウェイ サービスを GKE にデプロイする

Traffic Director サイドカー インジェクションの無効化

正しいボリュームをマウントする

クラスタの内部 IP アドレスを設定する

Ingress ゲートウェイで TLS を有効にする

Ingress ゲートウェイの Deployment を検証する

Ingress ゲートウェイの承認ポリシーの設定

Deployment を検証する

Deployment を削除する

制限事項

トラブルシューティング

接続エラー

Pod が作成されない

Envoy が Traffic Director で認証されていない

--workload-identity-certificate-authority flag を指定してクラスタを作成できない

--enable-mesh-certificates フラグを指定してクラスタを作成できない

Pod が起動しない

WorkloadCertificateConfig または TrustConfig の構成に誤りがある

CSR が承認されていない

アプリケーションで発行済みの mTLS 認証情報を使用できない

証明書が拒否される

Envoy とロードバランシング API を使用してサービスのセキュリティを設定する

`gcloud` コマンドラインツールを更新する

クラスタに Envoy サイドカーインジェクタをインストールする

Traffic Director のプロキシメタデータ

受信トラフィックインターセプトポートの構成

クライアントアプリケーションを GKE にデプロイする

バックエンドサービスへの送信トラフィックを保護する

Ingress ゲートウェイセキュリティを設定する

Ingress ゲートウェイサービスを GKE にデプロイする

Traffic Director サイドカーインジェクションの無効化

`--workload-identity-certificate-authority flag` を指定してクラスタを作成できない

`--enable-mesh-certificates` フラグを指定してクラスタを作成できない

`WorkloadCertificateConfig` または `TrustConfig` の構成に誤りがある