Bastionatge de Kubernetes: tancar el clúster sense trencar el que funciona
Un clúster amb els permisos justos, la xarxa segmentada i les imatges sota control, amb cada canvi al repositori i aplicat per fases.
Eines habituals
- Kubernetes
- Hetzner
- Vault
- Flux
- Tailscale
- Helm
- k3s
En resum
Bastionar un clúster de Kubernetes és reduir el que un atacant o un error poden fer-hi dins. Revisem i tanquem els permisos RBAC, les polítiques de xarxa, els estàndards de seguretat dels pods, l'origen de les imatges, els secrets, l'accés a l'API i el registre d'auditoria. Cada canvi va al repositori i s'aplica per fases, primer en mode avís.
- Idiomes
- Castellà, català o anglés
- Resposta
- El següent dia feiner, en horari laboral
- Mètode
- Al vostre compte i al vostre repositori, en codi i documentat
Què inclou
- Revisió del clúster davant de les recomanacions de seguretat de Kubernetes i els CIS Benchmarks.
- RBAC amb permisos mínims per equip i per aplicació, sense comptes d'administració compartits.
- Polítiques de xarxa: denegar per defecte i obrir només el necessari.
- Estàndards de seguretat de pods (Pod Security Standards) per espai de noms.
- Control d'imatges: registres permesos, escaneig i versions fixades.
- Secrets xifrats i fora del repositori.
- Accés a l'API restringit i registre d'auditoria activat.
- Tot en codi, amb informe de l'abans i el després.
Per què bastionar el clúster?
Un clúster acabat de crear funciona, però no està pensat per a limitar danys. El que trobem habitualment quan el revisem:
- Tot l’equip hi entra amb el mateix usuari d’administració del clúster.
- Qualsevol pod pot parlar amb qualsevol altre, inclosa la base de dades.
- Hi ha contenidors que s’executen com a root o amb privilegis que no necessiten.
- Les imatges vénen de qualsevol registre i amb l’etiqueta latest.
- Els secrets són al repositori en base64, que no és xifratge.
- Ningú no sap qui va esborrar aquell desplegament dimarts perquè no hi ha registre d’auditoria.
Quins controls apliquem i en quin ordre?
L’ordre importa: primer el que redueix més risc amb menys impacte en el dia a dia de l’equip.
| Control | Risc que cobreix | Com s’aplica | Impacte en l’equip |
|---|---|---|---|
| RBAC per equip i aplicació | Un error o una credencial robada amb permisos totals | Rols per espai de noms i accés amb identitat nominal | Baix, cada persona veu el que és seu |
| Registre d’auditoria | No saber qui va fer què | Activat i enviat als logs centrals | Cap |
| Polítiques de xarxa | Moviment lateral dins del clúster | Denegar per defecte i obrir per servei | Mitjà, es revisa en mode avís |
| Seguretat de pods | Contenidors amb privilegis o com a root | Pod Security Standards per espai de noms | Mitjà, algunes imatges s’ajusten |
| Control d’imatges | Imatges d’origen desconegut o amb errors | Registres permesos, escaneig i versions fixes | Baix, si el CI ja construeix les imatges |
| Secrets | Credencials llegibles al repositori | Xifratge amb Sealed Secrets, SOPS o Vault | Baix, canvia el flux d’alta de secrets |
L’accés a l’API del clúster també compta: en lloc de deixar-la oberta a internet, la posem darrere d’una xarxa privada amb NetBird o Tailscale, amb accés nominal per persona.
Com es treballa?
Revisió
Estat actual davant de les recomanacions de seguretat i els CIS Benchmarks, amb la llista de troballes.
Pla per fases
Quin control va primer, què pot trencar i com es comprova.
Mode avís
Les polítiques es despleguen sense bloquejar, per a veure què afectaria.
Activació
S’ajusta el necessari i s’activen, fase a fase, des del repositori.
Informe
L’abans i el després, i el que queda pendent per decisió vostra.
I després del bastionatge?
Un clúster bastionat deixa de ser-ho si ningú no el vigila: arriben versions noves, aplicacions noves i excepcions «temporals». Si voleu, el mantenim dins de l’SRE com a servei, amb les actualitzacions de versió del clúster i la revisió d’excepcions a l’informe mensual. El manteniment complet del clúster l’expliquem a Kubernetes gestionat, i el cas de Hetzner, sense pla de control gestionat, a Kubernetes a Hetzner.
Quina experiència tenim?
Treballem amb Kubernetes i Helm en plataformes en producció, en proveïdors gestionats i en clústers propis, amb més de deu anys d’experiència com a SRE i DevOps. També hem muntat bases segures al núvol i hem gestionat secrets amb HashiCorp Vault. El nostre criteri: la seguretat que l’equip no entén acaba desactivada, així que cada control va explicat.
Preguntes freqüents
Es trencarà alguna cosa?
El risc es controla aplicant per fases: primer les polítiques en mode avís, es revisa què bloquejarien, s'ajusten i només després s'activen. Cada fase es pot revertir des del repositori.
Serveix per a un clúster gestionat com EKS, GKE o AKS?
Sí. En els gestionats el proveïdor s'ocupa del pla de control, però els permisos, la xarxa, els pods, les imatges i els secrets continuen sent cosa vostra. En k3s o clústers propis revisem també els nodes i el pla de control.
Quines eines feu servir per a les polítiques?
El que ja porte Kubernetes sempre que n'hi haja prou, com Pod Security Admission i NetworkPolicy. Si cal més, Kyverno o OPA Gatekeeper per a regles pròpies. Triem l'opció amb menys peces que cobrisca el necessari.
Expliqueu-nos el vostre cas
En una trucada gratuïta de 20 minuts veiem on sou i per on començar. Sense compromís.
Revisat el