マネージド 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 を構成する

  1. CA プールを階層 DevOps 内と、クラスタと同じリージョン内に作成します。これにより、過大なレイテンシの問題や、リージョン間にわたるサービス停止の可能性を回避できます。詳細については、ワークロードに最適化された階層をご覧ください。
  2. CA を作成し、GKE クラスタと同じプロジェクトの CA プールに 1 つ以上の有効な認証局を設定します。下位 CA を使用して Cloud Service Mesh のワークロード証明書に署名します。下位 CA に対応する CA プールをメモします。

  3. 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/") )

  4. CA プールの発行ポリシーを更新するには、次のコマンドを使用します。

    gcloud privateca pools update CA_POOL --location ca_region --issuance-policy policy.yaml

    プールにポリシーを設定する方法については、証明書発行ポリシーの使用をご覧ください。

  5. 証明書テンプレートを使用している場合は、ここで構成します。詳細については、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 を構成する

  1. istio-system 名前空間が存在することを確認します。存在しない場合は作成します。

      kubectl create ns istio-system

  2. asm-options configmap が istio-system 名前空間に存在するかどうかを確認します。

      kubectl get configmap/asm-options -n istio-system

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

      kubectl create configmap -n istio-system asm-options

  4. 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 のインストールを続行します。