Standard クラスタで Autopilot セキュリティ ポリシーを適用する

Google Kubernetes Engine（GKE）Autopilot クラスタは、多くの一般的な攻撃経路を防ぐように設計されたさまざまなセキュリティ ポリシーを適用します。このドキュメントでは、プラットフォーム管理者が Standard クラスタでこれらの Autopilot ポリシーの一部またはすべてを適用する方法について説明します。Autopilot クラスタは、より高いベースラインの GKE セキュリティ ポスチャーを目的として設計されているため、Autopilot クラスタでクラスタ ポリシーの適用を無効にすることはできません。

Standard クラスタでは、特定のポリシーをいつでも有効または無効にできます。組織の管理者は、組織、フォルダ、またはプロジェクトでカスタム制約を適用することで、特定の Autopilot ポリシーを無効にできるかどうかを制御できます。これらの事前定義ポリシーを使用すると、複雑な RBAC ロールとバインディングを記述することなく、セキュリティのベスト プラクティスを適用できます。クラスタレベルのポリシーの多くは、クラスタやワークロードに Autopilot モードを使用する予定がない場合でも、クラスタのセキュリティを強化するのに役立ちます。使用可能な Autopilot クラスタ ポリシーの詳細については、サポートされているポリシーのセクションをご覧ください。

Autopilot クラスタ ポリシーの適用に関する考慮事項

Autopilot クラスタでは常にこれらのポリシーが適用されますが、Standard クラスタには、適用するポリシーに違反する可能性のある既存のワークロードとノードプールが存在することがよくあります。クラスタでポリシーを適用または無効にする前に、次の考慮事項を確認してください。

  • 変更は新しいワークロードにのみ適用される: ワークロードに適用されるポリシーを有効にすると、変更はそのポリシーの有効化後に作成または変更された Pod にのみ適用されます。ポリシーに違反する既存の Pod は引き続き実行できます。ポリシーを有効にする前に、クラスタ内の既存のワークロードを確認して、ポリシーの制約に準拠していることを確認します。
  • ノードプール ポリシーはすべてのノードに適用される: Standard クラスタのノードプールに適用されるポリシーを有効にすると、制約は新しいノードプールと既存のノードプールの両方に適用されます。既存のノードプールがポリシーに違反している場合、クラスタの更新オペレーションは失敗します。たとえば、既存のユーザー管理ノードプールがあるクラスタで no-standard-node-pools ポリシーを有効にしようとすると、オペレーションは失敗します。ノードプール ポリシーを有効にする前に、クラスタ内の既存のノードプールを確認します。
  • すべてのポリシーを有効にすると Autopilot モードが有効になる: 使用可能なすべての Autopilot ポリシー（ユーザー管理ノードプールを禁止するポリシーを含む）を有効にすると、クラスタ内のすべてのワークロードが Autopilot モードでのみ実行できるようになります。つまり、すべてのワークロードが Autopilot のセキュリティ制約とすべてのクラスタ ポリシーに準拠する必要があります。このアプローチでは、Standard クラスタ全体を Autopilot モードで実行できます。必要に応じて、特定のポリシーを無効にすることもできます。

始める前に

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

  • Google Kubernetes Engine API を有効にする。
    • Google Kubernetes Engine API を有効化
  • このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化します。gcloud CLI をインストール済みの場合は、gcloud components update コマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。

クラスタで特定の Autopilot ポリシーを有効にする

gcloud CLI または GKE API を使用して、Standard クラスタの作成または更新時に特定のポリシーを有効にします。特定の Autopilot クラスタ ポリシーを、GKE がクラスタで適用するポリシーのリストに追加するには、gcloud container clusters create コマンドまたは gcloud container clusters update コマンドで --autopilot-cluster-policies フラグを使用します。

次の例は、既存のクラスタでポリシーを有効にする方法を示しています。

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --autopilot-cluster-policies=AUTOPILOT_POLICIES

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

  • CLUSTER_NAME: Standard クラスタの名前。
  • CONTROL_PLANE_LOCATION: クラスタ コントロール プレーンのリージョンまたはゾーン（例: us-central1、us-central1-a）。
  • AUTOPILOT_POLICIES: クラスタで適用を開始する Autopilot クラスタ ポリシーのカンマ区切りのリスト（no-system-mutation,no-system-impersonation など）。1 つ以上のサポートされているポリシーを指定する必要があります。指定したポリシーは、GKE がクラスタですでに適用しているポリシーのリストに追加されます。ポリシーの適用を無効にするには、クラスタ内の特定の Autopilot ポリシーを無効にするをご覧ください。

Bad value [invalid policy]: で始まるエラー メッセージが表示されてコマンドが失敗した場合は、指定したすべてのポリシー名がサポートされているポリシーのリストに含まれていることを確認します。

ポリシーの適用を確認する

特定のポリシーを有効にした後、そのポリシーに違反するリソースを作成して、適用が機能していることを確認できます。たとえば、no-system-mutation ポリシーを有効にすると、kube-system Namespace に Pod を作成できます。GKE は Pod の作成オペレーションをブロックし、次のようなエラー メッセージを表示します。

Error from server (Forbidden): pods is forbidden: User cannot create resource "pods" in API group "" in the namespace "kube-system": GKE Warden authz [denied by managed-namespaces-limitation]: the namespace "kube-system" is managed and the request's verb "create" is denied

クラスタで特定の Autopilot ポリシーを無効にする

Autopilot クラスタ ポリシーはいつでも無効にできます。ポリシーを無効にすると、セキュリティ要件が変更された場合や、ポリシーを有効にしたときに既存のワークフローが中断された場合に便利です。クラスタで GKE が適用するポリシーのリストからポリシーを削除するには、gcloud container clusters update コマンドで --remove-autopilot-cluster-policies フラグを使用します。

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --remove-autopilot-cluster-policies=AUTOPILOT_POLICIES

--remove-autopilot-cluster-policies フラグに少なくとも 1 つの値を指定する必要があります。値を指定せずにこのフラグを指定すると、オペレーションは失敗します。

Bad value [invalid policy]: で始まるエラー メッセージが表示されてコマンドが失敗した場合は、指定したすべてのポリシー名がサポートされているポリシーのリストに含まれていることを確認します。

組織で Autopilot クラスタ ポリシーを適用する

組織管理者は、カスタム組織ポリシーの制約を使用して、組織、プロジェクト、フォルダ全体でこれらのクラスタ ポリシーの使用を適用できます。この追加の対策により、必要なクラスタ ポリシーがクラスタから不正または意図せずに削除されるのを防ぐことができます。次の例のように、カスタム制約で ClusterPolicyConfig フィールドを使用します。

name: organizations/ORGANIZATION_ID/customConstraints/custom.autopilotClusterPolicies
resourceTypes:
-   container.googleapis.com/Cluster
methodTypes:
-   CREATE
-   UPDATE
condition: "resource.ClusterPolicyConfig.no_system_mutation == true && resource.ClusterPolicyConfig.no_system_impersonation == true"
actionType: ALLOW
displayName: Autopilot policies in Standard clusters.
description: For all new and existing Standard clusters, enable the no_system_mutation and no_system_impersonation Autopilot cluster policies. For more information, see https://docs.cloud.google.com/kubernetes-engine/security/autopilot-cluster-policies-standard.

サポートされているポリシー

Standard クラスタで使用可能な Autopilot ポリシーは、クラスタレベルで 1 つ以上のセキュリティのベスト プラクティスを実装します。no-system-mutation、no-system-impersonation、no-unsafe-webhooks などのポリシーは、Autopilot モードの使用に関心がない場合でも、GKE クラスタのセキュリティを強化するのに役立ちます。

次の表に、Standard クラスタで有効にできる Autopilot ポリシーを示します。これは、ポリシーの適用に備えるうえで役立ちます。

ポリシー名 説明 有効化前の準備
no-system-mutation GKE システム Namespace（kube-system など）でのリソースの作成または変更を防止します。 Pod をシステム Namespace から独自の Namespace に移動します。
no-system-impersonation システム ユーザーのなりすましをブロックし、システム プリンシパルを使用した CertificateSigningRequest の作成を防ぎます。 システム ID 用に生成された未承認の CertificateSigningRequest を探します。承認済みの不正な CertificateSigningRequest が見つかった場合は、クラスタの認証情報をローテーションして証明書を無効にします。
no-unsafe-webhooks アドミッション Webhook とポリシーが、Node オブジェクト、PersistentVolume、CertificateSigningRequest などの重要なシステム リソースをインターセプトしないようにします。 Recommender サービスを使用して、システム リソースをインターセプトする Webhook を特定します。Webhook が見つかった場合は、Webhook の構成を変更します。詳細については、Webhook 使用時のコントロール プレーンの安定性を確保するをご覧ください。
no-standard-node-pools 手動で作成されたノードプールや自動作成されたノードプールなど、ユーザー管理のノードプールがクラスタに存在しないようにします。クラスタに存在できるのは Autopilot ノードプールのみです。 クラスタで作成されたデフォルト ノードプールなど、既存の Autopilot 以外のノードプールをすべて削除します。

次のステップ