マネージド Cloud Service Mesh の Certificate Authority Service を構成する

このガイドでは、マネージド Cloud Service Mesh の Certificate Authority Service を構成する方法について説明します。クラスタ内の Cloud Service Mesh については、デフォルトの機能とCertificate Authority (CA) Service　をインストールするをご覧ください。

Cloud Service Mesh certificate authorityに加えて、Certificate Authority Service を使用するように Cloud Service Mesh を構成できます。このガイドでは、CA Service とのインテグレーションについて説明します。このインテグレーションは、次のようなユースケースでおすすめします。

異なるクラスタ上のワークロード証明書への署名に別の認証局が必要な場合。
マネージド HSM に署名鍵を元に戻す必要がある場合。
規制の厳しい業界で、コンプライアンスの対象となっている場合。
Cloud Service Mesh CA をカスタムエンタープライズルート証明書のチェーンに追加して、ワークロード証明書に署名する場合。

Cloud Service Mesh certificate authorityの費用は Cloud Service Mesh の料金に含まれています。CA Service は Cloud Service Mesh の基本料金に含まれず、別途課金されます。また、CA Service には明示的な SLA が提供されますが、Cloud Service Mesh 認証局には提供されません。

要件

CA プールを構成するプロジェクトで、必要な API を有効にします。

 gcloud services enable privateca.googleapis.com \
      --project=CA_PROJECT_ID

CA Service を構成する

CA プールを階層 DevOps 内と、クラスタと同じリージョン内に作成します。これにより、過大なレイテンシの問題や、リージョン間にわたるサービス停止の可能性を回避できます。詳細については、ワークロードに最適化された階層をご覧ください。
CA を作成し、GKE クラスタと同じプロジェクトの CA プールに 1 つ以上の有効な認証局を設定します。下位 CA を使用して Cloud Service Mesh のワークロード証明書に署名します。下位 CA に対応する CA プールをメモします。
Cloud Service Mesh ワークロードのサービス証明書のみを目的とする場合は、CA プールに次の発行ポリシーを設定します。
policy.yaml
```
baselineValues:
  keyUsage:
    baseKeyUsage:
      digitalSignature: true
      keyEncipherment: true
    extendedKeyUsage:
      serverAuth: true
      clientAuth: true
  caOptions:
    isCa: false
identityConstraints:
  allowSubjectPassthrough: false
  allowSubjectAltNamesPassthrough: true
  celExpression:
    expression: subject_alt_names.all(san, san.type == URI && san.value.startsWith("spiffe://PROJECT_ID.svc.id.goog/ns/") )
```
注: マルチクラスタメッシュの場合は、一意のクラスタリージョンごとに 1 つの下位 CA プールを設定することをおすすめします。下位 CA プールはすべて、同じルート CA プールのチェーンに追加する必要があります。
CA プールの発行ポリシーを更新するには、次のコマンドを使用します。
```
gcloud privateca pools update CA_POOL --location ca_region --issuance-policy policy.yaml
```
プールにポリシーを設定する方法については、証明書発行ポリシーの使用をご覧ください。
証明書テンプレートを使用している場合は、ここで構成します。詳細については、CA Service ガイドの Workload Identity 証明書についての説明をご覧ください。証明書テンプレートが CA プールと同じリージョンに作成されていることを確認します。CA プールのリージョンが複数ある場合は、リージョンごとに証明書テンプレートを作成します。

CA Service の使用に必要なロール

この統合では、Cloud Service Mesh のすべてのワークロードに次の IAM ロールが必要です。これらのロールバインディングは、Cloud Service Mesh ワークロードに明示的に適用する必要があります。

    WORKLOAD_IDENTITY="FLEET_PROJECT_ID.svc.id.goog:/allAuthenticatedUsers/"

    gcloud privateca pools add-iam-policy-binding CA_POOL \
      --project FLEET_PROJECT_ID \
      --location ca_region \
      --member "group:${WORKLOAD_IDENTITY}" \
      --role "roles/privateca.workloadCertificateRequester"

    gcloud privateca pools add-iam-policy-binding CA_POOL \
      --project FLEET_PROJECT_ID \
      --location ca_region \
      --member "group:${WORKLOAD_IDENTITY}" \
      --role "roles/privateca.auditor"

証明書テンプレートを使用している場合:

    gcloud privateca templates add-iam-policy-binding CERT_TEMPLATE_ID \
        --member "group:${WORKLOAD_IDENTITY}" \
        --role "roles/privateca.templateUser"

制限事項

Cloud Service Mesh コントロールプレーンをプロビジョニングする前に、CA を構成して選択します。CA の変更はサポートされていません。

CA Service を使用するようにマネージド Cloud Service Mesh を構成する

istio-system 名前空間が存在することを確認します。存在しない場合は作成します。
```
  kubectl create ns istio-system
```
asm-options configmap が istio-system 名前空間に存在するかどうかを確認します。
```
  kubectl get configmap/asm-options -n istio-system
```

configmap が存在しない場合は作成します。

  kubectl create configmap -n istio-system asm-options

configmap にパッチを適用して CAS 構成を追加します。

  kubectl patch configmap/asm-options -n istio-system --type merge \
  -p '{"data":{"ASM_OPTS": "CA=PRIVATECA;CAAddr=projects/CA_PROJECT_ID/locations/ca_region/caPools/CA_POOL"}}'

証明書テンプレートが必要な場合は、: を区切りとしてテンプレート ID を CA プールアドレスに追加します。

  kubectl patch configmap/asm-options -n istio-system --type merge \
  -p '{"data":{"ASM_OPTS": "CA=PRIVATECA;CAAddr=projects/CA_PROJECT_ID/locations/ca_region/caPools/CA_POOL:projects/PROJECT_ID/locations/ca_region/certificateTemplates/CERT_TEMPLATE_ID"}}'

構成手順が完了したら、自動管理を有効にして、マネージド Cloud Service Mesh のインストールを続行します。