gke-platform-security について
gke-platform-securityは、GKEのプラットフォームやクラスターを運用する担当者向けのセキュリティ設定リファレンスです。Secret Manager、RBAC、Shielded Nodes、Binary Authorizationなどのクラスター設定、強化方法、IAMロールを扱います。
主な機能
- 01クラスターのセキュリティ基準を提示
- 02Secret Manager連携とローテーションの説明
- 03RBACバインディングの確認と強化
- 04Binary AuthorizationとShielded Nodesの解説
- 05一般的なGKE IAMロールの推奨
活用シーン
- 01クラスター設定のセキュリティ基準への照合
- 02過剰に広いRBAC権限の制限
- 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.goog | Day-0 | クラスターの Pod に対する Workload Identity Federation |
secretManagerConfig.enabled | true | Day-1 | Google Secret Manager のクラスターアドオン統合 |
secretManagerConfig.rotationConfig | enabled: true, rotationInterval: 120s | Day-1 | クラスターレベルでのシークレットの自動ローテーション |
rbacBindingConfig.enableInsecureBindingSystemAuthenticated | false | Day-0 | レガシーな system:authenticated バインディングをブロック |
rbacBindingConfig.enableInsecureBindingSystemUnauthenticated | false | Day-0 | レガシーな system:unauthenticated バインディングをブロック |
nodeConfig.shieldedInstanceConfig.enableSecureBoot | true | Day-0 | 検証可能なブート整合性 |
nodeConfig.shieldedInstanceConfig.enableIntegrityMonitoring | true | Day-0 | 実行時の整合性チェック |
nodeConfig.workloadMetadataConfig.mode | GKE_METADATA | Day-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)