/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`](../sota-sandboxing/SKILL.md) ([rules/03](../sota-sandboxing/rules/03-containers-microvms.md) containers & microVMs; [rules/01](../sota-sandboxing/rules/01-isolation-boundaries.md) boundaries). This skill owns the *admission-time enforcement* of those fields, not their internals.
• **NetworkPolicy semantics, CNI choice, service mesh, mTLS** → [`sota-network-security`](../sota-network-security/SKILL.md). This skill states only the *requirement* (default-deny per namespace, enforced at admission).
• **OIDC/SSO and RBAC-role *design* methodology** → [`sota-identity-access`](../sota-identity-access/SKILL.md). This skill owns the K8s RBAC *mechanics and escalation traps*.
• **Runtime/audit-log detection content (Falco/Tetragon rules, detections)** → [`sota-detection-engineering`](../sota-detection-engineering/SKILL.md). This skill owns *producing and shipping* the audit stream.
• **Workload identity, Secret storage backends (ESO, sealed-secrets, CSI)** → [`sota-secrets-management`](../sota-secrets-management/SKILL.md) ([rules/01](../sota-secrets-management/rules/01-lifecycle-and-workload-identity.md), [rules/02](../sota-secrets-management/rules/02-storage-backends.md)). This skill owns etcd encryption-at-rest.
• **Cloud IAM, managed-K8s selection, DR** → [`sota-cloud-infrastructure`](../sota-cloud-infrastructure/SKILL.md) ([rules/02](../sota-cloud-infrastructure/rules/02-iam-design.md), [rules/04](../sota-cloud-infrastructure/rules/04-compute-selection.md), [rules/07](../sota-cloud-infrastructure/rules/07-resilience-dr.md)).
• **CI/CD provenance, image signing, IaC/GitOps pipeline, runtime ops** → [`sota-devsecops`](../sota-devsecops/SKILL.md) ([rules/02](../sota-devsecops/rules/02-provenance-signing.md), [rules/04](../sota-devsecops/rules/04-build-containers.md), [rules/06](../sota-devsecops/rules/06-iac-deployment.md), [rules/07](../sota-devsecops/rules/07-runtime-ops.md)).

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`](rules/01-control-plane-etcd.md)) — 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`](rules/03-admission-policy.md)). 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`](rules/04-gitops-controllers.md)). 6. **Plan the upgrade before you build**: version skew, EOL date, CVE-response runbook, tested etcd restore ([`rules/01`](rules/01-control-plane-etcd.md) §4, §7).

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

**Coverage:** every `rules/` file's Audit checklist applies in AUDIT mode. Mark one *not applicable* only with its reason in the report — never skip a file because the thing it checks for is absent, since that absence may be the finding.

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 po