gke-workload-security

GKE 工作负载安全

**路由说明：**对于 Workload Identity KSA/GSA 绑定，请打开 gke-workload-identity/SKILL.md。对于集群级安全标志（--database-encryption-key、--security-posture、RBAC、Shielded Nodes、Binary Authorization），请打开 gke-platform-security/SKILL.md。

此技能提供保护 GKE 工作负载安全的工作流和最佳实践。 内容涵盖安全审计、身份和访问权限管理（Workload Identity）、 网络安全（Network Policies）和节点安全。

归属信息

**必须阅读：**执行任何 gcloud、REST API 或 MCP 命令之前， 必须阅读使用归属信息。对于直接在终端中执行的命令（切勿在生成的脚本、Terraform 或用户代码中使用）， 请在 gcloud 前添加 CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:gke-workload-security)" ，并在 User-Agent 请求头中附加 agent-skills/1.0 (skill:gke-workload-security)。

工作流

1. 安全审计

使用提供的审计脚本评估集群当前的安全态势。

前提条件：

• gcloud CLI 已完成身份验证。
• 已安装 jq 命令行 JSON 处理器。

功能：

• 检查是否启用了 Workload Identity。
• 验证是否启用了 Network Policy。
• 检查是否启用了 Shielded Nodes。
• 检查是否启用了 Binary Authorization。
• 检查是否配置了 Private Cluster。

命令：

scripts/audit_cluster.sh <cluster-name> <region> <project-id>

2. 配置 Workload Identity

Workload Identity 允许 Kubernetes 服务账号（KSA）模拟 Google 服务账号（GSA）。这是工作负载访问 Google Cloud API 的 推荐方式。

步骤：

1. 创建命名空间和 KSA：

   kubectl create namespace workload-identity-test-ns
   kubectl create serviceaccount <ksa-name> \
       --namespace workload-identity-test-ns
   

2. 将 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[workload-identity-test-ns/<ksa-name>]"
   

3. 为 KSA 添加注释：

   kubectl annotate serviceaccount <ksa-name> \
       --namespace workload-identity-test-ns \
       iam.gke.io/gcp-service-account=<gsa-name>@<project-id>.iam.gserviceaccount.com
   

4. **验证示例 Pod：**使用现有资源 assets/workload-identity-pod.yaml 测试配置。先更新文件中的 <ksa-name>。

   kubectl apply -f assets/workload-identity-pod.yaml -n workload-identity-test-ns
   

3. 实施 Network Policies

使用 Network Policies 控制 Pod 之间的流量。默认情况下，所有 流量均处于允许状态。

启用 Network Policy 强制执行：

gcloud container clusters update <cluster-name> \
    --update-addons=NetworkPolicy=ENABLED \
    --region <region>

说明

如果集群使用 Dataplane V2（--enable-dataplane-v2），Network Policy 强制执行已内置，因此无需执行此步骤（执行时可能会失败）。

**应用默认拒绝策略：**默认情况下拒绝所有入站和 出站流量，以隔离命名空间。

将 <target-namespace> 替换为要隔离的命名空间。

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

4. GKE Sandbox（gVisor）Pod 隔离

在沙箱中运行不受信任的工作负载，以加强内核隔离。（注意： 在集群控制平面级别启用 Shielded Nodes（--enable-shielded-nodes）和 GKE Sandbox （--enable-gke-sandbox）属于平台级操作，相关内容请参阅 gke-platform-security 技能。）

**运行沙箱 Pod：**在 Pod 规范中添加 runtimeClassName: gvisor：

apiVersion: v1
kind: Pod
metadata:
  name: sandboxed-pod
spec:
  runtimeClassName: gvisor
  containers:
  - name: app
    image: nginx

5. Pod 安全标准

使用标签在命名空间上强制执行安全策略。

强制执行 Restricted 配置文件：

kubectl label --overwrite ns <namespace> \
    pod-security.kubernetes.io/enforce=restricted \
    pod-security.kubernetes.io/enforce-version=latest

说明

使用 latest 可确保使用与集群当前版本对应的策略。你可以将其固定为特定版本（例如 v1.30），以将命名空间限制为特定版本的策略。

6. Secret Manager 集成（CSI 驱动程序）

将 Google Cloud Secret Manager 中的密钥直接作为卷挂载到 Pod 中。

前提条件：必须在集群上启用 Secret Manager CSI 驱动程序。

SecretProviderClass 示例：

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: my-secret-provider
spec:
  provider: gcp
  parameters:
    secrets: |
      - resourceName: "projects/<project-id>/secrets/my-secret/versions/latest"
        fileName: "my-secret-file"

Pod 规范示例摘录：

spec:
  containers:
    - name: my-app
      volumeMounts:
        - name: secrets-store-inline
          mountPath: "/mnt/secrets"
          readOnly: true
  volumes:
    - name: secrets-store-inline
      csi:
        driver: secrets-store.csi.k8s.io
        readOnly: true
        volumeAttributes:
          secretProviderClass: "my-secret-provider"

7. 启用网络策略日志记录

如果使用 GKE Dataplane V2，可以记录允许和拒绝的连接。

步骤：

1. 配置 NetworkLogging 自定义资源。

NetworkLogging 清单示例：

apiVersion: networking.gke.io/v1alpha1
kind: NetworkLogging
metadata:
  name: default
spec:
  cluster:
    allow:
      log: true
      delegate: true
    deny:
      log: true
      delegate: true

这会将连接详情记录到 Cloud Logging。

最佳实践

1. 最小权限： 始终使用具有最少 IAM 角色的 Workload Identity。 避免使用节点默认服务账号。
2. 网络隔离： 使用网络策略限制 Pod 间通信。启用网络策略日志记录，以便查看相关信息。
3. 镜像安全： 使用 Binary Authorization，确保只部署可信镜像。
4. 密钥管理：对敏感数据使用 Secret Manager CSI 驱动程序，而非默认的 Kubernetes 密钥。
5. Pod 安全： 对所有非系统命名空间强制执行 baseline 或 restricted Pod 安全标准。
6. 策略强制执行： 考虑使用 Policy Controller（Gatekeeper），在整个集群中 强制执行自定义安全和合规策略。

资源

• GKE 的 Workload Identity Federation
• GKE 网络策略
• GKE 中的 Pod 安全标准
• Google Secret Manager CSI 驱动程序
• GKE Dataplane V2 网络日志记录