kubernetes-securitylisted

# Kubernetes Security A pragmatic baseline for a single Kubernetes cluster running a small-team workload. Skews toward "I have a cluster and need it to not be the cause of an incident" — not a full CIS Benchmark for regulated environments. Most managed-K8s providers ship sensible defaults at the control-plane layer; the data-plane (your workloads) is where the work is. ## When to invoke - Provisioning a new cluster - Inheriting a cluster with no documented hardening - Before adding a new tenant / team / workload to a shared cluster - After a K8s security advisory affecting your version - Periodic re-audit (quarterly) - Multi-tenant SaaS where customer workloads share infrastructure ## Step 1 — Cluster baseline Before workload hardening, the cluster itself. ```bash # What version? Is it supported? kubectl version --short # K8s has a ~14-month support window. Unsupported = unpatched CVEs. # Who can reach the API? kubectl cluster-info # For managed clusters, check the provider's "API endpoint" access setting: # - Private endpoint, restricted CIDRs, or behind a bastion is correct # - "Public, open to 0.0.0.0/0" is a finding # Audit log enabled? # For EKS/GKE/AKS: check the cluster's "audit logging" / "control-plane logging" setting # Self-hosted: --audit-log-path on the API server ``` Patterns: - **Restrict the API endpoint.** Public + open is the worst default. Use private endpoint + bastion, or public + CIDR allowlist + IAM auth at minimum. - **Enable control-plane au