GKE Platform Security Hardening
Helps platform teams plan and apply cluster-level security hardening for Google Kubernetes Engine.
The skill promotes least privilege, RBAC hardening, and dedicated node service accounts, and cites official resources. However, several IAM and cluster-update commands use --quiet without explicit user confirmation, pre-change checks, data-flow disclosure, or rollback guidance, so points are deducted.
Common paths and MCP/kubectl alternatives are described, but there are no tests, version-compatibility notes, invalid-input handling, or diagnostic failure messages. The apparent unclosed final code fence may also impair parsing, so the static score remains modest.
The name, audience, and platform-level scope are clear, with an explicit exclusion for workload-level security. Inputs, outputs, trigger boundaries, regional/version prerequisites, and mainland-China environment fit are not sufficiently specified, so points are deducted.
The document has a golden-path section, topical structure, examples, and resource links; the repository README supplies Apache-2.0 licensing, installation, and issue-reporting paths. The skill itself lacks versioning, changelog, maintenance ownership, limitations, and troubleshooting guidance, and the code fencing appears incomplete.
It covers core platform-security tasks including Secret Manager, RBAC, Binary Authorization, Shielded Nodes, Sandbox, and IAM, with commands that can serve as a starting point. However, complete pre/post validation, compatibility and side-effect guidance, rollback, and representative output evidence are absent, limiting the static score.
Several official Google Cloud resources and auditable commands are provided, but there are no committed tests, CI coverage, execution records, or corroborating evidence from multiple sources. Traceability is therefore limited.
- Add explicit confirmation, permission prechecks, impact disclosure, and actionable rollback procedures before IAM or cluster changes; --quiet should not replace user authorization.
- Document GKE version, regional, and existing-cluster constraints and failure handling; fix the apparently unclosed final code fence.
- Explain sensitive-data flows, compatibility, and outage/recreation risks for Secret Manager, Workload Identity, and Sandbox, with post-change verification commands.
- No mainland-China network reachability or alternative documentation/mirror guidance is provided.
What does this skill do, and when should you use it?
This skill focuses on platform-level security configuration for Google Kubernetes Engine, not security controls inside individual workloads. It covers the Secret Manager cluster add-on, RBAC hardening, Binary Authorization, Shielded Nodes, GKE Sandbox, GKE IAM roles, service accounts, and cross-service authentication patterns. Its golden path recommends Workload Identity Federation, the GKE metadata mode, secure boot, and integrity monitoring, while disabling insecure legacy RBAC bindings. It fits teams responsible for cluster control planes, nodes, and platform permissions; workload-level Workload Identity, SecretProviderClass, network policies, and Pod Security Standards are out of scope.
Reads GKE cluster configuration and checks Secret Manager, RBAC bindings, and related security settings; provides gcloud commands for enabling Secret Manager with 120-second rotation, Binary Authorization, Shielded Nodes, and GKE Sandbox; explains GKE IAM roles, service accounts, and cross-service IAM bindings; and references gke:get_cluster, gke:update_cluster, k8s:check_k8s_auth, k8s:get_k8s_resource, and k8s:apply_k8s_manifest for cluster queries, authorization audits, resource inspection, and configuration application.
- A platform administrator needs to enable the Secret Manager add-on and automatic rotation on an existing GKE cluster.
- A cluster operator needs to disable legacy bindings for system:authenticated and system:unauthenticated.
- A security engineer needs to enable Binary Authorization on a production cluster to enforce image provenance policies.
- A platform team needs to enable Shielded Nodes or GKE Sandbox and review node-level security defaults.
- A cloud platform owner needs to choose suitable GKE IAM roles for administrators, developers, auditors, and CI/CD pipelines.
- A team needs IAM binding patterns that let Google service accounts access Cloud Storage, Cloud SQL, or Pub/Sub.
What are this skill's strengths and limitations?
- Has a clearly bounded focus on GKE cluster and platform security.
- Provides Day-0 and Day-1 golden-path defaults plus copyable gcloud examples.
- Covers configuration checks, RBAC authorization audits, IAM roles, and service-account patterns.
- Clearly separates platform-level security from workload-level security.
- Does not cover Workload Identity, SecretProviderClass, network policies, or Pod Security Standards for workloads.
- Delegates private-cluster and Dataplane V2 settings to the gke-networking skill.
- The source provides no test suite, version compatibility matrix, or failure-recovery guidance.
- Some examples modify existing clusters, so users need appropriate GKE, Kubernetes, and IAM permissions.
How do you install this skill?
Run npx skills add google/skills, then select the specific skill from the repository. The target skill is at skills/cloud/gke-platform-security/SKILL.md. The source does not document the installed local directory or client-specific configuration steps.
How do you use this skill?
After installation, ask something like: “Harden the platform security of my GKE cluster and check RBAC, Secret Manager, Shielded Nodes, and GKE IAM configuration.” For cluster operations, the skill supplies gcloud examples and references the listed GKE and Kubernetes MCP tools. The user must provide the relevant cluster name, region, project, and permissions.
How does this skill compare with similar options?
Use the source-referenced gke-workload-security skill for workload-level security controls; use gke-multitenancy for enterprise RBAC planning; and use gke-networking for private-cluster and Dataplane V2 settings.