mTLS を使用してワークロード間で認証を行う

このドキュメントでは、Compute Engine のマネージド ワークロード ID の自動プロビジョニングとライフサイクル管理を設定する方法について説明します。Certificate Authority Service（CA）を使用して証明書を発行するように CA プールを構成します。これは可用性の高いスケーラブルな Google Cloud サービスで、これにより CA サービスのデプロイ、管理、セキュリティが自動化され、簡素化されます。各 VM には、構成された CA プールから X.509 認証情報がプロビジョニングされます。その後、これらの認証情報を使用して mTLS 接続を確立できます。

Compute Engine のマネージド ワークロード ID を使用すると、任意の 2 つの Compute Engine VM 間で相互認証を行い、暗号化された通信を確立できます。構成された VM で実行されているワークロード アプリケーションは、VM ごとの mTLS に X.509 認証情報を使用できます。これらの mTLS 証明書は、Certificate Authority Service によって自動的にローテーションされ、管理されます。

始める前に

  • マネージド ワークロード ID（プレビュー版）へのアクセスをリクエストします。

  • Google Cloud CLI を構成します。

    Install the Google Cloud CLI, then initialize it by running the following command: 

    gcloud init

  • 許可リストに登録されたプロジェクトを課金と割り当てに使用するように、Google Cloud CLI を構成します。

      gcloud config set billing/quota_project PROJECT_ID

    PROJECT_ID は、マネージド ワークロード ID（プレビュー版）の許可リストに追加されたプロジェクトの ID に置き換えます。

  • マネージド ワークロード ID の概要のドキュメントをご覧ください。

  • Enable the Compute Engine API: 

    gcloud services enable compute.googleapis.com

必要なロール

他のワークロードの認証にマネージド ワークロード証明書を使用する VM を作成するために必要な権限を取得するには、プロジェクトに対する次の IAM ロールを付与するよう管理者に依頼してください。

ロールの付与の詳細については、アクセスの管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

概要

アプリケーションでマネージド ワークロード ID を使用するには、次の操作を行う必要があります。

  1. セキュリティ管理者:

  2. Compute 管理者:

Identity and Access Management でマネージド ワークロード ID を構成する

  • マネージド ワークロード ID 認証を構成するの手順を実施します。

    ここでは、次の方法について説明します。

    • ワークロード ID プールを作成する
    • ワークロード ID プールに名前空間を作成します。名前空間を使用して、マネージド ワークロード ID の管理境界を作成します。たとえば、組織が所有するアプリケーションごとに名前空間を作成します。
    • ワークロード ID プールの名前空間にマネージド ワークロード ID を作成します。たとえば、アプリケーションに名前空間を作成し、その名前空間内にアプリケーションをサポートするマイクロサービスのマネージド ID を作成できます。
    • サービス アカウントを作成します。Compute Engine VM は、VM に接続されている Google Cloud サービス アカウントに基づいて、マネージド ワークロード ID の受信が許可されます。
    • ワークロードにマネージド ワークロード ID の認証情報を発行できるようにするワークロード証明書ポリシーを作成します。マネージド ワークロード ID の認証情報を発行するには、ワークロードが指定されたプロジェクト内に存在し、サービス アカウントが接続されている必要があります。
    • マネージド ワークロード ID の証明書を発行するように Certificate Authority Service を構成します。
      • ルート CA プールを構成する
      • 下位 CA を構成する
      • CA プールの証明書のリクエストをマネージド ワークロード ID に許可する

パートナー メタデータをアップロードする構成ファイルを取得する

セキュリティ管理者が、次の内容を含む JSON ファイルを作成します。

このファイルの名前は CONFIGS.json です。このファイルは、MIG のインスタンス テンプレートを作成するとき、または個々の VM を作成するときに使用します。

CONFIGS.json ファイルは以下のようになります。

  {
  "wc.compute.googleapis.com": {
     "entries": {
        "certificate-issuance-config": {
           "primary_certificate_authority_config": {
              "certificate_authority_config": {
                 "ca_pool": "projects/PROJECT_ID/locations/SUBORDINATE_CA_POOL_REGION/caPools/SUBORDINATE_CA_POOL_ID"
              }
           },
           "key_algorithm": "rsa-2048"
        },
        "trust-config": {
           "POOL_ID.global.PROJECT_NUMBER.workload.id.goog": {
               "trust_anchors": [{
                  "ca_pool": "projects/PROJECT_ID/locations/SUBORDINATE_CA_POOL_REGION/caPools/SUBORDINATE_CA_POOL_ID"
                }]
           }
     }
  }
  },
  "iam.googleapis.com": {
     "entries": {
        "workload-identity": "spiffe://POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID"
     }
  }
  }

マネージド インスタンス グループ（MIG）でマネージド ワークロード ID を有効にする

マネージド インスタンス グループ（MIG）は、単一のエンティティとして扱う仮想マシン（VM）インスタンスのグループです。MIG 内の各 VM は、インスタンス テンプレートを使用して作成されます。MIG 内の VM がマネージド ワークロード ID を使用できるようにするには、インスタンス テンプレートで構成を指定します。

インスタンス テンプレートを作成する

マネージド ワークロード ID 機能を有効にしてインスタンス テンプレートを作成します。次に、このテンプレートを使用してマネージド インスタンス グループ（MIG）を作成します。

gcloud

gcloud beta compute instance-templates create コマンドを使用して、マネージド ワークロード ID を有効にする新しいインスタンス テンプレートを作成します。

gcloud beta compute instance-templates create INSTANCE_TEMPLATE_NAME \
    --service-account SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --metadata enable-workload-certificate=true \
    --partner-metadata-from-file CONFIGS.json

インスタンス テンプレートの作成時に別のフラグを追加して、作成する VM をカスタマイズできます。たとえば、デフォルト値を使用する代わりに、マシンタイプやイメージを指定できます。

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

  • INSTANCE_TEMPLATE_NAME: 新しいテンプレートの名前。
  • SERVICE_ACCOUNT_NAME: マネージド ID の受信が許可されているサービス アカウントの名前。
  • PROJECT_ID: サービス アカウントが作成されたプロジェクトの ID。
  • CONFIGS.json: 証明書発行構成、信頼構成、マネージド ワークロード ID を含む構成ファイル。

詳細については、インスタンス テンプレートを作成するをご覧ください。

テンプレートからマネージド インスタンス グループを作成する

マネージド ワークロード ID を有効にするインスタンス テンプレートを使用するマネージド インスタンス グループを作成します。インスタンス テンプレートの作成方法については、インスタンス テンプレートを作成するをご覧ください。

gcloud

インスタンス テンプレートと gcloud compute instance-groups managed create コマンドを使用して MIG を作成します。

gcloud compute instance-groups managed create INSTANCE_GROUP_NAME \
    --size=SIZE \
    --template=INSTANCE_TEMPLATE_NAME \
    --zone=ZONE

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

  • INSTANCE_GROUP_NAME: マネージド インスタンス グループの一意の ID。有効な名前の詳細については、リソース名の指定をご覧ください。
  • SIZE: マネージド インスタンス グループのサイズ
  • INSTANCE_TEMPLATE_NAME: MIG で VM を作成するときに使用するインスタンス テンプレートの名前
  • ZONE: VM を作成するゾーン

MIG の作成の詳細については、マネージド インスタンス グループ（MIG）を作成するための基本的なシナリオをご覧ください。

個々の VM でマネージド ワークロード ID を有効にする

VM のマネージド ワークロード ID は、VM の作成時に有効にできます。また、既存の VM のパートナー メタデータを更新して有効にすることもできます。

マネージド ワークロード ID を有効にして VM を作成する

VM の作成時にマネージド ワークロード ID 機能を有効にするには、次のことを行う必要があります。

  • VM が使用するサービス アカウントを指定する
  • enable-workload-certificate メタデータ属性を true に設定する

  • 証明書発行構成と信頼構成情報をパートナー メタデータとして指定する

gcloud

gcloud beta compute instances create コマンドを使用して、新しい VM を作成します。セキュリティ管理者から提供されたか、構成ファイルを作成して VM のパートナー メタデータをアップロードするの説明に従って作成された CONFIGS.json ファイルを使用します。

  1. マネージド ワークロード ID 機能を有効にして VM を作成します。

    gcloud beta compute instances create INSTANCE_NAME \
   --zone=INSTANCE_ZONE \
   --service-account SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com \
   --metadata enable-workload-certificate=true \
   --partner-metadata-from-file CONFIGS.json

    デフォルト値を使用する代わりに、マシンタイプやイメージなどの行をコマンドに追加して VM を構成できます。詳しくは、VM インスタンスの作成と開始をご覧ください。

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

    • INSTANCE_NAME: VM の一意の名前。有効なインスタンス名の詳細については、リソース名の指定をご覧ください。
    • INSTANCE_ZONE: VM を作成するゾーン。
    • SERVICE_ACCOUNT_NAME: マネージド ID の受信が許可されているサービス アカウントの名前。
    • PROJECT_ID: サービス アカウントが作成されたプロジェクトの ID。
    • CONFIGS.json: 証明書発行構成、信頼構成、マネージド ワークロード ID 構成を含む構成ファイルの名前。

既存の VM でマネージド ワークロード ID を有効にする

既存の VM でマネージド ワークロード ID を有効にするには、VM を更新して以下の構成を行います。

  • VM にサービス アカウントがまだ接続されていない場合は、サービス アカウントを作成して VM に接続します。
  • enable-workload-certificate メタデータ属性を true に設定します。
  • 証明書発行構成と信頼構成情報をパートナー メタデータとして指定する

  • VM を再起動します。

gcloud

このタスクでは、セキュリティ管理者から提供されたか、構成ファイルを作成して VM のパートナー メタデータをアップロードするの説明に従って作成された CONFIGS.json ファイルを使用します。

  1. VM にサービス アカウントがまだ接続されていない場合は、サービス アカウントを VM に接続します。

  2. 既存の VM のメタデータを更新して、マネージド ワークロード ID を有効にします。

    gcloud beta compute instances add-metadata VM_NAME \
   --zone=ZONE \
   --metadata enable-workload-certificate=true

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

    • VM_NAME: VM の名前
    • ZONE: VM を配置するゾーン

  3. 既存の VM の構成を更新して、構成ファイルを追加します。

    gcloud beta compute instances update VM_NAME \
   --zone=ZONE \
   --partner-metadata-from-file CONFIGS.json

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

    • VM_NAME: VM の名前
    • ZONE: VM を配置するゾーン
    • CONFIGS.json: 証明書発行構成、信頼構成、マネージド ワークロード ID を含む構成ファイル。

  4. VM を停止します。

    gcloud beta compute instances stop VM_NAME \
   --zone=ZONE

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

    • VM_NAME: VM の名前
    • ZONE: VM が配置されているゾーン。

  5. VM を起動します。

    gcloud beta compute instances start VM_NAME \
   --zone=ZONE

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

    • VM_NAME: VM の名前
    • ZONE: VM が配置されているゾーン。

Linux VM でワークロード認証情報にアクセスする

mTLS を使用してワークロード認証を正常に構成すると、VM で発行された認証情報にアクセスできます。

Compute Engine のマネージド ワークロード ID の認証情報とそれに関連する信頼バンドルにアクセスする方法は 2 つあります。

  • VM 上のファイル システム
  • Compute Engine メタデータ サーバー

VM 上のファイル システムを使用してワークロードの認証情報と信頼バンドルにアクセスする

この方法では、X.509 認証情報と信頼バンドルが VM のファイル システム内の特定のパスに配置されます。アプリケーションは、ファイル システムから認証情報と信頼バンドルを直接読み取ることができます。認証情報を取得する方法の例については、GitHub で次の例をご覧ください。

VM では、Compute Engine ゲスト エージェント バージョン 20231103.01 以降を実行する必要があります。次のコマンドを使用して、VM 上の Compute Engine ゲスト エージェントのバージョンを確認します。

gcloud beta compute instances get-serial-port-output INSTANCE_NAME \
   --zone=ZONE | grep "GCE Agent Started"

ゲスト エージェントのバージョンが 20231103.01 より前の場合は、ゲスト環境の更新の手順に沿ってバージョンを更新します。

ワークロード認証情報と信頼バンドルを VM のファイル システムで使用できるようにするには、次の手順を完了します。

  1. Compute Engine ゲスト エージェントをインストールするか、バージョン 20231103.01 以降に更新します。ゲスト エージェントは次の処理を行います。

    • Compute Engine メタデータ サーバーから認証情報と信頼バンドルを自動的に取得します。
    • X.509 証明書とそれに対応する秘密鍵の更新中に、ファイル システムへのアトミック書き込みが行われるようにします。
    • 認証情報と信頼バンドルを自動的に更新します（mTLS 証明書がローテーションされた場合など）。

  2. ゲスト OS に Compute Engine ゲスト エージェントをインストールまたは更新した後、ワークロード更新ジョブはディレクトリ /var/run/secrets/workload-spiffe-credentials を作成し、ディレクトリ権限を 0755 (rwxr-xr-x) に設定します。

    このディレクトリには、0644 (rw-r--r--) 権限で作成された次のファイルが含まれています。

    • private_key.pem: PEM 形式の秘密鍵
    • certificates.pem: PEM 形式の X.509 証明書のバンドル。これは、クライアント証明書チェーンとして他の VM に提示することも、サーバー証明書チェーンとして使用することもできます。

    • ca_certificates.pem: ピアの証明書を検証するときにトラスト アンカーとして使用する PEM 形式の X.509 証明書のバンドル。

      spiffe://POOL_ID.global.PROJECT_NUMBER.workload.id.goog

    • config_status: エラー メッセージを含むログファイル。

  3. アプリケーションは、ファイル システムから証明書、秘密鍵、信頼バンドルを直接読み取り、mTLS 接続を確立できます。

メタデータ サーバーを使用してワークロード認証情報と信頼バンドルにアクセスする

Compute Engine VM で実行されるアプリケーションは、直接メタデータ サーバー エンドポイントをクエリし、認証情報と信頼バンドルを取得できます。アプリケーションは、メタデータ サーバー エンドポイントを定期的にチェックし、新しい認証情報と信頼バンドルの更新を確認します。

Compute Engine メタデータ サーバーは 3 つの HTTP エンドポイントを公開し、VM 内で実行されているアプリケーションがマネージド ワークロード ID 機能を使用できるようにします。

  • gce-workload-certificates/config-status: VM メタデータを介して指定された構成値にエラーがあるエンドポイント。
  • gce-workload-certificates/workload-identities: Compute Engine コントロール プレーンによって管理される ID のエンドポイント。このエンドポイントには、X.509 証明書と VM の信頼ドメインの秘密鍵が含まれています。
  • gce-workload-certificates/trust-anchors: ピア X.509 証明書チェーン検証に使用する信頼された証明書のセットを含むエンドポイント。

VM インスタンスのメタデータのクエリの詳細については、VM メタデータについてをご覧ください。

メタデータ サーバーを使用してワークロード認証情報と信頼バンドルにアクセスするには、アプリケーションで次のことを行う必要があります。

  1. gce-workload-certificates/config-status エンドポイントにクエリを実行します。HTTP レスポンス コードが 200 であり、レスポンスに partnerMetadataConfigsErrors エラーが含まれていないことを確認します。このようなエラーが存在する場合は、証明書発行と信頼構成を更新するの手順に沿って、該当する構成を有効な値で更新します。

    値を確認するには、VM で次のコマンドを実行します。

    curl "http://metadata.google.internal/computeMetadata/v1/instance/gce-workload-certificates/config-status" -H "Metadata-Flavor: Google"

    config-status エンドポイントは、次の構造の JSON レスポンスを返します。

    {
    "partnerMetadataConfigsErrors": {
        "errors": {  // A map of errors keyed by attribute name.
            "ATTRIBUTE_NAME" : "ERROR_DETAILS",
            ...
        }
    }
}

  2. gce-workload-certificates/workload-identities エンドポイントにクエリを実行します。HTTP レスポンス コードが 200 であることを確認します。このエンドポイントは、次の構造の JSON レスポンスを返します。

    {
 "workloadCredentials": {  // Credentials for the VM's trust domains
   "spiffe://POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID": {
      "certificatePem" : "X.509 certificate or certificate chain",
      "privateKeyPem" : "Private for X.509 leaf certificate"
   }
 }
}

    certificatePem と privateKeyPem を抽出します。マネージド ワークロード ID が Compute Engine インフラストラクチャによって更新された場合は、秘密鍵と公開鍵の不一致を避けるため、両方の値を同じレスポンスから読み取ることが重要です。

  3. gce-workload-certificates/trust-anchors エンドポイントにクエリを実行します。HTTP レスポンス コードが 200 であることを確認します。指定されている場合、レスポンスには SPIFFE 信頼ドメインのトラスト アンカーのみが含まれます。それ以外の場合、クエリはエラーを返します。trust-anchors エンドポイントは、次の構造の JSON レスポンスを返します。

    {
    "trustAnchors": {  // Trust bundle for the VM's trust domains
        "POOL_ID.global.PROJECT_NUMBER.workload.id.goog": {
            "trustAnchorsPem" : "Trust bundle containing the X.509
            roots certificates"
        }
    }
}

    trustAnchorsPem の内容には、mTLS 接続を確立するときにピア X.509 認証情報の認証に使用できる信頼バンドルが含まれています。

認証情報と信頼バンドルの更新

Compute Engine コントロール プレーンは、マネージド ワークロード ID の認証情報とトラスト アンカーを定期的にローテーションします。

アプリケーションがファイル システムを使用してワークロード認証情報と信頼バンドルにアクセスする場合、Compute Engine ゲスト エージェントは認証情報と信頼バンドルを自動的に更新します（たとえば、mTLS 証明書がローテーションされた場合など）。

アプリケーションがメタデータ サーバーにクエリを送信する場合、VM で実行されているアプリケーションはメタデータ サーバー エンドポイントに定期的にクエリを実行し、マネージド ワークロード ID 認証情報と信頼バンドルの最新のセットを取得する必要があります。そうしないと、証明書の有効期限や信頼バンドルの変更によってアプリケーションの処理が中断し、mTLS 接続を確立できない可能性があります。アプリケーションでは、5 分ごとにメタデータ サーバーにマネージド ワークロード ID の認証情報と信頼バンドルをクエリすることをおすすめします。

証明書発行と信頼構成を更新する

マネージド ワークロード ID を使用する VM の証明書発行と信頼の構成を変更できます。

マネージド インスタンス グループのインスタンス テンプレートを更新する

インスタンス テンプレートの証明書発行と信頼の構成値を更新するには、新しい値で新しいテンプレートを作成する必要があります。そのため、既存のマネージド インスタンス グループ（MIG）の証明書発行と信頼の構成の更新はサポートされていません。

個々の Compute Engine VM を更新する

証明書発行と信頼の構成を更新するには、CONFIGS.json ファイルの内容を更新し、gcloud beta compute instances update コマンドを使用して更新を適用します。

gcloud beta compute instances update INSTANCE_NAME \
    --partner-metadata-from-file FILENAME.json

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

  • INSTANCE_NAME: 構成値を更新する VM の名前
  • FILENAME: 変更された構成ファイルの名前（例: CONFIGS.json）

トラブルシューティング

ワークロード認証情報の取得に関連する一般的なエラーを診断して解決する方法については、ワークロードに対する認証のトラブルシューティングのドキュメントをご覧ください。

次のステップ