En tancar el mòdul 7 vam deixar la plataforma Rutas Norte completament observable: sondes que detecten un procés malalt, mètriques a Prometheus, quadres de comandament a Grafana, alertes encaminades per Alertmanager i tots els logs centralitzats a Elasticsearch. Veiem absolutament tot el que passa. I tanmateix, ara mateix, qualsevol que tingui accés al clúster pot llegir el Secret amb les credencials de postgres-reserves —la base de dades que guarda el nom, el DNI, el telèfon i el correu de cada client que ha comprat un bitllet—, pot desplegar un contenidor privilegiat que s'escapi al node, o pot pujar una imatge que ningú ha revisat. I no sabríem qui ho va fer.

Aquest mòdul sencer es dedica a tancar aquestes portes. I la primera, la més important, és aquesta: decidir qui pot fer què. A Kubernetes això s'anomena RBAC (Role-Based Access Control, control d'accés basat en rols) i és el mecanisme que converteix un clúster on tothom pot fer-ho tot en un clúster on cada persona i cada procés té exactament els permisos que necessita i ni un més.

Al mòdul 3 vam deixar dos fils solts que ara recollim. En parlar de Secrets vam dir que qui pot llegir un secret ho decideix RBAC. En parlar de ServiceAccounts vam dir que la ServiceAccount respon a qui ets i RBAC a què pots fer, i vam veure un 403 Forbidden que demostrava que Kubernetes denega per defecte. Aquesta lliçó explica exactament per què va passar aquell 403 i com es concedeix, amb precisió quirúrgica, només l'imprescindible.

Advertiment important. Aquesta lliçó ensenya els mecanismes de RBAC i proposa un disseny d'exemple per a una empresa fictícia. El disseny real de permisos d'un clúster de producció l'ha de revisar un professional de seguretat, i si el clúster tracta dades personals —com és el cas de postgres-reserves— també el responsable de compliment normatiu de l'organització. Un error de permisos no es nota fins que algú l'aprofita.

1. Les tres portes: autenticació, autorització i admissió
2. Els subjectes: usuaris, grups i ServiceAccounts
3. Els quatre objectes de RBAC
4. Anatomia d'una regla: apiGroups, resources, verbs i resourceNames
5. Subrecursos: el poder ocult de pods/exec i pods/log
6. Els rols per defecte i els rols agregats
7. Verificar permisos amb kubectl auth can-i
8. El disseny de RBAC de Rutas Norte
9. Per què list sobre secrets equival a llegir-los
10. Escalada de privilegis i les proteccions de Kubernetes
11. Auditoria i revisió periòdica de permisos
12. Errors comuns i consells
13. Exercicis
14. Conclusió

Tot a Kubernetes passa per l'apiserver. Quan escrius kubectl get pods, quan el kubelet informa de l'estat d'un node, quan el controlador de Deployments crea un ReplicaSet, quan informes-ocupacio consulta la llista de pods: tot són peticions HTTP a la mateixa API. I tota petició travessa tres portes abans d'arribar a etcd.

Anem porta per porta.

Respon a qui ets?. L'apiserver examina les credencials que acompanyen la petició i produeix una identitat: un nom d'usuari, una llista de grups i, opcionalment, uns atributs extra. Els mecanismes habituals són:

Si cap funciona, la petició es queda a system:anonymous i normalment es rebutja amb 401 Unauthorized.

Respon a pots fer això?. L'apiserver pren la identitat de la porta anterior i el detall de la petició (verb, grup d'API, recurs, namespace, nom) i consulta els autoritzadors configurats. RBAC és l'autoritzador que fa servir pràcticament tothom, tot i que n'existeixen d'altres (Node, ABAC, Webhook, AlwaysAllow). Si cap autoritzador diu "sí", la resposta és 403 Forbidden. No hi ha permís implícit: Kubernetes denega per defecte. Aquell va ser exactament el 403 que vam veure a 03-06.

Un detall essencial: RBAC només concedeix, mai denega. No existeixen regles de denegació. El permís efectiu d'un subjecte és la unió de tot el que li concedeixen tots els seus bindings. Per això treure un permís vol dir treure el binding que l'atorga, no afegir una regla que el prohibeixi.

Respon a aquest objecte és acceptable tal com ve?. Aquí actuen els controladors d'admissió mutants (que poden modificar l'objecte, com el que injecta la ServiceAccount per defecte) i els validants (que només accepten o rebutgen). És on viuen les ResourceQuota del mòdul 3, el Pod Security Admission i les polítiques de Kyverno.

Aquesta tercera porta és el tema de 08-03; aquí només l'anomenem perquè vegis on encaixa RBAC. Recorda la diferència clau:

RBAC decideix si tens dret a fer l'operació. L'admissió decideix si l'objecte que envies compleix les normes. Pots tenir permís per crear pods (RBAC diu sí) i tot i així veure rebutjat un pod privilegiat (l'admissió diu no).

RBAC concedeix permisos a subjectes. N'hi ha exactament tres tipus.

Aquí ve la sorpresa que confon gairebé tothom en començar:

Kubernetes no emmagatzema usuaris. No existeix un objecte User. No pots fer kubectl create user anna. No hi ha cap base de dades de persones dins del clúster.

Un usuari és simplement una cadena de text que produeix l'autenticador. Si t'autentiques amb un certificat el CN del qual és anna.garcia, per a RBAC ets l'usuari anna.garcia. Si t'autentiques amb OIDC i el proveïdor retorna l'email [email protected], aquest serà el teu nom d'usuari. El clúster confia en l'autenticador i prou.

La conseqüència pràctica és important: donar d'alta i de baixa persones és responsabilitat del proveïdor d'identitat, no de Kubernetes. Si l'Anna deixa l'empresa i només esborres el seu RoleBinding, però el seu certificat continua sent vàlid i li quedaven permisos per un altre binding de grup, continua entrant.

Igual que els usuaris: són cadenes que produeix l'autenticador. Amb un certificat X.509, cada camp O (organització) es converteix en un grup. Amb OIDC, sol configurar-se un claim com ara groups.

Gairebé sempre has de concedir permisos a grups, no a usuaris. Si Rutas Norte contracta algú nou a l'equip de plataforma, l'afegeixes al grup plataforma al proveïdor d'identitat i ja té els permisos. No cal tocar ni un sol YAML del clúster.

Kubernetes reserva alguns grups amb significat propi:

Compte extrem amb system:masters. L'apiserver li concedeix permís total abans de consultar RBAC, així que no es pot limitar ni revocar amb un manifest. És la identitat del kubeconfig d'administrador que genera kubeadm. Aquest fitxer s'ha de custodiar com una clau mestra: guardat fora del portàtil de ningú, amb accés registrat, i utilitzat només per recuperar el clúster quan RBAC està trencat.

Són les identitats dels processos que corren al clúster, i sí que són objectes reals de Kubernetes (els vam crear a 03-06). A RBAC es referencien de dues maneres equivalents:

Resum comparatiu:

RBAC té només quatre tipus d'objecte, i tots viuen al grup d'API rbac.authorization.k8s.io/v1. La idea és d'una simetria molt neta:

• Role i ClusterRole descriuen què es pot fer. Són llistes de permisos, i no esmenten ningú.
• RoleBinding i ClusterRoleBinding descriuen qui ho pot fer. Uneixen uns subjectes amb un rol.

Fixa-t'hi bé perquè aquí hi ha el 90 % de la confusió amb RBAC:

La segona fila és la que sorprèn i alhora la més útil. Un ClusterRole no concedeix res per si sol: és només una plantilla de permisos. Quan el referencies des d'un RoleBinding, les seves regles s'apliquen únicament dins del namespace d'aquell binding. Això permet escriure el rol una vegada i reutilitzar-lo en molts namespaces.

Amb aquests dos manifests, el grup suport pot llistar pods a rutas-norte-pro i enlloc més. Si demà volguéssim donar-li també lectura a rutas-norte-pre, n'hi hauria prou amb un altre RoleBinding idèntic canviant el namespace: el ClusterRole no es toca.

Hi ha recursos que no pertanyen a cap namespace: Node, PersistentVolume, StorageClass, Namespace, ClusterRole, CustomResourceDefinition... Per concedir permisos sobre ells és obligatori un ClusterRole referenciat des d'un ClusterRoleBinding. Un RoleBinding mai no pot donar accés a un recurs global, per molt que el ClusterRole l'esmenti.

Un detall de roleRef que convé saber: és immutable. No pots canviar a quin rol apunta un binding ja creat; cal esborrar-lo i tornar-lo a crear. La llista de subjects, en canvi, sí que es pot modificar.

Una regla de RBAC és la intersecció de quatre dimensions. Totes han de coincidir perquè el permís s'apliqui.

Cada recurs de Kubernetes pertany a un grup d'API. El grup del nucli (core, també anomenat legacy) és històric i es representa amb la cadena buida "", no amb core. Allà viuen Pods, Services, ConfigMaps, Secrets, ServiceAccounts, Nodes, PersistentVolumeClaims i Namespaces.

Escriure apiGroups: ["core"] és un error silenciós molt freqüent: no falla en aplicar el manifest, simplement no concedeix res perquè no existeix cap grup anomenat core.

Per esbrinar el grup i el nom plural exacte de qualsevol recurs:

Quan APIVERSION és només v1 (sense barra), el grup és el buit "". Quan és apps/v1, el grup és apps. La columna NAMESPACED et diu si necessites Role o forçosament ClusterRole.

En una regla s'utilitza sempre el nom plural en minúscules de la columna NAME, mai el KIND ni el nom curt. resources: ["Pod"] o resources: ["po"] no concedeixen res.

I tres verbs especials que no corresponen a una operació normal:

Els tres són, a la pràctica, vies d'escalada de privilegis. Hi tornarem a l'apartat 10.

Un avís important sobre deletecollection: molta gent el passa per alt en construir un rol de "poder esborrar coses concretes". Si concedeixes delete amb resourceNames però també deletecollection sense restricció, has obert la porta a esborrar-ho tot, perquè resourceNames no s'aplica a les operacions de col·lecció.

Permet acotar una regla a objectes amb noms concrets:

Amb aquest rol es pot fer kubectl get configmap botiga-web-config però no kubectl get configmap qualsevol-altre.

La limitació fonamental de resourceNames. No funciona amb list, watch, create ni deletecollection. La raó és senzilla: quan demanes una llista, encara no saps quins objectes hi ha, així que l'autoritzador no pot filtrar per nom —només pot permetre o denegar la petició sencera—. RBAC no és un filtre de contingut.

Conseqüència pràctica: resourceNames restringeix la lectura individual, però no impedeix un llistat si has concedit list. Si la teva intenció és "que només pugui veure aquest ConfigMap", has de concedir get amb resourceNames i no concedir list. La contrapartida és que kubectl get configmaps (sense nom) fallarà amb un 403, cosa que desconcerta els usuaris; cal documentar-ho.

Fins i tot amb aquesta limitació, resourceNames és molt valuós en un cas concret: donar a un procés permís per actualitzar exactament un objecte. El farem servir amb ci-rutasnorte.

Alguns recursos tenen subrecursos: rutes filles de l'API amb el seu propi control d'accés. S'escriuen amb una barra al camp resources.

El punt clau que s'oblida constantment:

get pods i get pods/log són permisos diferents. Poder veure que un pod existeix no dona dret a llegir-ne els logs. I pods/exec no el concedeix el verb get sobre pods: cal anomenar-lo explícitament. Això és una bona notícia, perquè permet donar visibilitat sense donar accés.

Exemple directament aplicable a Rutas Norte: l'equip de suport necessita veure si un pod ha caigut i llegir-ne els logs per respondre a un client que diu que no li arriba el correu de confirmació. No necessita entrar al contenidor.

Fixa't en el que no hi és. Un rol de seguretat es jutja tant pel que omet com pel que inclou. Si suport tingués pods/exec sobre api-reserves, podria obrir una shell, llegir les variables d'entorn del procés i obtenir la cadena de connexió a la base de dades de clients. El límit entre "veure l'estat" i "llegir dades personals" és exactament aquella línia del YAML.

I compte amb pods/log fins i tot així: a 07-05 vam prohibir explícitament registrar dades personals als logs precisament perquè un permís de lectura de logs és molt més fàcil de concedir que un de lectura de base de dades. Les dues decisions es reforcen.

Tot clúster ve amb desenes de ClusterRole predefinits. Molts són interns (system:kube-scheduler, system:node...), però quatre estan pensats per a persones:

Dos matisos que decideixen dissenys sencers:

1. edit pot llegir Secrets. Molta gent concedeix edit a producció pensant "és que només edita, no administra", i amb això ha lliurat les credencials de la base de dades de clients. Si això t'importa —i a Rutas Norte ens importa molt—, no pots fer servir edit tal qual a rutas-norte-pro.
2. view no veu Secrets (va ser una decisió explícita del projecte), però sí que veu ConfigMaps. Això reforça el que vam dir a 03-01 i 03-02: les dades sensibles van en Secrets, mai en ConfigMaps, encara que "només sigui una cadena de connexió sense contrasenya".

Comprovar què fa exactament un rol abans de fer-lo servir és un hàbit obligatori:

Alguns rols per defecte no tenen regles pròpies: es componen automàticament amb les regles de tots els ClusterRole que porten certes etiquetes. Això és la aggregationRule.

El controlador d'agregació vigila els ClusterRole amb aquella etiqueta i copia les seves regles dins de view. Això és enormement útil quan instal·les CRDs: pots fer que qui té view vegi també els teus recursos personalitzats sense editar el rol view (que se sobreescriuria en cada actualització del clúster).

Exemple real per a Rutas Norte: al mòdul 7 vam instal·lar l'operador de Prometheus, que aporta ServiceMonitor i PrometheusRule. Volem que suport i desenvolupament els puguin veure.

En aplicar-lo, qualsevol que tingui view a qualsevol namespace passa a veure els ServiceMonitor d'aquell namespace, sense tocar cap binding. Fixa't en la jerarquia: admin agrega el d'edit, i edit agrega el de view, així que si només poses aggregate-to-view, tots tres l'hereten igualment. Posar-les totes tres és explícit i no fa cap mal.

Escriure RBAC sense verificar-lo és com escriure tests sense executar-los. kubectl auth can-i respon a la pregunta exacta que l'apiserver es fa.

El veritablement potent és --as i --as-group, que pregunten en nom d'una altra identitat (això utilitza el mecanisme d'impersonation, així que necessites el verb impersonate o ser administrador):

També es poden verificar ServiceAccounts, que és com s'auditen els permisos dels processos:

I una vista completa de tot el que pot fer un subjecte en un namespace:

Aquesta sortida és exactament el "full de permisos" que cal revisar en cada auditoria. Si hi apareix res que no esperaves, tens un binding de més.

Estable des de 1.28, respon a "qui es pensa el clúster que soc?". És l'eina per diagnosticar problemes d'autenticació, que es confonen constantment amb problemes d'autorització.

Un patró de diagnòstic útil:

Un guió de verificació que val la pena guardar al repositori al costat dels manifests, per executar-lo després de cada canvi de RBAC:

Executar aquest guió en cada canvi converteix el RBAC en una cosa verificable. Sense ell, un roleRef mal copiat pot passar mesos inadvertit.

Ara apliquem tot això als quatre col·lectius de l'empresa i a les ServiceAccounts dels processos. El principi rector és el de mínim privilegi: cada subjecte rep el just per a la seva feina.

Resum del disseny:

A rutas-norte-dev necessiten treballar amb llibertat. Fem servir el ClusterRole edit acotat amb un RoleBinding:

És acceptable perquè a rutas-norte-dev no hi ha dades reals de clients: només dades sintètiques generades per a proves. Aquesta afirmació és una decisió de disseny que ha d'estar documentada i verificada, no una suposició. Si algun dia algú copiés un abocament de producció a desenvolupament, aquest binding passaria a ser un incident greu. És exactament el tipus de regla que el responsable de compliment ha de conèixer.

A rutas-norte-pro el plantejament canvia completament. Els desenvolupadors necessiten investigar —veure l'estat, llegir logs, consultar esdeveniments— però no tocar res ni llegir credencials.

I el mateix ClusterRole, més el permís de logs, es reutilitza a rutas-norte-pre sense escriure regles noves. Aquest és l'avantatge de la combinació RoleBinding → ClusterRole.

Administra els tres namespaces. Podríem donar-los cluster-admin, però és excessiu i fa impossible distingir al registre d'auditoria (08-06) una operació rutinària d'una d'anòmala. Preferim admin per namespace més un ClusterRole de lectura d'infraestructura:

cluster-admin queda reservat per a un procediment d'emergència amb accés registrat i aprovació prèvia. En moltes organitzacions això s'implementa amb accés temporal (just-in-time): un sistema extern crea el ClusterRoleBinding, avisa per un canal públic i l'esborra automàticament al cap de dues hores.

Ja vam escriure el seu ClusterRole a l'apartat 5. Només falta el binding, exclusivament a producció:

Aquest és el cas més interessant, perquè la CI és un objectiu molt llaminer: si algú compromet el sistema de CI i aquest té cluster-admin, té el clúster. Li donem exactament el que necessita per desplegar: actualitzar la imatge dels Deployments i StatefulSets existents. Res més.

Analitzem les decisions:

• Sense create: els objectes nous els crea una persona de plataforma després de revisió. La CI només actualitza el que ja existeix i ha estat revisat.
• Sense delete ni deletecollection: una CI compromesa no pot esborrar la plataforma.
• Sense secrets: la CI no llegeix credencials del clúster. Les seves són al gestor de secrets de la canalització.
• Sense pods/exec: no hi ha manera que la CI obri una shell a producció.

Si volguéssim ser encara més estrictes, podríem acotar amb resourceNames als noms exactes de les càrregues:

Aquest és el patró correcte quan cal el llistat: dues regles, una de restrictiva per a les operacions per nom i una altra amb només list.

El CronJob informes-ocupacio genera un informe nocturn d'ocupació de places. No necessita parlar amb l'API de Kubernetes en absolut, així que el correcte és que ni tan sols munti el token:

Que un procés no tingui cap binding és la situació ideal i més freqüent del que la gent es pensa. botiga-web, worker-notificacions i redis-cache són en el mateix cas.

api-reserves sí que necessita llegir un ConfigMap concret per recarregar la seva configuració de rutes en calent:

I l'operador de PostgreSQL del mòdul 6, que sí que necessita permisos amplis perquè la seva feina és gestionar StatefulSets, Services i PVCs. Recorda el que vam dir a 06-07: abans d'adoptar un operador cal llegir quin RBAC demana. Aquest és el mínim raonable, acotat a un namespace:

Si l'operador que estàs avaluant exigeix un ClusterRole amb secrets a tot el clúster i la seva documentació no explica per què, aquesta és una raó legítima per rebutjar-lo o per desplegar-lo amb l'abast restringit a un namespace, si ho admet.

Aquest és un dels punts que més gent entén malament, i té conseqüències directes sobre les dades de clients de Rutas Norte.

Quan executes kubectl get secrets, kubectl fa un GET /api/v1/namespaces/<ns>/secrets. L'apiserver retorna una SecretList amb els objectes complets, inclòs el camp data amb tots els valors. Que kubectl et mostri una taula resumida sense els valors és només una decisió de presentació del client. Les dades ja han viatjat per la xarxa fins a la teva màquina.

Com vam dir a 03-02, base64 no és xifratge: és codificació. Una sola ordre ho reverteix.

Regla que no admet excepcions: concedir list sobre secrets és concedir lectura de tots els secrets d'aquell àmbit. No hi ha manera de llistar secrets "sense veure'n el contingut". Si un rol té list sobre secrets a rutas-norte-pro, qui el tingui pot llegir les credencials de la base de dades de clients. Tracta-ho amb la mateixa serietat que lliurar la contrasenya.

El mateix val per a watch, que lliura els objectes complets en cada canvi.

Això és cluster-admin. Però fins i tot els comodins "petits" són perillosos:

L'última fila és especialment traïdora: un comodí a verbs sobre pods no inclou els subrecursos (cal anomenar-los), però resources: ["pods/*"] sí que inclou exec, attach i portforward. Val la pena memoritzar la diferència.

I hi ha un problema temporal: un comodí concedeix permisos sobre recursos que encara no existeixen. Si instal·les un CRD nou el mes que ve, qualsevol amb resources: ["*"] el controlarà des del primer dia, sense que ningú hagi decidit res.

L'alternativa correcta és sempre enumerar. És més llarg d'escriure i moltíssim més fàcil d'auditar.

Kubernetes impedeix, per defecte, que creïs o modifiquis un rol amb permisos que tu no tens. Si poguessis, qualsevol amb permís sobre roles seria cluster-admin de facto: s'escriuria un rol amb * i se l'assignaria.

La regla exacta és: per crear o modificar un rol, has de posseir ja tots els permisos que aquell rol concedeix (en l'àmbit corresponent). Hi ha dues excepcions deliberades:

bind, acotat amb resourceNames, és el mecanisme elegant per delegar. A Rutas Norte podríem permetre que els caps d'equip concedissin el rol de suport sense ser administradors:

Qui tingui aquest rol pot crear bindings al rol rutasnorte-suport i a cap altre. No pot vincular admin, ni cluster-admin. És una delegació segura.

Aquesta és probablement la implicació més subestimada de tot RBAC:

Si pots crear pods en un namespace, pots executar codi amb la identitat de qualsevol ServiceAccount d'aquell namespace, simplement posant el seu nom a spec.serviceAccountName.

Crear pods no està protegit per la regla de "no pots concedir el que no tens", perquè tècnicament no estàs creant un rol: estàs creant un pod. Però l'efecte pràctic és idèntic a heretar els permisos d'aquella ServiceAccount.

Conseqüències concretes per al nostre disseny:

1. create pods a rutas-norte-pro és un permís d'alt privilegi. Per això ci-rutasnorte no el té i desenvolupament tampoc el té a producció.
2. Mai posis al mateix namespace una ServiceAccount molt privilegiada i càrregues de treball normals. L'operador de PostgreSQL, que pot llegir secrets, comparteix namespace amb botiga-web. Qui pugui crear un pod allà, hereta els permisos de l'operador. El correcte és aïllar els operadors al seu propi namespace.
3. Els verbs que creen pods indirectament compten igual: crear Deployments, StatefulSets, DaemonSets, Jobs o CronJobs és crear pods per delegació. edit els inclou tots.

Altres rutes d'escalada que convé conèixer per poder tancar-les:

Auditar aquests permisos concrets és una tasca rutinària molt rendible:

Aquesta llista ha de cabre en una pantalla i cada línia ha de tenir una justificació coneguda. El dia que no hi càpiga, comença el problema.

RBAC es degrada amb el temps. Un permís temporal que ningú va retirar, un binding per depurar una incidència que s'hi va quedar, un grup que va créixer. L'única defensa és la revisió sistemàtica.

La segona línia és exactament el que cal caçar: un accés d'emergència que havia de durar dues hores i encara hi és. La convenció de posar la data al nom del binding fa que salti a la vista.

Només plataforma. És el resultat que buscàvem i cal poder demostrar-ho en qualsevol moment: aquesta sortida, guardada amb data, és una evidència vàlida per a una auditoria de compliment.

Quan una persona deixa l'empresa, el seu binding s'hi queda. Quan una ServiceAccount s'esborra, els seus bindings també. Una comprovació senzilla:

Existeixen utilitats específiques que fan aquesta feina molt més còmoda:

Una cadència raonable per a una plataforma com Rutas Norte:

Tots els manifests de RBAC han de viure al repositori, a k8s/base/rbac/, i aplicar-se només des d'allà. Un binding creat a mà amb kubectl create rolebinding és invisible per a la revisió de codi i és exactament per on entren els problemes. Al mòdul 10 veurem amb GitOps com fer que el clúster rebutgi de facto qualsevol cosa que no sigui a Git.

Escriure apiGroups: ["core"]. No existeix. El grup del nucli és la cadena buida "". El manifest s'aplica sense error i no concedeix res; després passes una hora buscant per què hi ha un 403.

Fer servir el Kind o el nom curt a resources. Cal fer servir el plural en minúscules: pods, no Pod ni po; deployments, no Deployment. Consulta-ho amb kubectl api-resources.

Creure que un RoleBinding a un ClusterRole dona permisos globals. No: els acota al namespace del binding. És just al contrari del que suggereix el nom i és la combinació més útil de les quatre.

Intentar canviar el roleRef d'un binding existent. És immutable. Cal esborrar i recrear. Un kubectl apply que canvia el roleRef falla amb un error poc descriptiu.

Concedir edit a producció "perquè només edita". edit llegeix i crea Secrets, i crea pods (amb la qual cosa pot suplantar qualsevol ServiceAccount del namespace). En un namespace amb dades personals és un permís d'administració disfressat.

Suposar que resourceNames protegeix el llistat. No s'aplica a list, watch, create ni deletecollection. Si concedeixes list sense noms, es veu tot.

Oblidar que list sobre Secrets és llegir-los. No hi ha manera de llistar-los sense veure'n el contingut.

Afegir comodins "per sortir del pas". El permís temporal s'hi queda, i a sobre concedeix accés a recursos que encara no existeixen. Si necessites desbloquejar algú de pressa, concedeix el permís exacte que li falta i obre-li una tasca per revisar-ho.

Concedir permisos a usuaris en comptes de a grups. Cada alta i cada baixa es converteix en un canvi de manifest, i les baixes s'obliden sempre.

Confondre 401 amb 403. 401 és autenticació (no sé qui ets), 403 és autorització (sé qui ets i no pots). kubectl auth whoami distingeix els dos casos en un segon.

No verificar. Escriu sempre les comprovacions negatives: no n'hi ha prou amb confirmar que suport pot llegir logs, cal confirmar que no pot fer exec ni llegir Secrets. Les fallades de seguretat són als permisos de més, no als de menys.

Posar un operador privilegiat al mateix namespace que les aplicacions. Qui pugui crear un pod allà hereta els permisos de l'operador. Namespace a part.

Consell d'or: comença sempre per zero permisos i afegeix només el que falla. És més lent el primer dia i moltíssim més segur tots els altres. Amb kubectl auth can-i --list sabràs en cada moment exactament on ets.

Rutas Norte incorpora un becari a l'equip de suport. Necessites un ClusterRole anomenat rutasnorte-suport-junior i un binding que l'apliqui només a rutas-norte-pre. Ha de poder:

• Llistar i veure pods, serveis i deployments.
• Llegir els logs dels pods.

I no ha de poder:

• Llegir Secrets.
• Executar kubectl exec ni kubectl port-forward.
• Modificar res.

Escriu els manifests i les ordres de verificació que demostrin les tres prohibicions.

Un nou agent de mètriques, agent-inventari, corre com a Deployment a rutas-norte-pro amb la seva pròpia ServiceAccount. Necessita llistar pods i nodes de tot el clúster per elaborar un inventari de recursos, i res més. Escriu la ServiceAccount, el ClusterRole, el ClusterRoleBinding i una comprovació que demostri que no pot llegir Secrets ni crear res.

Pregunta addicional: per què aquí sí que cal un ClusterRoleBinding i no n'hi ha prou amb un RoleBinding?

Trobes aquest Role aplicat a rutas-norte-pro:

Està vinculat al grup analitica, l'únic comès del qual és consultar les mètriques d'ocupació mitjançant els ServiceMonitor i veure l'estat dels pods.

1. Enumera tots els problemes de seguretat d'aquest rol.
2. Reescriu-lo amb el mínim privilegi.
3. Escriu les comprovacions que demostrin que la versió nova continua servint per al seu comès i ja no exposa dades personals.

Solució 1

Verificació:

L'última comprovació és la que demostra que el RoleBinding acota el ClusterRole: a rutas-norte-pro no té absolutament res.

Solució 2

Verificació:

Per què cal un ClusterRoleBinding: per dues raons independents.

1. nodes és un recurs sense namespace. Un RoleBinding mai no pot concedir accés a recursos globals, ni tan sols referenciant un ClusterRole que els esmenti.
2. L'agent ha de llistar pods de tots els namespaces. Un RoleBinding acotaria la lectura al namespace del binding, i caldria replicar-lo a cada namespace existent i futur.

Si el requisit hagués estat només "pods de rutas-norte-pro", un RoleBinding hauria estat l'opció correcta i més segura.

Solució 3

1. Problemes del rol original:

2. Versió amb mínim privilegi:

Fixa't que també hem tret pods/log: el comès declarat és consultar mètriques, i els logs podrien contenir informació de clients (encara que a 07-05 ho vam prohibir, el permís mínim no depèn que aquella prohibició es compleixi sempre).

3. Verificació:

Com que el rol vell concedia accés a les credencials de la base de dades de clients, no n'hi ha prou amb corregir el rol: cal revisar el registre d'auditoria per saber si algú va arribar a llegir aquell Secret, i si és així, rotar les credencials i notificar-ho al responsable de compliment. Com es fa aquella consulta és el tema de 08-06.

RBAC és la primera i més important línia de defensa d'un clúster de Kubernetes, i ara tens el model mental complet:

• Tota petició travessa tres portes: autenticació (qui ets), autorització (què pots fer, aquí actua RBAC) i control d'admissió (si l'objecte és acceptable).
• Els subjectes són usuaris i grups, que Kubernetes no emmagatzema i arriben de l'autenticador, i ServiceAccounts, que sí que són objectes del clúster.
• Quatre objectes: Role/ClusterRole diuen què, RoleBinding/ClusterRoleBinding diuen qui. La combinació RoleBinding → ClusterRole és la més útil: escriu el rol una vegada, acota'l on vulguis.
• Una regla és la intersecció d'apiGroups (amb el grup buit "" del nucli), resources (inclosos subrecursos com pods/log i pods/exec), verbs i opcionalment resourceNames (que no s'aplica a list).
• list sobre Secrets és llegir-los. Els comodins concedeixen més del que et penses, inclòs sobre recursos que encara no existeixen.
• Crear pods equival a poder fer servir qualsevol ServiceAccount del namespace; per això els operadors privilegiats van al seu propi namespace.
• kubectl auth can-i --as/--as-group i kubectl auth whoami converteixen el RBAC en una cosa verificable, i aquestes verificacions s'han d'executar automàticament en cada canvi.

A Rutas Norte hem passat de "qualsevol pot llegir les credencials de la base de dades de clients" a un disseny on només plataforma ho pot fer, suport veu l'estat i els logs sense poder entrar als contenidors, desenvolupament investiga producció sense tocar-la, i la canalització d'integració contínua només pot actualitzar la imatge de les càrregues que ja existeixen.

Però acabem de descobrir un límit incòmode: RBAC decideix si tens dret a crear un pod, no com és aquell pod. Algú de plataforma, amb permisos perfectament legítims, pot desplegar avui mateix un contenidor amb privileged: true, que munti / del node amb hostPath i corri com a root. RBAC dirà que sí, perquè té permís per crear pods. I des d'allà, el node sencer —i tots els pods que hi corrin, inclòs postgres-reserves— queda al descobert.

La lliçó següent, 08-02, Contextos de Seguretat i Enduriment del Contenidor, ataca exactament aquest problema: què aïlla realment un contenidor, per què no és una màquina virtual, i com es configura el securityContext de cada component de Rutas Norte perquè, encara que algú aconsegueixi executar codi dins d'un contenidor, no en pugui sortir.