/sota-kubernetes

name: sota-kubernetes
description: >-
  State-of-the-art Kubernetes platform security and operations (2026) for
  cloud-managed (EKS/GKE/AKS) and self-hosted clusters (kubeadm, k3s/k0s,
  Talos). Use when building, operating, hardening, or auditing the cluster
  PLATFORM layer: control plane and etcd, API server/kubelet, RBAC, admission
  control and policy-as-code, GitOps controllers, operators/CRDs/admission
  webhooks, Helm/Kustomize supply chain, multi-tenancy, cluster
  lifecycle/upgrades/CVE response, and audit logging. Trigger keywords:
  Kubernetes, k8s, cluster, control plane, etcd, kube-apiserver, kubelet,
  RBAC, ClusterRole, ServiceAccount, admission controller, Pod Security
  Admission, PSA, Kyverno, Gatekeeper, OPA, ValidatingAdmissionPolicy, Argo
  CD, Flux, GitOps, operator, CRD, admission webhook, Helm, Kustomize,
  multi-tenancy, vCluster, Talos, k3s, k0s, kubeadm, EKS, GKE, AKS, CIS
  benchmark, kube-bench, audit log, version skew. NOT pod-level
  securityContext/seccomp (sota-sandboxing) or NetworkPolicy/CNI depth
  (sota-network-security).

SOTA Kubernetes Platform Security & Operations

Purpose

Engineer and audit the Kubernetes **platform** so that a compromised workload, a hostile chart, a leaked token, or a malicious controller cannot pivot to cluster-admin, read every Secret, or take the cluster down. This skill owns the layer above the pod: control plane and etcd, API server and kubelet hardening, RBAC and ServiceAccount identity, admission control and policy-as-code, GitOps controllers, operators/CRDs and admission webhooks, Helm/Kustomize at admission, multi-tenancy boundaries, cluster lifecycle, and K8s audit logging.

It does **not** re-teach pod isolation mechanics. Boundaries it defers:

• **Pod `securityContext`, seccomp, AppArmor, capabilities, PSA pod-level fields** → `sota-sandboxing` (rules/03 containers & microVMs; rules/01 boundaries). This skill owns the *admission-time enforcement* of those fields, not their internals.
• **NetworkPolicy semantics, CNI choice, service mesh, mTLS** → `sota-network-security`. This skill states only the *requirement* (default-deny per namespace, enforced at admission).
• **OIDC/SSO and RBAC-role *design* methodology** → `sota-identity-access`. This skill owns the K8s RBAC *mechanics and escalation traps*.
• **Runtime/audit-log detection content (Falco/Tetragon rules, detections)** → `sota-detection-engineering`. This skill owns *producing and shipping* the audit stream.
• **Workload identity, Secret storage backends (ESO, sealed-secrets, CSI)** → `sota-secrets-management` (rules/01, rules/02). This skill owns etcd encryption-at-rest.
• **Cloud IAM, managed-K8s selection, DR** → `sota-cloud-infrastructure` (rules/02, rules/04, rules/07).
• **CI/CD provenance, image signing, IaC/GitOps pipeline, runtime ops** → `sota-devsecops` (rules/02, rules/04, rules/06, rules/07).

Two modes. Pick one explicitly at the start of the task.

---

BUILD mode

Use when provisioning a cluster, writing RBAC/policies/manifests, configuring a GitOps controller, or installing an operator/chart.

1. **Name the cluster topology first**: managed (EKS/GKE/AKS) vs self-hosted (kubeadm, k3s/k0s, Talos), single- vs multi-tenant, who the threat actors are (workload → control plane? tenant → tenant? compromised CI → cluster?). Read the matching rules. 2. **Least privilege by default**: no wildcard RBAC verbs/resources, `automountService AccountToken: false` unless the pod calls the API, scoped AppProjects, operators get the narrowest RBAC that works. Loosen only with a comment stating why. 3. **Encrypt etcd at rest with a KMS provider** (`rules/01`) — Secrets are base64, not encrypted, by default. This is the single most common "we thought we were covered" gap. 4. **Admission is fail-closed and ENFORCING, not auditing.** A policy left in `audit`/ `warn` forever is documentation, not a control (`rules/03`). Ship the AUDIT→ENFORCE rollout plan with the policy. 5. **GitOps is the only write path to the cluster.** Humans propose via PR; the controller reconciles. Scope the controller's own privileges and AppProjects tightly (`rules/04`). 6. **Plan the upgrade before you build**: version skew, EOL date, CVE-response runbook, tested etcd restore (`rules/01`, `rules/07`).

Deliverables: topology + threat statement, the concrete manifests/configs, the AUDIT→ENFORCE rollout, and the residual-risk/assumptions list (cloud-managed control plane internals you cannot see, org IAM, CNI behavior).

AUDIT mode

Use when reviewing an existing cluster, its RBAC, policies, GitOps config, or operators.

Procedure: inventory the cluster surface (control plane flags or managed equivalent, RBAC graph, admission policies, GitOps controllers, operators/CRDs, namespaces/tenancy); for each, walk the relevant rules-file Audit checklist; verify empirically with `kubectl`, `kubectl auth can-i`, rbac-tool/krane, kube-bench, and `helm template` where possible; report findings in the format below. Do not report style nits as security findings.

Severity conventions

| Severity | Meaning | Examples | |---|---|---| | **Critical** | Cluster-admin, all-Secrets read, or cluster takedown reachable now | `anonymous-auth` enabled on API server/kubelet; etcd unencrypted AND reachable; ClusterRoleBinding granting `cluster-admin` to a workload SA or `system:authenticated`; wildcard `*/*` ClusterRole bound broadly; Argo CD AppProject `clusterResourceWhitelist: [{group: '*', kind: '*'}]` with broad SSO; unpatched control plane on a known-RCE CVE | | **High** | Escalation/secret-read by an in-cluster or contributor principal, or a single event from it | `escalate`/`bind`/`impersonate` verbs granted; secret-reader → token-mint → privilege chain; admission policy in `audit` mode for a control that should enforce; image-verification policy only `Audit`s signatures; operator with cluster-wide `secrets:*`; kubelet `read-only-port` open; no etcd backu