gke-security

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

GKE Security

GKE 安全

This reference covers security configuration for GKE clusters. The golden path enforces a hardened security posture by default.

MCP Tools:

get_cluster

check_k8s_auth

get_k8s_resource

apply_k8s_manifest

update_cluster

本参考文档涵盖GKE集群的安全配置。黄金路径默认强制实施强化的安全态势。

MCP 工具：

get_cluster

check_k8s_auth

get_k8s_resource

apply_k8s_manifest

update_cluster

Golden Path Security Defaults

黄金路径安全默认值

Setting	Golden Path Value	Day-0/1	Notes
`workloadIdentityConfig.workloadPool`	`<PROJECT>.svc.id.goog`	Day-0	Workload Identity Federation for Pods
`secretManagerConfig.enabled`	`true`	Day-1	Google Secret Manager integration
`secretManagerConfig.rotationConfig`	`enabled: true, rotationInterval: 120s`	Day-1	Automatic secret rotation
`rbacBindingConfig.enableInsecureBindingSystemAuthenticated`	`false`	Day-0	Blocks legacy `system:authenticated` bindings
`rbacBindingConfig.enableInsecureBindingSystemUnauthenticated`	`false`	Day-0	Blocks legacy `system:unauthenticated` bindings
`nodeConfig.shieldedInstanceConfig.enableSecureBoot`	`true`	Day-0	Verifiable boot integrity
`nodeConfig.shieldedInstanceConfig.enableIntegrityMonitoring`	`true`	Day-0	Runtime integrity checks
`nodeConfig.workloadMetadataConfig.mode`	`GKE_METADATA`	Day-0	Blocks legacy metadata API, enforces Workload Identity
Private cluster + Dataplane V2 settings	See the `gke-networking` skill	Day-0	Private nodes, private endpoint enforcement, ADVANCED_DATAPATH

设置项	黄金路径值	实施阶段	说明
`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

Workload Identity Federation

Workload Identity is the recommended way for pods to access Google Cloud APIs. It eliminates the need for static service account keys.

Workload Identity是Pod访问Google Cloud API的推荐方式，无需使用静态服务账号密钥。

Setup

配置步骤

bash

undefined

bash

undefined

1. Create a Google Service Account (GSA)

1. 创建Google服务账号（GSA）

gcloud iam service-accounts create <GSA_NAME>
--project <PROJECT_ID>
--display-name "Workload Identity SA"
--quiet

2. Grant IAM roles to the GSA

2. 为GSA授予IAM角色

gcloud projects add-iam-policy-binding <PROJECT_ID>
--member "serviceAccount:<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com"
--role "<ROLE>"
--quiet

3. Create Kubernetes Service Account (KSA)

3. 创建Kubernetes服务账号（KSA）

kubectl create namespace <NAMESPACE> kubectl create serviceaccount <KSA_NAME> --namespace <NAMESPACE>

4. Bind KSA to GSA

4. 将KSA与GSA绑定

gcloud iam service-accounts add-iam-policy-binding
<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com
--role roles/iam.workloadIdentityUser
--member "serviceAccount:<PROJECT_ID>.svc.id.goog[<NAMESPACE>/<KSA_NAME>]"
--quiet

5. Annotate KSA

5. 为KSA添加注解

kubectl annotate serviceaccount <KSA_NAME>
--namespace <NAMESPACE>
iam.gke.io/gcp-service-account=<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com


> See [assets/workload-identity-pod.yaml](./assets/workload-identity-pod.yaml)
> for a test pod.

kubectl annotate serviceaccount <KSA_NAME>
--namespace <NAMESPACE>
iam.gke.io/gcp-service-account=<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com


> 测试Pod示例请查看[assets/workload-identity-pod.yaml](./assets/workload-identity-pod.yaml)

Verification

验证

bash

kubectl run workload-identity-test \
  --image=gcr.io/google.com/cloudsdktool/cloud-sdk:slim \
  --serviceaccount=<KSA_NAME> --namespace=<NAMESPACE> \
  --rm -it -- gcloud auth list --quiet

bash

kubectl run workload-identity-test \
  --image=gcr.io/google.com/cloudsdktool/cloud-sdk:slim \
  --serviceaccount=<KSA_NAME> --namespace=<NAMESPACE> \
  --rm -it -- gcloud auth list --quiet

Secret Manager Integration

Secret Manager集成

The golden path enables Secret Manager with automatic rotation. Secrets are synced to Kubernetes Secrets.

bash

undefined

黄金路径启用了带自动轮换功能的Secret Manager，密钥会同步到Kubernetes Secrets中。

bash

undefined

Verify Secret Manager is enabled on cluster

验证集群是否已启用Secret Manager

gcloud container clusters describe <CLUSTER_NAME> --region <REGION>
--format="value(secretManagerConfig.enabled)"
--quiet

Enable if not already (Day-1 change)

若未启用则开启（Day-1变更）

gcloud container clusters update <CLUSTER_NAME> --region <REGION>
--enable-secret-manager
--secret-manager-rotation-interval=120s
--quiet

undefined

gcloud container clusters update <CLUSTER_NAME> --region <REGION>
--enable-secret-manager
--secret-manager-rotation-interval=120s
--quiet

undefined

Mounting Secrets via CSI Volume (Deployment Example)

通过CSI卷挂载密钥（Deployment示例）

Once the Secret Manager add-on is enabled, workloads can mount secrets as volumes using the Secrets Store CSI driver. This requires two steps:

Define a
SecretProviderClass
to specify which secrets to retrieve from Secret Manager.
Mount the volume in a
Deployment
referencing that class.

[!IMPORTANT] Production Best Practice: Always demonstrate workload integrations (like Secret Manager CSI) using production-standard Deployment
manifests rather than raw
Pod
manifests.

启用Secret Manager插件后，工作负载可通过Secrets Store CSI驱动将密钥作为卷挂载，需完成以下两步：

定义
SecretProviderClass
，指定从Secret Manager获取哪些密钥。
在
Deployment
中挂载卷，引用该类。

[!IMPORTANT] 生产最佳实践：始终使用符合生产标准的**
Deployment
**清单展示工作负载集成（如Secret Manager CSI），而非原始
Pod
清单。

Step 1: Create the SecretProviderClass

步骤1：创建SecretProviderClass

yaml

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: app-secrets-provider
  namespace: default
spec:
  provider: gke  # Identifies GKE managed provider
  parameters:
    secrets: |
      - resourceName: "projects/<PROJECT_ID>/secrets/db-password/versions/latest"
        fileName: "db-password.txt"

yaml

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: app-secrets-provider
  namespace: default
spec:
  provider: gke  # 指定GKE托管提供商
  parameters:
    secrets: |
      - resourceName: "projects/<PROJECT_ID>/secrets/db-password/versions/latest"
        fileName: "db-password.txt"

Step 2: Mount the secret in a Deployment

步骤2：在Deployment中挂载密钥

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: secure-app
  template:
    metadata:
      labels:
        app: secure-app
    spec:
      serviceAccountName: secure-ksa  # Must be bound to GSA with Secret Manager Secret Accessor role
      containers:
      - name: app
        image: <IMAGE>
        volumeMounts:
        - name: secrets-volume
          mountPath: "/var/secrets"
          readOnly: true
      volumes:
      - name: secrets-volume
        csi:
          driver: secrets-store.csi.k8s.io
          readOnly: true
          volumeAttributes:
            secretProviderClass: "app-secrets-provider"

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: secure-app
  template:
    metadata:
      labels:
        app: secure-app
    spec:
      serviceAccountName: secure-ksa  # 必须绑定拥有Secret Manager Secret Accessor角色的GSA
      containers:
      - name: app
        image: <IMAGE>
        volumeMounts:
        - name: secrets-volume
          mountPath: "/var/secrets"
          readOnly: true
      volumes:
      - name: secrets-volume
        csi:
          driver: secrets-store.csi.k8s.io
          readOnly: true
          volumeAttributes:
            secretProviderClass: "app-secrets-provider"

RBAC Hardening

RBAC强化

The golden path disables insecure legacy RBAC bindings that grant broad access to

system:authenticated

and

system:unauthenticated

groups.

bash

undefined

黄金路径禁用了不安全的旧版RBAC绑定，这些绑定会向

system:authenticated

和

system:unauthenticated

组授予广泛权限。

bash

undefined

Verify insecure bindings are disabled

验证不安全绑定是否已禁用

gcloud container clusters describe <CLUSTER_NAME> --region <REGION>
--format="yaml(rbacBindingConfig)"
--quiet


**Best practices for RBAC:**

-   Use namespace-scoped Roles over cluster-wide ClusterRoles
-   Bind to specific Groups or ServiceAccounts, never to `system:authenticated`
-   Audit permissions via MCP: `check_k8s_auth(parent="...", verb="list",
    resourceType="pods", namespace="...")` (or `kubectl auth can-i --list
    --as=<user>`)
-   Review bindings via MCP: `get_k8s_resource(parent="...",
    resourceType="clusterrolebinding")` (or `kubectl get
    clusterrolebindings,rolebindings --all-namespaces`)

> See the `gke-multitenancy` skill for enterprise RBAC planning and
> https://docs.cloud.google.com/kubernetes-engine/docs/best-practices/rbac.md.txt

gcloud container clusters describe <CLUSTER_NAME> --region <REGION>
--format="yaml(rbacBindingConfig)"
--quiet


**RBAC最佳实践：**

- 优先使用命名空间级别的Role，而非集群级别的ClusterRoles
- 绑定到特定组或服务账号，绝不要绑定到`system:authenticated`
- 通过MCP审核权限：`check_k8s_auth(parent="...", verb="list",
    resourceType="pods", namespace="...")`（或`kubectl auth can-i --list
    --as=<user>`）
- 通过MCP查看绑定：`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

Binary Authorization

二进制授权

Not enabled in golden path by default but recommended for production image provenance:

bash

undefined

默认未在黄金路径中启用，但推荐用于生产环境镜像来源验证：

bash

undefined

Enable Binary Authorization

启用二进制授权

gcloud container clusters update <CLUSTER_NAME> --region <REGION>
--binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
--quiet

undefined

gcloud container clusters update <CLUSTER_NAME> --region <REGION>
--binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
--quiet

undefined

Network Policies

网络策略

Dataplane V2 (golden path) provides built-in Network Policy enforcement. Apply default-deny per namespace:

undefined

Dataplane V2（黄金路径）提供内置的网络策略强制功能，为每个命名空间应用默认拒绝规则：

undefined

MCP (preferred)

优先使用MCP

apply_k8s_manifest(parent="...", yamlManifest="<contents of default-deny-netpol.yaml>")

apply_k8s_manifest(parent="...", yamlManifest="<default-deny-netpol.yaml的内容>")

kubectl fallback

备选kubectl方式

kubectl apply -f ./assets/default-deny-netpol.yaml -n <NAMESPACE>

undefined

kubectl apply -f ./assets/default-deny-netpol.yaml -n <NAMESPACE>

undefined

GKE Sandbox (gVisor)

GKE沙箱（gVisor）

For running untrusted workloads in an isolated sandbox:

bash

undefined

用于在隔离沙箱中运行不受信任的工作负载：

bash

undefined

Enable on cluster (Standard clusters)

在集群上启用（标准集群）

gcloud container clusters update <CLUSTER_NAME> --region <REGION> --enable-gke-sandbox --quiet

Use in pod spec

在Pod规格中使用

Add: runtimeClassName: gvisor

添加：runtimeClassName: gvisor

undefined

undefined

Pod Security Standards (Golden Path)

Pod安全标准（黄金路径）

Pod Security Standards define three profiles that restrict what pods can do. The restricted
profile is the golden path default for production namespaces.

Profile	Level	Use Case
`privileged`	Unrestricted	System namespaces ( `kube-system` ),
: : : infrastructure controllers :
`baseline`	Minimally restrictive	Shared/dev namespaces, legacy apps
: : : being migrated :
`restricted`	Golden path	Production workloads -- blocks
: : : privilege escalation, host access, :
: : : root :

Enforce via namespace labels (Pod Security Admission):

yaml

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

Gradual rollout strategy:

Start with
```
warn
```
+
```
audit
```
on existing namespaces to identify violations
Fix non-compliant workloads (remove
```
privileged
```
,
```
hostNetwork
```
, root user, etc.)
Enable
```
enforce
```
once all workloads pass

restricted

blocks: running as root, privilege escalation, host networking/PID/IPC, host path volumes, and most capabilities. The golden path

workload-identity-pod.yaml

already complies.

Pod安全标准定义了三个限制Pod行为的配置文件，restricted
配置文件是生产命名空间的黄金路径默认值。

配置文件	限制级别	使用场景
`privileged`	无限制	系统命名空间（ `kube-system` ）、基础设施控制器
`baseline`	最低限制	共享/开发命名空间、正在迁移的遗留应用
`restricted`	黄金路径	生产工作负载——阻止权限提升、主机访问、以root用户运行等

通过命名空间标签强制实施（Pod安全准入控制）：

yaml

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

逐步推广策略：

在现有命名空间上先启用
```
warn
```
+
```
audit
```
模式，识别违规情况
修复不符合要求的工作负载（移除
```
privileged
```
、
```
hostNetwork
```
、root用户等）
所有工作负载合规后启用
```
enforce
```
模式

restricted

配置文件会阻止：以root用户运行、权限提升、主机网络/PID/IPC、主机路径卷以及大多数权限。黄金路径的

workload-identity-pod.yaml

已符合要求。

Network Policy Logging (Recommended)

网络策略日志（推荐）

With Dataplane V2 (golden path), you can enable logging for Network Policy decisions. Not a golden path default -- recommended for security auditing.

bash

gcloud container clusters update <CLUSTER_NAME> --region <REGION> \
  --enable-network-policy-logging \
  --quiet

This logs allowed and denied connections, useful for troubleshooting Network Policy rules and auditing traffic flows.

使用Dataplane V2（黄金路径）时，可启用网络策略决策日志。并非黄金路径默认值——推荐用于安全审计。

bash

gcloud container clusters update <CLUSTER_NAME> --region <REGION> \
  --enable-network-policy-logging \
  --quiet

该功能会记录允许和拒绝的连接，有助于排查网络策略规则问题和审计流量流向。

Common IAM Roles

常见IAM角色

The five most common predefined IAM roles for GKE:

Role	Purpose	When to Use
`roles/container.admin`	Full control over	Platform team admins
: : clusters and : managing cluster :
: : Kubernetes : lifecycle :
: : resources : :
`roles/container.clusterAdmin`	Manage clusters but	Cluster operators
: : not project-level : who create/delete :
: : IAM : clusters :
`roles/container.developer`	Deploy workloads	Application
: : (pods, services, : developers deploying :
: : deployments) : to existing clusters :
`roles/container.viewer`	Read-only access to	Monitoring,
: : clusters and : auditing, or :
: : Kubernetes : read-only dashboards :
: : resources : :
`roles/container.clusterViewer`	List and get	CI/CD pipelines that
: : cluster details : need cluster :
: : only : metadata :

Principle of least privilege: Start with
roles/container.viewer
or
roles/container.developer
and escalate only as needed. Avoid granting
roles/container.admin
broadly.

GKE最常用的五个预定义IAM角色：

角色	用途	使用场景
`roles/container.admin`	完全控制集群和Kubernetes资源	平台团队管理员管理集群生命周期
`roles/container.clusterAdmin`	管理集群但无权操作项目级IAM	创建/删除集群的集群运维人员
`roles/container.developer`	部署工作负载（pod、服务、deployments）	向现有集群部署应用的开发人员 :
`roles/container.viewer`	只读访问集群和Kubernetes资源	监控、审计或只读仪表盘使用场景
`roles/container.clusterViewer`	仅查看集群详情	需要集群元数据的CI/CD流水线

最小权限原则：从
roles/container.viewer
或
roles/container.developer
开始，仅在必要时提升权限。避免广泛授予
roles/container.admin
权限。

Service Accounts & Agents

服务账号与代理

GKE Service Agent (
```
service-<PROJECT_NUMBER>@container-engine-robot.iam.gserviceaccount.com
```
): Automatically created. Manages nodes, networking, and cluster operations on your behalf. Do not remove or modify its permissions.
Node Service Account: By default, nodes use the Compute Engine default service account. For production, create a dedicated SA with minimal permissions and assign it via node pool config.
Workload Identity: The recommended way for pods to access Google Cloud APIs. Maps a Kubernetes ServiceAccount to a Google IAM ServiceAccount — see Workload Identity setup above.

GKE服务代理 (
```
service-<PROJECT_NUMBER>@container-engine-robot.iam.gserviceaccount.com
```
): 自动创建，代表您管理节点、网络和集群操作。请勿移除或修改其权限。
节点服务账号：默认情况下，节点使用Compute Engine默认服务账号。生产环境中，请创建具有最小权限的专用服务账号，并通过节点池配置分配。
Workload Identity：Pod访问Google Cloud API的推荐方式，将Kubernetes服务账号映射到Google IAM服务账号——请查看上方的Workload Identity配置步骤。

Cross-Service Authentication Patterns

跨服务认证模式

Common patterns for granting GKE workloads access to other Google Cloud services:

bash

undefined

授予GKE工作负载访问其他Google Cloud服务的常见模式：

bash

undefined

Grant a GKE workload access to Cloud Storage

授予GKE工作负载访问Cloud Storage的权限

gcloud projects add-iam-policy-binding <PROJECT_ID>
--member "serviceAccount:<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com"
--role "roles/storage.objectViewer"
--quiet

Grant a GKE workload access to Cloud SQL

授予GKE工作负载访问Cloud SQL的权限

gcloud projects add-iam-policy-binding <PROJECT_ID>
--member "serviceAccount:<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com"
--role "roles/cloudsql.client"
--quiet

Grant a GKE workload access to Pub/Sub

授予GKE工作负载访问Pub/Sub的权限

gcloud projects add-iam-policy-binding <PROJECT_ID>
--member "serviceAccount:<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com"
--role "roles/pubsub.subscriber"
--quiet


In all cases, the GSA must be bound to a KSA via Workload Identity (see setup
above). The pod then uses the KSA to authenticate as the GSA.

gcloud projects add-iam-policy-binding <PROJECT_ID>
--member "serviceAccount:<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com"
--role "roles/pubsub.subscriber"
--quiet


在所有场景中，GSA必须通过Workload Identity绑定到KSA（请查看上方的配置步骤）。Pod随后使用KSA以GSA身份进行认证。