gke-workload-security

The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.

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

# GKE Workload Security

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.

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

```bash
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). 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
    ```

### 3. Implement Network Policies

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>
```

### 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
act