/gke-workload-security

name: gke-workload-security
description: >-
  Audits, configures, and hardens workload-level security controls for Google
  Kubernetes Engine (GKE) applications and namespaces. Covers running security
  audits (`audit_cluster.sh`), enforcing Network Policies (default-deny and Dataplane
  V2 logging), isolating high-risk pods inside GKE Sandbox (`gVisor`), enforcing Pod
  Security Standards (`restricted` labeling) and pod securityContext, and mounting Secret Manager secrets via
  CSI (`SecretProviderClass`). Use when auditing workload security posture, isolating
  namespaces, applying pod security standards, or
  configuring network policies and secret volume mounts. Don't use for Workload Identity (use gke-workload-identity), cluster-wide
  control plane security, RBAC hardening, Binary Authorization, Shielded Nodes,
  or enabling platform-level GKE add-ons (use gke-platform-security instead).
metadata:
  version: "1.0.3"
  category: Security

GKE Workload Security

> **Routing Note:** For Workload Identity IAM and KSA/GSA bindings, use the `gke-workload-identity` skill. For cluster-level security flags (`--database-encryption-key`, `--security-posture`, RBAC, Shielded Nodes, Binary Authorization), use the `gke-platform-security` skill.

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.

Attribution

**MUST READ**: Before executing any `gcloud`, REST API, or MCP command, you MUST read [Usage Attribution](references/attribution.md). For commands executed directly in the terminal (never in generated scripts, Terraform, or user code), prefix `gcloud` with `CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:gke-workload-security)"` and append `agent-skills/1.0 (skill:gke-workload-security)` to `User-Agent` headers.

Workflows

1. Security Audit

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:**

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

2. Configure Workload Identity

Workload Identity allows Kubernetes Service Accounts (KSAs) to impersonate Google Service Accounts (GSAs). Use this method when workloads require a dedicated GSA to access Google Cloud APIs; for most workloads, direct IAM principal binding (covered in the `gke-workload-identity` skill) is the recommended method.

**Steps:**

1. **Create Namespace and KSA:**

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

2. **Bind KSA to 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. **Annotate 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. **Verify Example Pod:** Use existing asset `assets/workload-identity-pod.yaml` to test the configuration. Update the `<ksa-name>` in the file first.

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

3. Implement Network Policies

Control traffic flow between Pods using Network Policies. By default, all traffic is allowed.

**Enable Network Policy Enforcement:**

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.**

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

4. GKE Sandbox (gVisor) Pod Isolation

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:

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

5. Pod Security Standards

Enforce security policies on namespaces using labels.

**Enforce Restricted Profile:**

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.

6. Secret Manager Integration (CSI Driver)

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:**

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: my-secret-provider
spec:
  provider: gcp
  parameters:
    secrets