マネージド 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 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 サービスの使用に必要なロール

このインテグレーションでは、Cloud Service Mesh のワークロードすべてに次の IAM ロールが必要です。

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

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

    gcloud privateca pools add-iam-policy-binding CA_POOL \
      --project 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/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/PROJECT_ID/locations/ca_region/caPools/CA_POOL:projects/PROJECT_ID/locations/ca_region/certificateTemplates/CERT_TEMPLATE_ID"}}'

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