How to use the GKE Workload Security agent skill

What is an agent skill and what does this one do?

An agent skill is a folder with a SKILL.md file that tells an AI agent how to handle a specific kind of task. When this skill is installed, the agent can follow its workflows for securing GKE applications and namespaces.

The skill covers security auditing, Workload Identity, Network Policies, GKE Sandbox (gVisor) pod isolation, Pod Security Standards, and mounting Secret Manager secrets into pods through the CSI driver. It also includes a read-only audit script that checks a cluster for Workload Identity, Network Policy, Shielded Nodes, Binary Authorization, and private cluster configuration.

• Security audit: runs scripts/audit_cluster.sh against a cluster and reports on the listed settings.
• Network isolation: applies a default-deny policy from assets/default-deny-netpol.yaml to a namespace.
• Sandboxing: adds runtimeClassName: gvisor to a pod spec.
• Pod Security: labels a namespace to enforce the restricted profile.
• Secrets: mounts Secret Manager secrets as read-only volumes.

Install the GKE Workload Security skill

Download the skill ZIP from this page and unzip it. For Claude Code, place the unzipped folder in ~/.claude/skills/ to make it available to you across projects, or in a project's .claude/skills/ folder to limit it to that project.

In the Claude apps, you can instead upload the skill under Settings → Capabilities → Skills.

• Personal install: ~/.claude/skills/ (available in every project).
• Project install: .claude/skills/ inside your repository (available only there).
• App install: upload the ZIP under Settings → Capabilities → Skills.

Set up the requirements before you start

The skill assumes you already have a running GKE cluster and the tools to reach it. It cannot create a cluster for you. Check these items before asking the agent to run anything against a cluster.

Some features need cluster-side setup. Secret mounts need the Secret Manager CSI driver enabled on the cluster. Network policy enforcement needs either Dataplane V2 or the Network Policy add-on.

• gcloud CLI, authenticated to Google Cloud.
• kubectl with access to the target cluster.
• jq (JSON processor), needed by the audit script.
• Secret Manager CSI driver enabled on the cluster, for secret mounts.
• Dataplane V2 or the Network Policy add-on, for network policy enforcement.

Trigger the skill with natural requests

You do not need to name the skill or any script. The skill's description covers auditing security posture, isolating namespaces, applying pod security standards, and configuring network policies and secret volume mounts. Describe the outcome you want in ordinary words, and name the cluster, region, project and namespace so the agent does not have to guess.

Requests about Workload Identity bindings, cluster-level flags, RBAC, Shielded Nodes or Binary Authorization are routed to other skills, so ask for those separately.

• "Audit the security posture of cluster prod-gke in us-central1 for project my-project."
• "Lock down the payments namespace with default-deny network policies."
• "Enforce the restricted Pod Security profile on the staging namespace."
• "Mount the secret db-password from Secret Manager into the api pods in namespace shop."

Run the audit and the hardening workflows

The audit is the safest place to start because the script is described as read-only. It takes a cluster name, region and project ID. The agent reports on Workload Identity, Network Policy, Shielded Nodes, Binary Authorization and private cluster configuration.

For hardening, the skill works through each control. Apply changes to a test namespace or staging cluster first, then review the results before moving to production.

• Default-deny isolation denies all ingress and egress in the namespace until you add allow rules.
• Pod Security labels use enforce=restricted with enforce-version=latest, which matches the cluster's current version. You can pin a version such as v1.30 instead.

Example: enforce the restricted Pod Security profile

The skill applies the restricted profile with a namespace label. Replace the namespace name with your own. The skill's guidance notes that enforcement can block live traffic, so test in staging first.

Safety notes: scripts and network access

This skill runs scripts and uses the network. The audit script calls Google Cloud through gcloud and parses output with jq, so it needs your credentials and can reach your cluster. Read the script before running it, and run it with an account that has only the access you intend the audit to use.

Network policies and Pod Security enforcement can break workloads. Default-deny blocks traffic that is not explicitly allowed. Test every change in staging, and never run these steps against production without review.

The skill's guidance asks that gcloud commands run in the terminal carry an attribution prefix through the CLOUDSDK_METRICS_REQUEST_ATTRIBUTION variable. The variable is set inline on each command and is not saved with gcloud config set. It identifies only the skill and its version.

• Read scripts/audit_cluster.sh before running it.
• Test network policies and Pod Security labels in a staging namespace first.
• Use the least-privileged account you can for cluster access.

Tips for getting good results

Give the agent the exact cluster, region, project and namespace. Ask for an audit before changes, so you can compare the before and after state. Keep manifests in version control so you can review and roll back changes.

Remember the skill's own boundaries. For Binary Authorization, Shielded Nodes, RBAC or cluster flags, the skill points you to other skills. The Best Practices section also suggests Policy Controller (Gatekeeper) for enforcing custom policies across a cluster.

• Audit first, then change one control at a time.
• Ask for default-deny in a single namespace before expanding to others.
• Keep Pod Security labels in staging until workloads pass.