Autopilot モードで特権ワークロードの承認を制御する

Autopilot

Google Kubernetes Engine（GKE）Autopilot モードで特権ワークロードを実行するには、クラスタにこれらのワークロードの許可リストをインストールします。このドキュメントでは、次のタスクを行う方法について説明します。

• 特定の特権ワークロードのみを Autopilot モードで実行するように GKE を構成します。
• 特権ワークロードの許可リストをインストールします。

このドキュメントは、次のような役割の方を対象としています。

• サードパーティ ワークロードがクラスタで実行され、GKE 承認済みのソースから取得されるように、許可リストが必要であることを確認するセキュリティ エンジニア。
• クラスタでサードパーティのワークロードを有効にして、アプリケーション チームのブロックを解除したいプラットフォーム エンジニア。

次のコンセプトに精通している必要があります。

• Autopilot モードでの特権ワークロードの承認について
• Kubernetes カスタム リソース
• GKE Autopilot のセキュリティ制約
• GKE Autopilot のパートナー

Autopilot の特権ワークロードについて

Autopilot モードでは、セキュリティ ポスチャーを改善するために、ワークロードにデフォルトの制約セットが適用されます。これらの制約を変更して、特定の特権ワークロードを実行するには、それらのワークロードに対応する許可リストをインストールします。デフォルトでは、Autopilot パートナーと特定のオープンソース プロジェクトの許可リストをインストールできます。対象となる GKE のお客様は、Cloud Storage バケットにアップロードするお客様所有の特権ワークロードの許可リストを作成することもできます。

許可リストはそれぞれ、特定の特権ワークロードに一致するファイルです。特権ワークロードを実行する手順は次のとおりです。

1. 特定のパスからの許可リストのインストールを許可するようにクラスタを構成します。デフォルトでは、Autopilot パートナーと承認済みのオープンソース プロジェクトのすべての許可リストがサポートされています。
2. 許可リストをインストールして最新の状態に保つ AllowlistSynchronizer をクラスタに作成します。

特権ワークロードと許可リストに関するバグと機能リクエスト

特権ワークロードの所有者は、ワークロードと許可リストの作成、開発、維持を行う責任があります。バグが発生した場合や、特権ワークロードまたは許可リストに関する機能リクエストがある場合は、該当するオーナーにお問い合わせください。

始める前に

作業を始める前に、次のタスクが完了していることを確認してください。

• Google Kubernetes Engine API を有効にする。
Google Kubernetes Engine API を有効化
• このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。gcloud CLI をインストール済みの場合は、gcloud components update コマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。
  注: gcloud CLI がすでにインストールされている場合には、必ず compute/region プロパティを設定してください。主にゾーンクラスタを使用する場合は、代わりに compute/zone を設定します。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。クラスタのロケーションが設定したデフォルトと異なる場合は、特定のコマンドでロケーションの指定が必要になることがあります。

• 選択したソースから許可リストをインストールするようにクラスタを構成できることを確認します。組織の管理者は、組織のポリシーを使用して、クラスタに追加できるパスを制御できます。詳細については、許可リストの組織ポリシー サービス マネージド制約をご覧ください。

• 対象となる GKE ユーザーが利用できるお客様所有の特権ワークロードの場合は、次の両方の条件を確認します。

  • 組織の管理者が、許可リストのバケットパスを組織のポリシーに追加しました。詳細については、組織で特権 GKE ワークロードを制限するをご覧ください。
  • インストールする許可リストが Cloud Storage バケットにある。詳細については、特権 Autopilot ワークロードの許可リストを作成するをご覧ください。

要件

• AllowlistSynchronizer カスタム リソースには、GKE バージョン 1.32.2-gke.1652000 以降が必要です。
• クラスタで実行する特権ワークロードを把握しておく必要があります。
• クラスタの許可リスト パス構成を変更するには、クラスタで GKE バージョン 1.35 以降を実行している必要があります。

クラスタの許可リストのパスを構成する

このセクションでは、承認済みのパスのセットから許可リストのインストールをサポートするようにクラスタを構成する方法について説明します。デフォルトでは、Autopilot は GKE パートナーと承認済みのオープンソース プロジェクトからの許可リストのインストールをサポートしています。このデフォルト構成は、個々のクラスタで変更できます。組織のポリシーを使用することで、組織、フォルダ、プロジェクト全体の承認済み許可リスト ソースを指定することもできます。

1. クラスタに追加する許可リスト ファイルのパスを特定します。クラスタの作成時または更新時に、複数のパスを指定できます。パスの代わりに空の文字列を指定して、任意のソースからの許可リストのインストールを無効にすることもできます。指定できるパスの詳細については、許可リストのパスをご覧ください。

2. クラスタの承認済み許可リスト ソースを制御するには、次のコマンドのように、Autopilot クラスタまたは Standard クラスタを作成または更新するときに --autopilot-privileged-admission フラグを使用します。

   gcloud container clusters create-auto CLUSTER_NAME \
       --location=LOCATION \
       --autopilot-privileged-admission=ALLOWLIST1_PATH,ALLOWLIST2_PATH,...
   

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

   • CLUSTER_NAME: 新しいクラスタの名前。
   • LOCATION: クラスタ コントロール プレーンのロケーション（us-central1 など）。

   • ALLOWLIST1_PATH,ALLOWLIST2_PATH,...: 許可リスト ファイルまたはディレクトリのパスのカンマ区切りのリスト。例: gke://*,gs://my-agent/privileged-logging-agent.yaml空の文字列（""）を指定して、任意のソースからの許可リストのインストールを無効にすることもできます。

     注意: gke://* パスでは、すべての GKE 承認済みソースからの WorkloadAllowlists が許可されます。これは、デフォルトの Autopilot の動作です。--autopilot-privileged-admission フラグを使用するときにこの値を省略すると、クラスタは GKE 承認済みの許可リストを実行できません。

--autopilot-privileged-admission フラグを指定せずに既存のクラスタを更新すると、そのクラスタの既存のパス構成は変更されません。クラスタを更新するたびにこのフラグを指定する必要はありません。

クラスタの作成または更新オペレーションが完了したら、AllowlistSynchronizer を作成して、指定されたパスから許可リストをインストールできます。

注: Autopilot で独自の特権ワークロードを実行できるのは、対象となる Google Cloud お客様のみです。コマンドが Cluster is not authorized to use custom allowlist paths のようなメッセージで失敗した場合は、まだアクセス権がありません。詳細については、特権 Autopilot ワークロードのソースをご覧ください。

新しい AllowlistSynchronizer を作成する

特権ワークロードを実行するには、対応する許可リストファイルのパスを YAML ファイルの AllowlistSynchronizer 仕様に追加します。次に、AllowlistSynchronizer をクラスタにデプロイします。

ベスト プラクティス: 対応するワークロードがサポートする特定のアプリケーションやチームに個別の AllowlistSynchronizer を作成します。

1. テキスト エディタで、新しい YAML ファイルを作成します。

2. この YAML ファイルに次の内容を追加します。

   apiVersion: auto.gke.io/v1
   kind: AllowlistSynchronizer
   metadata:
     name: ALLOWLIST_SYNCHRONIZER_NAME
   spec:
     allowlistPaths:
     - ALLOWLIST1_PATH
     - ALLOWLIST2_PATH
   

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

   • ALLOWLIST_SYNCHRONIZER_NAME: 新しい同期ツールの名前。許可リストがサポートするワークロードまたはチームに、わかりやすい名前を付けてください。

   • ALLOWLIST1_PATH, ALLOWLIST2_PATH, ...: インストールする許可リスト ファイルまたはディレクトリのパスのリスト。たとえば、GKE 承認済みの許可リストの次の例をご覧ください。

     allowlistPaths:
     - Gke-Org/accelerators/*
     - Wiz/wiz-sensor/v1/wiz-sensor-v1.yaml
     

     または、お客様所有の許可リストの次の例のようにします。

     allowlistPaths:
     - my-agent/log-collector/*
     - my-agent/privileged-logging-agent.yaml
     

     クラスタ構成は、クラスタの許可リストパスを構成するセクションで説明されているように、指定したパスをサポートしている必要があります。また、各 AllowlistSynchronizer には、GKE 承認済みの許可リストのみ、または顧客所有の許可リストのみが含まれている必要があります。

3. お客様所有の Cloud Storage バケットから許可リストをインストールする場合は、AllowlistSynchronizer に spec.projectNumber フィールドと spec.bucketName フィールドを追加します。詳細については、 AllowlistSynchronizer CustomResourceDefinition をご覧ください。

4. YAML ファイルをクラスタにデプロイします。

   kubectl apply -f PATH_TO_YAML_FILE
   

   PATH_TO_YAML_FILE は、前の手順で作成した YAML ファイルのパスで置き換えます。

   AllowlistSynchronizer コントローラは、クラスタ内の指定されたパスから許可リストファイルをインストールします。

5. 同期ツールから Ready ステータスが報告されるまで待ちます。

   kubectl wait --for=condition=Ready allowlistsynchronizer/ALLOWLIST_SYNCHRONIZER_NAME \
       --timeout=60s
   

許可リストのインストールと特権ワークロードのデプロイを継続的インテグレーションと継続的デプロイ（CI/CD）パイプラインに統合することもできます。許可リストが正常にインストールされたら、対応するワークロードをデプロイするようにワークフローを構成します。

既存の AllowlistSynchronizer を更新する

既存の AllowlistSynchronizer を更新して、許可リストファイルを追加または削除できます。次のような状況では、既存の同期ツールを更新することがあります。

• ワークロード オーナーが別の名前の新しい許可リストファイルを追加する。
• 関連する許可リストをグループ化する既存の同期ツールに、新しいワークロード許可リストを追加する。
• 対応するワークロードを使用しなくなったため、同期ツールから許可リストを削除する。

既存の AllowlistSynchronizer オブジェクトを更新するには、次の操作を行います。

1. クラスタ内の既存の同期ツールを一覧表示します。

   kubectl get allowlistsynchronizer
   

2. テキスト エディタで、更新する同期ツールの仕様を開きます。

   ベスト プラクティス: 同期ツールの変更を追跡するには、同期ツールの作成に使用した YAML ファイルを更新します。これらのファイルをバージョン管理システムに保存します。

3. spec.allowlistPaths フィールドを更新して、許可リストのファイルパスを追加、変更、削除します。

4. 保存してテキスト エディタを閉じます。

5. 更新された構成をクラスタに適用します。

   kubectl apply -f PATH_TO_YAML_FILE
   

   PATH_TO_YAML_FILE は、前の手順で更新した YAML ファイルのパスに置き換えます。

更新された同期ツールの構成をデプロイすると、AllowlistSynchronizer オブジェクトのステータスの managedAllowlistStatus.generation フィールドの値が 1 ずつ増加します。AllowlistSynchronizer コントローラが変更を適用します。

許可リストの同期ステータスをモニタリングする

AllowlistSynchronizer をインストールするか、既存の同期ツールを更新すると、同期ステータスをモニタリングできます。ステータスは、許可リストファイルのインストール、削除、変更、および発生する可能性のあるエラーの追跡に役立ちます。

同期の一般的なステータスをモニタリングするには、次のコマンドを実行します。

kubectl get allowlistsynchronizer ALLOWLIST_SYNCHRONIZER_NAME -o yaml

出力は次のようになります。

...
status:
  conditions:
  - type: Ready
    status: "False"
    reason: "SyncError"
    message: "some allowlists failed to sync: example-allowlist-1.yaml"
    lastTransitionTime: "2024-10-12T10:00:00Z"
    observedGeneration: 2
  managedAllowlistStatus:
    - filePath: "gs://path/to/example-allowlist-2.yaml"
      generation: 1
      phase: Installed
      lastSuccessfulSync: "2024-10-10T10:00:00Z"
    - filePath: "gs://path/to/example-allowlist-1.yaml"
      phase: Failed
      lastError: "Initial install failed: invalid contents"
      lastSuccessfulSync: "2024-10-08T10:00:00Z"

この出力例では、example-allowlist-1.yaml 許可リストの同期に失敗し、example-allowlist-2.yaml 許可リストが正常にインストールされています。これらのフィールドの説明については、AllowlistSynchronizer のステータスをご覧ください。

クラスタに許可リストが存在することを確認する

クラスタに許可リストが存在することを確認するには、次のコマンドを実行します。

kubectl get workloadallowlist

クラスタにインストールされている許可リストのリストが返されます。出力に、使用する許可リストが含まれていることを確認します。

特権ワークロードをデプロイする

許可リストのインストールが正常に完了したら、対応するワークロードをクラスタにデプロイできます。ワークロードのインストール手順は、ワークロードのオーナーから提供されます。Autopilot パートナーのリストとドキュメントへのリンクについては、Autopilot パートナーをご覧ください。

非公開イメージ ミラー リポジトリを使用する

所有するプライベート リポジトリに、特権ワークロードのコンテナ イメージをミラーリングできます。これらのミラーリングされたイメージをワークロードで実行するには、次の要件をすべて満たす必要があります。

• ミラーリングされたイメージの SHA-256 ダイジェストが、一般公開されているワークロードのイメージ ダイジェストと一致している必要があります。
• 指定する SHA-256 イメージ ダイジェストは、クラスタに同期される WorkloadAllowlist オブジェクトに存在する必要があります。

ワークロードがミラーリングされたイメージをサポートしている場合、そのワークロードの許可リスト仕様の containers.imageDigests フィールドにイメージ ダイジェストのリストが含まれます。通常、このフィールドには、使用可能なコンテナ イメージのバージョンごとに個別のダイジェストがあります。イメージ ダイジェストのリストを表示する手順は次のとおりです。

1. 許可リストがクラスタに存在することを確認します。

2. インストールされている許可リストの仕様を取得します。

   kubectl get workloadallowlist ALLOWLIST_NAME -o yaml
   

   ALLOWLIST_NAME は、インストールされている許可リストの名前に置き換えます。例: company-name-solution-v1.0.0

   この機能をサポートするワークロードの場合、出力は次のようになります。imageDigests フィールドには、許可されるダイジェストのリストが含まれます。

   # lines omitted for clarity
   - containerName: pause-container1
     imageDigests:
     - cb5c1bddd1b5665e1867a7fa1b5fa843a47ee433bbb75d4293888b71def53229
     - 932ea160d395f3d7f76c0c17a52a63c4cfe1836a900f1058b6bc20b16fd10d23
   

   出力に imageDigests フィールドが含まれていない場合や、使用するリリースのダイジェストがリストにない場合は、ワークロード オーナーに直接連絡して、許可リストの更新を依頼してください。ワークロード オーナーがイメージ ダイジェストを許可リストに追加すると、クラスタ内の許可リストの同期ツールが更新後の許可リストを自動的にインストールします。

3. サポートされているイメージ ダイジェストのいずれかをワークロード マニフェストに追加します。

たとえば、パートナーの一般公開されている Pod 仕様に次のイメージが含まれているとします。

...
  containers:
  - name: pause-container1
    image: partner-repo/pause1@sha256:cb5c1bddd1b5665e1867a7fa1b5fa843a47ee433bbb75d4293888b71def53229
    securityContext:
      privileged: true

次の例のように、ダイジェストが一般公開されているダイジェストと一致する場合は、ミラーリングされたイメージを使用できます。

...
  containers:
  - name: pause-container1
    image: my-private-repo/pause1@sha256:cb5c1bddd1b5665e1867a7fa1b5fa843a47ee433bbb75d4293888b71def53229
    securityContext:
      privileged: true

前の例と同様に、SHA-256 ダイジェストをイメージ フィールドに含める必要があります。ダイジェストが一致しない場合、ミラーリングされたイメージは実行されません。パートナー イメージをミラーリングするときにイメージ ダイジェストを保持するには、crane、ORAS、skopeo などのツールの使用を検討してください。

特権ワークロードを削除する

クラスタで特権ワークロードの実行を停止するには、対応する許可リストのパスを AllowlistSynchronizer から削除します。同期ツールにより許可リストがアンインストールされます。

同期ツールを更新する代わりに、クラスタから WorkloadAllowlist オブジェクトを削除すると、同期ツールにより許可リストが再インストールされます。AllowlistSynchronizer からパスを削除してください。

許可リストをアンインストールするには、次の操作を行います。

1. 許可リストを管理する AllowlistSynchronizer の YAML マニフェストで、アンインストールする許可リストのパスを削除します。手順については、既存の AllowlistSynchronizer を更新するをご覧ください。

2. 許可リストがアンインストールされたことを確認するには、クラスタ内の WorkloadAllowlist オブジェクトのリストを取得します。

   kubectl get workloadallowlist
   

   削除する許可リストが出力に含まれていないことを確認します。

3. クラスタからワークロードを削除します。手順については、ワークロード プロバイダのドキュメントをご覧ください。

クラスタで許可リストのインストールを防止する

特定のクラスタで特権ワークロードの許可リストがインストールされないようにするには、クラスタの作成または更新時に --autopilot-privileged-admission フラグで空の文字列（""）を指定します。

• クラスタの特定の許可リストパスを無効にするには、クラスタの作成時または更新時に、それらの許可リストのパスを省略します。

  gcloud container clusters update CLUSTER_NAME \
      --location=LOCATION \
      --autopilot-privileged-admission=ALLOWLIST1_PATH,ALLOWLIST2_PATH,...
  

  ALLOWLIST1_PATH,ALLOWLIST2_PATH,... は、許可リストのソースへのパスのカンマ区切りのリストに置き換えます。無効にするパスは省略します。

• 既存のクラスタのすべての許可リストを無効にするには、承認済みパスとして空の文字列を指定します。

  gcloud container clusters update CLUSTER_NAME \
      --location=LOCATION \
      --autopilot-allowlist-paths=""
  

  注意: このオペレーションにより、パートナー ワークロードと承認済みのオープンソース ワークロードの許可リストを含む、すべての許可リストのインストールが無効になります。実行中のアプリケーションがこれらのワークロードに依存していないことを確認します。

トラブルシューティング

同期またはワークロードのデプロイが失敗した場合は、特権 Autopilot ワークロードのデプロイのトラブルシューティングをご覧ください。

次のステップ

• GKE Autopilot パートナーから利用可能なワークロードについて学習する
• GKE Autopilot で特権オープンソース ワークロードを実行する
• デフォルトの GKE Autopilot セキュリティ機能について学習する
• AllowlistSynchronizer CustomResourceDefinition を読み取る