Hardening de securitate pentru Kubernetes: o listă de verificare pentru producție

Am auditat zeci de clustere Kubernetes. Tiparul e aproape mereu același: o echipă pornește un cluster managed (sau, mai rău, kubeadm cu setări implicite), își face deploy la aplicații și declară că e producție. Șase luni mai târziu, ne sună după un incident.

Kubernetes-ul implicit nu este sigur. E proiectat pentru flexibilitate, nu pentru siguranță. Iată lista de verificare pe care o urmăm pentru fiecare cluster pe care îl administrăm.

1. RBAC — nu mai folosi cluster-admin pentru orice

Cea mai frecventă greșeală pe care o vedem: fiecare service account, pipeline de CI și developer legat de cluster-admin.

# Bad: giving your CI pipeline god mode
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ci-pipeline
subjects:
  - kind: ServiceAccount
    name: ci-deployer
    namespace: ci
roleRef:
  kind: ClusterRole
  name: cluster-admin # Don't do this

În schimb, creează roluri limitate per namespace. Pipeline-ul tău de CI are nevoie doar de permisiunea de a actualiza Deployment-uri și ConfigMap-uri în namespace-urile țintă — nu de a șterge PersistentVolume-uri la nivel de cluster.

# Better: namespace-scoped, least-privilege
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ci-deployer
  namespace: production
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "patch", "update"]
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "create", "update"]

2. Network policies — default deny

În mod implicit, fiecare pod poate vorbi cu orice alt pod. Asta înseamnă că un frontend compromis poate ajunge direct la baza ta de date.

# Default deny all ingress in a namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Apoi permite explicit doar traficul de care ai nevoie. Noi folosim Cilium pentru network policies pentru că suportă filtrare L7 (metodă HTTP, path) pe lângă L3/L4.

3. Pod Security Standards

Kubernetes a marcat PodSecurityPolicy ca deprecated în v1.25 și l-a înlocuit cu Pod Security Standards (PSS), impuse prin admission controller-ul încorporat.

Cel puțin, impune profilul restricted pe namespace-urile de producție:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Asta împiedică containerele să ruleze ca root, să folosească host networking, să escaladeze privilegii sau să monteze tipuri periculoase de volume.

4. Securitatea imaginilor

• Folosește digest pinning — Tag-urile sunt mutabile. nginx:latest de azi nu e nginx:latest de mâine. Fixează la nginx@sha256:abc123...
• Scanează imaginile în CI — Noi rulăm Trivy în fiecare pipeline. Blochează deploy-urile cu CVE-uri critice
• Registry privat — Nu trage din Docker Hub în producție. Oglindește ce ai nevoie în propriul tău registry
• Admission control — Folosește un tool precum Kyverno sau OPA Gatekeeper ca să respingi imaginile din registry-uri neverificate

5. Gestionarea secretelor

Secretele Kubernetes sunt codificate base64, nu criptate. Oricine are RBAC pentru get secrets le poate citi.

Abordarea noastră:

• Criptează etcd at rest — Configurează EncryptionConfiguration cu aescbc sau secretbox
• Secrete externe — Folosește External Secrets Operator ca să sincronizezi din HashiCorp Vault, AWS Secrets Manager sau similar
• Nu comite niciodată secrete — Sealed Secrets sau SOPS pentru workflow-uri GitOps

6. Securitate la runtime

Tot ce e mai sus e preventiv. Securitatea la runtime prinde ce a scăpat:

• Falco pentru detectarea anomaliilor — alertează la execuții neașteptate de procese, accesări de fișiere, conexiuni de rețea
• Root filesystem read-only — Împiedică malware-ul să scrie în sistemul de fișiere al containerului
• Profiluri seccomp — Restricționează syscall-urile doar la ce are nevoie aplicația

7. Audit logging

Activează audit log-ul din Kubernetes. Trebuie să știi cine a făcut ce și când:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["clusterroles", "clusterrolebindings"]

Trimite audit log-urile către SIEM-ul tău. Noi folosim Loki + Grafana pentru agregare de log-uri la un cost rezonabil.

Stack-ul nostru de hardening

Nivel	Tool	Scop
Rețea	Cilium	Network policies + filtrare L7
Admission	Kyverno	Impunerea politicilor
Scanare	Trivy	Scanarea vulnerabilităților din imagini
Secrete	External Secrets + Vault	Gestionarea secretelor
Runtime	Falco	Detectarea anomaliilor
Audit	Loki + Grafana	Agregare de log-uri

Începe azi

Nu trebuie să implementezi totul deodată. Începe cu RBAC și network policies — elimină cei mai comuni vectori de atac. Apoi adaugă restul, strat cu strat.

Ai nevoie de ajutor ca să-ți auditezi clusterul? Am făcut hardening pe clustere care rulează de la workload-uri fintech la backend-uri de gaming. Contactează-ne și începem cu un review de securitate.