Menu
Reviews Kubernetes Admission Control (Webhooks, VAP/MAP) for vulnerabilities.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Autonomously poll, triage, investigate, and resolve unaddressed open issues on our target GitHub repository strictly within authorized scope.
Configures, optimizes, and troubleshoots GKE ComputeClasses. Use when configuring Spot VMs with on-demand fallback, targeting specific accelerators (GPUs/TPUs) or machine families, restricting ComputeClass access, or debugging pending pods related to node pool auto-creation. Do not use for cluster-level Node Auto Provisioning configuration or general GKE cluster creation.
Audit, monitor, and debug the logging, tracing, metrics, and API/dashboard observability of the Platform Agent.
Standard Operating Procedure (SOP) for generating and updating secure, compliant, and cost-effective GKE manifests.
Systematic Standard Operating Procedure (SOP) for diagnosing GKE workload failures, crash loops, resource OOMs, mounting errors, and connectivity timeouts.
Reviews Kubernetes Pod security contexts for workload-level isolation and privilege escalation risks.
| name | review-security-k8s-admission |
| description | Reviews Kubernetes Admission Control (Webhooks, VAP/MAP) for vulnerabilities. |
Review Kubernetes Admission Control (ValidatingWebhookConfiguration, MutatingWebhookConfiguration, ValidatingAdmissionPolicy, MutatingAdmissionPolicy).
failurePolicy: Ignore on security webhooks as a bypass risk (DoS allows bypass). Prefer Fail.timeoutSeconds (e.g. 30s) as API connection exhaustion risks.namespaceSelector/objectSelector. Flag blanket kube-system exemptions; recommend specific label targeting.failurePolicy: Ignore for runtime errors. Prefer Fail.messageExpression hides sensitive cluster metadata.caBundle and HTTPS.NetworkPolicy restricting webhook ingress solely to the API server.reinvocationPolicy: IfNeeded should be required. This ensures, if later webhooks make mutations that earlier webhooks have an opinion on, that the earlier webhooks are run again to ensure the same policies are applied to those later mutations. In general, if certain mutations are always expected, a validating webhook should also be used to confirm the mutation was successful. Validation always runs after mutation.