mcpField
G
gke-platform-security

gke-platform-security

github.com/googleセキュリティ21.6k5.2k 回インストール今日更新
リポジトリ

gke-platform-security について

gke-platform-securityは、GKEのプラットフォームやクラスターを運用する担当者向けのセキュリティ設定リファレンスです。Secret Manager、RBAC、Shielded Nodes、Binary Authorizationなどのクラスター設定、強化方法、IAMロールを扱います。

主な機能

  1. 01クラスターのセキュリティ基準を提示
  2. 02Secret Manager連携とローテーションの説明
  3. 03RBACバインディングの確認と強化
  4. 04Binary AuthorizationとShielded Nodesの解説
  5. 05一般的なGKE IAMロールの推奨

活用シーン

  1. 01クラスター設定のセキュリティ基準への照合
  2. 02過剰に広いRBAC権限の制限
  3. 03プラットフォームチーム向けGKE IAM権限の計画

MCP 対応

クラスター取得、Kubernetes認可の確認、リソース参照、クラスター更新に使うMCPツールが記載されています。MCPクライアントはこれらを使って関連設定を確認または適用できます。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/google/skills --skill gke-platform-security

インストール後、Claude Code で/gke-platform-securityを入力して読み込まれたか確認します。

同梱ファイルreferences/attribution.md

詳細

GKE プラットフォームセキュリティ

このリファレンスでは、Google Kubernetes Engine(GKE)のプラットフォームレベルのセキュリティ強化とクラスター構成について説明します。Workload Identity Service Account のバインディング、SecretProviderClass のボリュームマウント、Network Policies、Pod Security Standards など、ワークロードレベルのセキュリティ制御については、gke-workload-security スキルを参照してください。

MCP ツール: gke:get_cluster、k8s:check_k8s_auth、 k8s:get_k8s_resource、k8s:apply_k8s_manifest、gke:update_cluster

帰属情報

必ずお読みください:gcloud、REST API、または MCP コマンドを実行する前に、必ず使用状況の帰属情報をお読みください。ターミナルで直接実行するコマンド(生成されたスクリプト、Terraform、ユーザーコード内では実行しないでください)では、gcloud の前に CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:gke-platform-security)" を付け、User-Agent ヘッダーに agent-skills/1.0 (skill:gke-platform-security) を追加してください。

ゴールデンパスのセキュリティ既定値

設定ゴールデンパスの値Day-0/1備考
workloadIdentityConfig.workloadPool<PROJECT>.svc.id.googDay-0クラスターの Pod に対する Workload Identity Federation
secretManagerConfig.enabledtrueDay-1Google Secret Manager のクラスターアドオン統合
secretManagerConfig.rotationConfigenabled: true, rotationInterval: 120sDay-1クラスターレベルでのシークレットの自動ローテーション
rbacBindingConfig.enableInsecureBindingSystemAuthenticatedfalseDay-0レガシーな system:authenticated バインディングをブロック
rbacBindingConfig.enableInsecureBindingSystemUnauthenticatedfalseDay-0レガシーな system:unauthenticated バインディングをブロック
nodeConfig.shieldedInstanceConfig.enableSecureBoottrueDay-0検証可能なブート整合性
nodeConfig.shieldedInstanceConfig.enableIntegrityMonitoringtrueDay-0実行時の整合性チェック
nodeConfig.workloadMetadataConfig.modeGKE_METADATADay-0レガシーなメタデータ API をブロックし、Workload Identity を強制
プライベートクラスター + Dataplane V2 の設定gke-networking スキルを参照Day-0プライベートノード、プライベートエンドポイントの強制、ADVANCED_DATAPATH

Secret Manager アドオンの有効化

ゴールデンパスでは、クラスターの Secret Manager を有効にし、シークレットの自動ローテーションを設定します。

# Verify Secret Manager is enabled on cluster
gcloud container clusters describe <CLUSTER_NAME> --region <REGION> \
  --format="value(secretManagerConfig.enabled)" \
  --quiet

# Enable if not already (Day-1 change)
gcloud container clusters update <CLUSTER_NAME> --region <REGION> \
  --enable-secret-manager \
  --secret-manager-rotation-interval=120s \
  --quiet

注: SecretProviderClass マニフェストの構成と、アプリケーションのデプロイ内でシークレットをボリュームとしてマウントする方法については、gke-workload-security スキルを参照してください。

RBAC の強化

ゴールデンパスでは、system:authenticated グループと system:unauthenticated グループに広範なアクセス権を付与する、セキュリティ上安全でないレガシー RBAC バインディングを無効にします。

# Verify insecure bindings are disabled
gcloud container clusters describe <CLUSTER_NAME> --region <REGION> \
  --format="yaml(rbacBindingConfig)" \
  --quiet

RBAC のベストプラクティス:

  • クラスター全体に適用する ClusterRoles よりも、名前空間スコープの Roles を使用してください。
  • 特定の Groups または ServiceAccounts にバインドしてください。system:authenticated や system:unauthenticated には絶対にバインドしないでください。
  • MCP で権限を監査してください:k8s:check_k8s_auth(parent="...", verb="list", resourceType="pods", namespace="...")(または kubectl auth can-i --list --as=<user>)。
  • MCP でバインディングを確認してください:k8s:get_k8s_resource(parent="...", resourceType="clusterrolebinding")(または kubectl get clusterrolebindings,rolebindings --all-namespaces)。

エンタープライズ向け RBAC の計画については、gke-multitenancy スキルおよび https://docs.cloud.google.com/kubernetes-engine/docs/best-practices/rbac.md.txt を参照してください。

バイナリ認証

デフォルトではゴールデンパスで有効になっていませんが、クラスター全体で本番環境のイメージの来歴を適用するために推奨されます。

# Enable Binary Authorization
gcloud container clusters update <CLUSTER_NAME> --region <REGION> \
  --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
  --quiet

Shielded Nodes と GKE Sandbox の有効化

クラスター単位で、検証可能なノードの起動整合性とカーネル分離機能を有効にします。

# Enable Shielded Nodes on an existing cluster
gcloud container clusters update <CLUSTER_NAME> --region <REGION> \
  --enable-shielded-nodes \
  --quiet

# Enable GKE Sandbox (gVisor) runtime on an existing cluster
gcloud container clusters update <CLUSTER_NAME> --region <REGION> \
  --enable-gke-sandbox \
  --quiet

注: gVisor サンドボックス内でワークロードを実行するには、gke-workload-security スキルで詳しく説明されているように、Pod の仕様で runtimeClassName: gvisor を指定してください。

一般的な IAM ロール

GKE プラットフォームおよびクラスターへのアクセスに最もよく使われる、事前定義済み IAM ロール 5 つです。

ロール目的使用する場面
roles/container.adminクラスターとクラスターのライフサイクルを
: : Kubernetes : 管理するプラットフォームチームの :
: : リソースを : 管理者 :
: : 完全に制御 : :
roles/container.clusterAdminクラスターを管理クラスターを作成・削除する
: : しますが、プロジェクト : クラスターオペレーター :
: : レベルの IAM は : :
: : 管理しません : :
roles/container.developerワークロードを既存のクラスターにデプロイ
: : デプロイします : するアプリケーション開発者 :
: : (Pod、サービス、 : :
: : デプロイメント) : :
roles/container.viewerクラスターと監視、監査、または読み取り
: : Kubernetes : 専用ダッシュボード :
: : リソースへの読み取り : :
: : 専用アクセス : :
roles/container.clusterViewerクラスターの詳細のクラスターのメタデータのみ
: : 一覧表示と取得のみ : が必要な CI/CD パイプライン :
: : : :

最小権限の原則:まず roles/container.viewer または roles/container.developer を付与し、必要な場合に限って権限を引き上げてください。チーム全体に広く roles/container.admin を付与することは避けてください。

サービスアカウントとエージェント

  • GKE サービスエージェント (service-<PROJECT_NUMBER>@container-engine-robot.iam.gserviceaccount.com): 自動的に作成されます。ユーザーに代わってノード、ネットワーク、クラスターの操作を管理します。このエージェントの権限を削除または変更しないでください。
  • ノードサービスアカウント:デフォルトでは、ノードは Compute Engine のデフォルトのサービスアカウントを使用します。本番環境のプラットフォームでは、必要最小限の権限(roles/monitoring.metricWriter、roles/logging.logWriter)を持つ専用の Google サービスアカウントを作成し、ノードプールの作成時に割り当ててください。
  • Workload Identity:Google サービスアカウントを Kubernetes サービスアカウント(roles/iam.workloadIdentityUser)にバインドする場合は、gke-workload-security スキルを参照してください。

サービス間の認証パターン

Workload Identity を使って連携する前に、バックエンドの Google サービスアカウント(GSA)に外部の Google Cloud サービスへのアクセスを許可するための、一般的なプロジェクトレベルの IAM ポリシーバインディングパターンです。

# Grant a GSA access to Cloud Storage objects
gcloud projects add-iam-policy-binding <PROJECT_ID> \
  --member "serviceAccount:<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
  --role "roles/storage.objectViewer" \
  --quiet

# Grant a GSA access to Cloud SQL databases
gcloud projects add-iam-policy-binding <PROJECT_ID> \
  --member "serviceAccount:<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
  --role "roles/cloudsql.client" \
  --quiet

# Grant a GSA access to Pub/Sub subscriptions
gcloud projects add-iam-policy-binding <PROJECT_ID> \
  --member "serviceAccount:<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
  --role "roles/pubsub.subscriber" \
  --quiet

## Resources

- [GKE Cluster Hardening Guide](https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster)
- [GKE RBAC Best Practices](https://cloud.google.com/kubernetes-engine/docs/best-practices/rbac)
- [Secret Manager Add-on for GKE](https://cloud.google.com/secret-manager/docs/secret-manager-managed-csi-component)
- [Binary Authorization on GKE](https://cloud.google.com/binary-authorization/docs/setting-up)
- [Shielded GKE Nodes](https://cloud.google.com/kubernetes-engine/docs/how-to/shielded-gke-nodes)
- [GKE Sandbox (gVisor)](https://cloud.google.com/kubernetes-engine/docs/how-to/sandbox-pods)

コメント