Back to Details

gke-workload-security

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

GKE Workload Security

GKE工作负载安全

This skill provides workflows and best practices for securing GKE workloads. It covers security auditing, Identity and Access Management (Workload Identity), Network Security (Network Policies), and Node Security.
本技能提供用于保护GKE工作负载的工作流与最佳实践，涵盖安全审计、身份与访问管理（Workload Identity）、网络安全（网络策略）以及节点安全。

Workflows

工作流

1. Security Audit

1. 安全审计

Assess the current security posture of your cluster using the provided audit script.
Prerequisites:
  • gcloud
    CLI authenticated.
  • jq
    command-line JSON processor installed.
Capabilities:
  • Checks for Workload Identity.
  • Verifies Network Policy is enabled.
  • Checks if Shielded Nodes are enabled.
  • Checks if Binary Authorization is enabled.
  • Checks for Private Cluster configuration.
Command:
bash
scripts/audit_cluster.sh <cluster-name> <region> <project-id>
使用提供的审计脚本评估集群当前的安全状态。
前提条件：
  • gcloud
    CLI已完成身份验证。
  • 已安装
    jq
    命令行JSON处理器。
功能：
  • 检查Workload Identity是否启用。
  • 验证网络策略是否启用。
  • 检查受保护节点（Shielded Nodes）是否启用。
  • 检查二进制授权（Binary Authorization）是否启用。
  • 检查私有集群配置。
命令：
bash
scripts/audit_cluster.sh <cluster-name> <region> <project-id>

2. Configure Workload Identity

2. 配置Workload Identity

Workload Identity allows Kubernetes Service Accounts (KSAs) to impersonate Google Service Accounts (GSAs). This is the recommended method for workloads to access Google Cloud APIs.
Steps:
  1. Create Namespace and KSA:
    bash
    kubectl create namespace workload-identity-test-ns
kubectl create serviceaccount <ksa-name> \
    --namespace workload-identity-test-ns
  2. Bind KSA to GSA:
    bash
    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. Annotate KSA:
    bash
    kubectl annotate serviceaccount <ksa-name> \
    --namespace workload-identity-test-ns \
    iam.gke.io/gcp-service-account=<gsa-name>@<project-id>.iam.gserviceaccount.com
  4. Verify Example Pod: Use existing asset 
    assets/workload-identity-pod.yaml
    to test the configuration. Update the 
    <ksa-name>
    in the file first.
    bash
    kubectl apply -f assets/workload-identity-pod.yaml -n workload-identity-test-ns
Workload Identity允许Kubernetes服务账户（KSA）模拟Google服务账户（GSA），这是工作负载访问Google Cloud API的推荐方式。
步骤：
  1. 创建命名空间与KSA：
    bash
    kubectl create namespace workload-identity-test-ns
kubectl create serviceaccount <ksa-name> \
    --namespace workload-identity-test-ns
  2. 绑定KSA与GSA：
    bash
    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添加注解：
    bash
    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>
    。
    bash
    kubectl apply -f assets/workload-identity-pod.yaml -n workload-identity-test-ns

3. Implement Network Policies

3. 实施网络策略

Control traffic flow between Pods using Network Policies. By default, all traffic is allowed.
Enable Network Policy Enforcement:
bash
gcloud container clusters update <cluster-name> \
    --update-addons=NetworkPolicy=ENABLED \
    --region <region>
[!NOTE] If your cluster uses Dataplane V2 (
--enable-dataplane-v2
), Network Policy enforcement is built-in and this step is not required (and may fail).
Apply Default Deny Policy: Isolate namespaces by denying all ingress and egress traffic by default.
Replace 
<target-namespace>
with the namespace you want to isolate.
bash
kubectl apply -f assets/default-deny-netpol.yaml -n <target-namespace>
使用网络策略控制Pod之间的流量。默认情况下，所有流量均被允许。
启用网络策略强制实施：
bash
gcloud container clusters update <cluster-name> \
    --update-addons=NetworkPolicy=ENABLED \
    --region <region>
[!NOTE] 如果您的集群使用Dataplane V2（
--enable-dataplane-v2
），网络策略强制实施已内置，此步骤无需执行（执行可能失败）。
应用默认拒绝策略： 通过默认拒绝所有入口和出口流量来隔离命名空间。
将
<target-namespace>
替换为您要隔离的命名空间。
bash
kubectl apply -f assets/default-deny-netpol.yaml -n <target-namespace>

4. GKE Sandbox (gVisor) Pod Isolation

4. GKE沙箱（gVisor）Pod隔离

Run untrusted workloads in a sandbox for extra kernel isolation. (Note: Enabling Shielded Nodes (
--enable-shielded-nodes
) and GKE Sandbox (
--enable-gke-sandbox
) at the cluster control plane level are platform-level actions covered in the 
gke-platform-security
skill.)
Run a Sandboxed Pod: Add 
runtimeClassName: gvisor
to your Pod spec:
yaml
apiVersion: v1
kind: Pod
metadata:
  name: sandboxed-pod
spec:
  runtimeClassName: gvisor
  containers:
  - name: app
    image: nginx
在沙箱中运行不受信任的工作负载，以获得额外的内核隔离。（注意：在集群控制平面级别启用受保护节点（
--enable-shielded-nodes
）和GKE沙箱（
--enable-gke-sandbox
）属于平台级操作，由
gke-platform-security
技能覆盖。）
运行沙箱化Pod： 在Pod规格中添加
runtimeClassName: gvisor
：
yaml
apiVersion: v1
kind: Pod
metadata:
  name: sandboxed-pod
spec:
  runtimeClassName: gvisor
  containers:
  - name: app
    image: nginx

5. Pod Security Standards

5. Pod安全标准

Enforce security policies on namespaces using labels.
Enforce Restricted Profile:
bash
kubectl label --overwrite ns <namespace> \
    pod-security.kubernetes.io/enforce=restricted \
    pod-security.kubernetes.io/enforce-version=latest
[!NOTE] Using 
latest
ensures you use the policies corresponding to the cluster's current version. You can pin it to a specific version (e.g., 
v1.30
) to lock down the namespace to policies of a specific release.
使用标签对命名空间强制实施安全策略。
强制实施Restricted配置文件：
bash
kubectl label --overwrite ns <namespace> \
    pod-security.kubernetes.io/enforce=restricted \
    pod-security.kubernetes.io/enforce-version=latest
[!NOTE] 使用
latest
确保您使用与集群当前版本对应的策略。您也可以将其固定到特定版本（例如
v1.30
），以将命名空间锁定到特定版本的策略。

6. Secret Manager Integration (CSI Driver)

6. Secret Manager集成（CSI驱动）

Mount secrets from Google Cloud Secret Manager directly as volumes in your pods.
Prerequisites: Secret Manager CSI driver must be enabled on the cluster.
Example SecretProviderClass:
yaml
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"
Example Pod Spec excerpt:
yaml
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"
将Google Cloud Secret Manager中的密钥直接作为卷挂载到Pod中。
前提条件：集群上必须已启用Secret Manager CSI驱动。
示例SecretProviderClass：
yaml
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规格片段：
yaml
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. Enable Network Policy Logging

7. 启用网络策略日志

If using GKE Dataplane V2, you can log allowed and denied connections.
Steps:
  1. Configure the 
    NetworkLogging
    custom resource.
Example NetworkLogging Manifest:
yaml
apiVersion: networking.gke.io/v1alpha1
kind: NetworkLogging
metadata:
  name: default
spec:
  cluster:
    allow:
      log: true
      delegate: true
    deny:
      log: true
      delegate: true
This will log connection details to Cloud Logging.
如果使用GKE Dataplane V2，您可以记录允许和拒绝的连接。
步骤：
  1. 配置
    NetworkLogging
    自定义资源。
示例NetworkLogging清单：
yaml
apiVersion: networking.gke.io/v1alpha1
kind: NetworkLogging
metadata:
  name: default
spec:
  cluster:
    allow:
      log: true
      delegate: true
    deny:
      log: true
      delegate: true
这会将连接详情记录到Cloud Logging中。

Best Practices

最佳实践

  1. Least Privilege: Always use Workload Identity with minimal IAM roles. Avoid using Node default service accounts.
  2. Network Isolation: Use Network Policies to restrict Pod-to-Pod communication. Enable Network Policy Logging for visibility.
  3. Image Security: Use Binary Authorization to ensure only trusted images are deployed.
  4. Secret Management: Use Secret Manager CSI driver instead of default Kubernetes secrets for sensitive data.
  5. Pod Security: Enforce 
    baseline
    or 
    restricted
    Pod Security Standards on all non-system namespaces.
  6. Policy Enforcement: Consider using Policy Controller (Gatekeeper) to enforce custom security and compliance policies across the cluster.
  1. 最小权限原则： 始终使用具有最小IAM角色的Workload Identity，避免使用节点默认服务账户。
  2. 网络隔离： 使用网络策略限制Pod间通信，启用网络策略日志以提高可见性。
  3. 镜像安全： 使用二进制授权确保仅部署可信镜像。
  4. 密钥管理： 对于敏感数据，使用Secret Manager CSI驱动而非默认Kubernetes密钥。
  5. Pod安全： 在所有非系统命名空间上强制实施
    baseline
    或
    restricted
    级别的Pod安全标准。
  6. 策略强制实施： 考虑使用**Policy Controller（Gatekeeper）**在集群范围内强制实施自定义安全与合规策略。

Resources

资源