Tot el que portem construït en aquest mòdul protegeix el clúster en temps d'execució. RBAC decideix qui pot fer què (08-01). El securityContext limita el que pot fer un contenidor (08-02). Les polítiques d'admissió impedeixen desplegar alguna cosa que no compleixi les regles (08-03). I les polítiques de xarxa controlen què parla amb què i què pot sortir (08-04).

Però tot això descansa sobre una suposició que mai no hem qüestionat: que les imatges que executem són les que ens pensem.

I aquella suposició és fràgil. registry.rutasnorte.example/api-reserves:2.7.1 és una etiqueta, i una etiqueta es pot reassignar: la imatge que es va descarregar ahir pot no ser la d'avui. La imatge base sobre la qual es va construir conté centenars de paquets que ningú no ha revisat. Les dependències es van instal·lar des de repositoris públics durant la construcció. I ara com ara, res no impedeix que algú amb accés al registre pugi una imatge modificada amb el mateix nom i que el clúster l'executi sense piular, amb tots els nostres securityContext perfectament aplicats... a un contenidor que fa una cosa diferent de la que ens pensem.

Aquesta lliçó s'ocupa de la cadena de subministrament de les imatges: d'on vénen, com es construeixen, com s'identifiquen sense ambigüitat, com se signen i com s'aconsegueix que el clúster rebutgi tot el que no estigui verificat.

Advertiment important. La política d'imatges d'una plataforma de producció l'ha de dissenyar i revisar un professional de seguretat. Quan les imatges processen dades personals —api-reserves, postgres-reserves i informes-ocupacio a Rutas Norte— el responsable de compliment normatiu ha de conèixer quins controls existeixen sobre el programari que tracta aquelles dades, perquè una dependència compromesa és una via directa d'accés a elles. L'enfocament d'aquesta lliçó és exclusivament defensiu: entendre on es pot enverinar una imatge per tancar cada punt i detectar els intents.

1. La cadena de subministrament d'una imatge
2. Construir imatges mínimes
3. Usuari no root al Dockerfile
4. Identificar la imatge sense ambigüitat: etiquetes i digests
5. imagePullPolicy i el parany de l'etiqueta reutilitzada
6. El registre privat
7. Signatura i verificació amb Cosign
8. Verificar al clúster amb una política d'admissió
9. SBOM i atestacions de procedència
10. Política d'imatges base i actualització periòdica
11. La política completa d'imatges de Rutas Norte
12. Errors comuns i consells
13. Exercicis
14. Conclusió

Una imatge de contenidor no apareix del no-res. És el resultat d'una cadena de passos, i cada baula és un punt on es pot introduir alguna cosa indesitjada.

Fixa't que les defenses es reforcen entre si. El digest garanteix que descarregues exactament el contingut que esperes, però no diu si aquell contingut és bo. La signatura diu que algú de confiança el va aprovar, però no si conté vulnerabilitats. L'escaneig diu quines vulnerabilitats té, però no si algú el va modificar. Calen totes.

Pensa en api-reserves. És una aplicació Node.js amb potser 400 dependències transitives: paquets que instal·la un paquet que instal·la un paquet que vas demanar tu. Cadascuna és codi que s'executarà amb accés a la connexió de postgres-reserves, és a dir, amb accés a la taula de clients.

No cal cap fallada del kernel ni cap escalada de privilegis. Una dependència compromesa ja és a dins, amb els permisos legítims de l'aplicació. Ni el securityContext més restrictiu no ho impedeix, perquè no està fent res prohibit: està fent servir la connexió a la base de dades que l'aplicació necessita.

Aquesta és la raó de ser d'aquesta lliçó.

El principi és senzill: el que no és a la imatge no pot tenir vulnerabilitats ni ser utilitzat per ningú.

Una imatge basada en una distribució completa porta centenars de paquets que la teva aplicació no fa servir: compiladors, gestors de paquets, curl, wget, un intèrpret d'ordres complet, eines de xarxa. Cadascun és superfície d'atac i una font potencial d'alertes de vulnerabilitat que cal gestionar.

És la tècnica fonamental: fer servir una imatge amb eines per construir, i copiar només el resultat a una imatge neta.

Punts a destacar:

• npm ci en lloc de npm install. ci instal·la exactament el que diu package-lock.json i falla si el fitxer de bloqueig no està sincronitzat. install pot resoldre versions diferents en cada construcció, cosa que fa que dues construccions del mateix codi produeixin imatges diferents. Reproduïbilitat i seguretat van de la mà.
• Copiar els manifests abans que el codi. Aprofita la caché de capes: mentre les dependències no canviïn, no es reinstal·len.
• --omit=dev: les dependències de desenvolupament (marcs de proves, linters) no han d'acabar a producció. Solen ser la meitat de l'arbre.
• --chown al COPY: els fitxers queden amb el propietari correcte sense necessitat d'un RUN chown que duplicaria la mida de la capa.
• Etiquetes OCI: deixen rastre d'on ve la imatge. Quan d'aquí a un any algú trobi aquesta imatge al registre, sabrà de quin repositori va sortir.

Un detall important que s'oblida constantment: els secrets utilitzats durant la construcció queden a les capes encara que els esborris després. Si fas RUN echo $TOKEN > /tmp/token && ... && rm /tmp/token, el token continua estant a la capa intermèdia i qualsevol que descarregui la imatge el pot extreure. La solució correcta és RUN --mount=type=secret, que munta el secret durant l'ordre sense persistir-lo:

I amb nginx, el cas de botiga-web:

Aquesta és la part que els articles entusiastes no expliquen. Amb distroless o scratch:

No hi ha shell. Això és exactament el que volem des del punt de vista de la seguretat —qui aconsegueixi executar codi no té eines— però significa que les tècniques de diagnòstic habituals no funcionen.

La solució és la que vam veure a 07-06: els contenidors efímers.

El contenidor efímer porta les eines i, amb --target, comparteix el namespace de processos del contenidor objectiu. Pots inspeccionar el procés, el seu sistema de fitxers a través de /proc/1/root i la seva xarxa, sense que la imatge de producció contingui ni una sola utilitat.

Nota de seguretat important: kubectl debug requereix el subrecurs pods/ephemeralcontainers, que a 08-01 vam classificar com de risc molt alt i no vam concedir ni a suport ni a desenvolupament. És una operació de plataforma. I a 08-03 la política de registre obligatori de Kyverno incloïa ephemeralContainers precisament perquè ningú no pogués injectar una imatge arbitrària per aquesta via.

Un principi útil: scratch per a binaris estàtics (Go, Rust), distroless per a llenguatges amb runtime (Node.js, Python, Java), alpine quan necessitis una mica de sistema operatiu, i una distribució completa només si tens una raó concreta que puguis escriure.

A 08-02 vam configurar runAsNonRoot: true i runAsUser als manifests. Aquí fem el mateix des de l'altre costat: declarar l'usuari a la imatge.

Sembla redundant i no ho és. Es reforcen mútuament:

El cas més valuós és el segon: si demà algú copia aquesta imatge a un manifest nou sense el securityContext complet, el USER del Dockerfile continua protegint. I en l'altre sentit, runAsNonRoot: true al manifest detecta si algú va reconstruir la imatge sense el USER i rebutja el pod en lloc d'arrencar-lo com a root en silenci.

Això és crític i ja ho vam avançar a 08-02:

Amb un nom, Kubernetes no pot verificar runAsNonRoot: true, perquè per resoldre'l hauria de llegir el /etc/passwd de dins de la imatge abans d'arrencar-la:

El pod no arrenca. Una fallada desconcertant la causa de la qual és al Dockerfile, no al manifest.

A distroless no hi ha adduser. Les imatges amb el sufix :nonroot ja porten l'usuari 65532 creat, que és el més còmode. Per a scratch, es copia un /etc/passwd fabricat a l'etapa de construcció:

La imatge resultant conté tres fitxers: el binari, els certificats i el /etc/passwd. Res més. No hi ha shell que obrir, no hi ha curl que fer servir, no hi ha gestor de paquets que instal·li res. És la superfície d'atac més petita possible.

Un detall que sorprèn: sense els certificats arrel, qualsevol connexió HTTPS falla amb un error de verificació de certificat. És el problema més habitual en passar a scratch.

Amb distroless això falla perquè no hi ha id. L'alternativa és inspeccionar les metadades:

I una comprovació automatitzable per a la canalització:

Aquesta és, probablement, la part amb més conseqüències pràctiques de la lliçó.

latest no significa "l'última": és simplement l'etiqueta que es fa servir per defecte quan no n'especifiques cap. No hi ha cap garantia que apunti a res en concret.

Els problemes, un a un:

Aquell segon punt és especialment insidiós perquè produeix incidències impossibles de diagnosticar: la meitat de les peticions funcionen i l'altra meitat no, segons a quina rèplica arribin.

A 08-03 vam escriure una ValidatingAdmissionPolicy que prohibeix latest a nivell de clúster. Aquella política és la que converteix aquesta recomanació en una garantia.

L'escaló següent és fer servir etiquetes que, per convenció i per configuració del registre, mai no es reassignen:

Esquemes habituals:

La clau és la paraula immutable: un cop publicada 2.7.1, aquella etiqueta mai no es reassigna a un altre contingut. Si cal corregir alguna cosa, es publica 2.7.2. Molts registres permeten aplicar aquella regla del costat del servidor (apartat 6), i aleshores deixa de ser una convenció per ser una garantia.

Fins i tot amb etiquetes immutables per convenció, l'etiqueta és un punter mutable: si algú amb accés al registre la reassigna, el clúster descarregarà una altra cosa.

El digest és el hash SHA-256 del manifest de la imatge. És criptogràficament immutable: si el contingut canvia, el digest canvia. No es pot reassignar perquè no és un nom, és una empremta del contingut.

L'objecció pràctica és evident: un digest és illegible. La solució és escriure tots dos:

O, a la pràctica moderna, deixar que una eina ho gestioni. Kustomize (10-04) resol el digest automàticament:

I eines com Renovate o Dependabot actualitzen els digests amb una petició de canvi quan hi ha versions noves, amb la qual cosa el canvi d'imatge passa per revisió de codi com qualsevol altre canvi. Aquest és exactament l'objectiu.

Aquella segona ordre és or pur per investigar un incident: et diu exactament quin contingut s'està executant, no quina etiqueta es va demanar. Si el digest no coincideix amb el que esperaves, tens un problema per investigar urgentment.

Una comprovació molt útil: verificar que totes les rèpliques corren el mateix digest.

Dues línies per a dos contenidors. Si apareguessin tres línies per a api, hi ha rèpliques amb versions diferents.

imagePullPolicy determina quan el kubelet descarrega la imatge del registre.

Si no especifiques imagePullPolicy:

Aquell comportament té una lògica: amb un digest, IfNotPresent és perfectament segur perquè la còpia local és necessàriament el contingut correcte (si el digest coincideix, el contingut coincideix).

Aquí hi ha l'escenari que cal entendre:

1. Es desplega api-reserves:2.7.1 amb imagePullPolicy: IfNotPresent.
2. Els nodes A, B i C descarreguen la imatge i la guarden en caché.
3. Algú reassigna l'etiqueta 2.7.1 al registre a un contingut diferent.
4. Un pod es recrea al node D, que no tenia la imatge: descarrega la nova.
5. Els pods d'A, B i C continuen executant l'antiga.

Resultat: rèpliques del mateix Deployment executant continguts diferents, amb el mateix nom d'imatge. I cap eina de Kubernetes no t'ho dirà: kubectl get pods mostra la mateixa imatge a tots.

Només mirant l'imageID (el digest efectiu) es veu la discrepància. Per això la comprovació de l'apartat anterior és tan valuosa.

I per això la solució de fons és fer servir digests, no ajustar imagePullPolicy:

Fixa't en el matís de la primera fila. Always no et protegeix d'una etiqueta reassignada maliciosament: et garanteix que tots els pods executen el contingut nou, que és exactament el que volia qui la va reassignar.

Aquell últim punt és un benefici de seguretat real: amb IfNotPresent, un node que ja té la imatge en caché la continua fent servir encara que les credencials del registre s'hagin revocat.

Amb digest, IfNotPresent és alhora segur i robust. És el millor de tots dos mons.

Excepció: a rutas-norte-dev, on s'itera ràpid amb etiquetes mutables, Always és raonable. I un avís de 08-02 que s'aplica aquí: a minikube amb imatges construïdes localment, Always fa que el kubelet intenti descarregar del registre i falli; allà és on Never o IfNotPresent tenen sentit.

A 08-03 vam escriure la política de Kyverno que obliga que tota imatge vingui de registry.rutasnorte.example. El registre deixa de ser una comoditat per ser el punt on s'apliquen tots els controls.

Ja vam veure els imagePullSecrets a 03-02. La millora important és declarar-los a la ServiceAccount en lloc de a cada pod:

Avantatges de declarar-lo a la ServiceAccount:

• No cal repetir-lo a cada Deployment: s'oblida menys.
• Canviar les credencials és un sol objecte.
• Es pot tenir una ServiceAccount amb accés a un repositori concret del registre i una altra amb accés a un altre.

I un advertiment de 08-01 que s'aplica directament: aquest Secret conté credencials del registre. Qui tingui list sobre secrets al namespace les pot llegir. Al nostre disseny, només plataforma.

El principi és la separació entre publicar i descarregar:

Els nodes de producció mai no han de tenir credencials de publicació. Si algú compromet un node i l'imagePullSecret permet publicar, pot pujar imatges enverinades al registre del qual s'abasteix tota la plataforma. És una escalada d'un node al clúster sencer.

La majoria de registres moderns permeten configurar que una etiqueta, un cop publicada, no es pugui reassignar:

Això converteix "fem servir etiquetes immutables per convenció" en una garantia tècnica. Un intent de reassignar una etiqueta falla:

Continua sent recomanable fer servir digests, perquè la immutabilitat protegeix contra l'error i contra la reassignació, però un registre compromès a nivell d'emmagatzematge la podria burlar. El digest el verifica el mateix client.

Rutas Norte fa servir postgres:16.4, redis:7.4-alpine i nginx-unprivileged. Totes són imatges públiques excel·lents, i tot i així convé copiar-les al registre propi:

Què resol això:

Aquell últim punt té un valor d'inventari que se subestima: quan aparegui una vulnerabilitat greu en una llibreria, la pregunta serà "quines imatges nostres la contenen?", i tenir-ho tot en un registre propi fa que la resposta sigui una consulta en lloc d'una investigació.

Fins ara hem garantit quin contingut s'executa (digest). Falta garantir que aquell contingut l'ha aprovat algú de confiança.

Un digest et diu que la imatge no ha canviat. No et diu si aquella imatge la va construir la teva canalització o algú que va robar les credencials del registre. La signatura criptogràfica respon a aquella pregunta: qui avala aquesta imatge.

Sigstore és un projecte que fa la signatura d'artefactes de programari accessible. Cosign és la seva eina per signar imatges de contenidor.

Instal·lació:

El model clàssic:

Signar sempre per digest, mai per etiqueta. Si signes imatge:2.7.1, Cosign resol el digest en aquell moment; però si algú reassigna l'etiqueta després, la signatura no correspon al nou contingut i la verificació falla, cosa que és correcta però confusa. Signar per digest deixa clar què s'està avalant.

El problema del parell de claus és on viu la clau privada. Si és a la canalització, qui comprometi la canalització pot signar qualsevol cosa. Es pot mitigar amb un KMS:

És el model que recomana Sigstore i resol el problema de la custòdia de claus.

Funciona així:

1. Cosign obté un token OIDC d'un proveïdor d'identitat (la mateixa canalització, GitHub Actions, GitLab CI, Google, etc.).
2. Sol·licita a Fulcio (l'autoritat certificadora de Sigstore) un certificat de curta durada, vàlid deu minuts, que vincula la identitat amb una clau efímera.
3. Signa la imatge amb aquella clau.
4. Publica la signatura i el certificat a Rekor, un registre públic de transparència, immutable i només d'addició.
5. Descarta la clau privada.

Verificació per identitat, no per clau:

El que estàs verificant no és "aquesta imatge la va signar la clau X", sinó una cosa molt més útil: "aquesta imatge la va signar la canalització del repositori plataforma/* de git.rutasnorte.example".

Comparació:

Recomanació per a Rutas Norte: sense claus amb OIDC, fent servir el proveïdor d'identitat de la canalització. És més segur i elimina la feina de custodiar claus.

Nota sobre privacitat: el registre de transparència públic de Sigstore fa públics els noms de les imatges signades. Si això és un problema (revela noms interns de projectes), es pot desplegar una instància privada de Fulcio i Rekor.

L'ordre importa: escanejar abans de publicar. Publicar primer i escanejar després significa que durant una estona hi ha una imatge vulnerable disponible perquè algú la desplegui.

Signar a la canalització és la meitat de la feina. Si el clúster accepta qualsevol imatge, la signatura és un adorn: qui pugui saltar-se la canalització i publicar directament al registre desplega el que vulgui.

La verificació de signatures ha d'ocórrer al clúster, al control d'admissió. És l'única forma de garantir que absolutament tot el que s'executa ha passat pel procés.

Reprenem Kyverno de 08-03, ara amb verifyImages:

Aspectes clau del manifest:

• mutateDigest: true és el més elegant d'aquesta política. Kyverno verifica la signatura, obté el digest i reescriu el manifest perquè faci servir el digest en lloc de l'etiqueta. Resol automàticament el problema de l'apartat 4: encara que el Deployment digui :2.7.1, el pod que es crea fa servir @sha256:..., el mateix que es va verificar.
• required: true: si la imatge no encaixa amb cap regla de verificació, es rebutja. Sense això, una imatge d'un registre no contemplat passaria sense verificar.
• useCache: true: sense caché, cada creació de pod consulta el registre de transparència, cosa que afegeix latència i crea una dependència externa al camí crític.
• webhookTimeoutSeconds: 30: la verificació pot trigar. Si el temps d'espera s'esgota i failurePolicy és Fail, no es poden crear pods.
• Dues regles: les nostres imatges es verifiquen per identitat OIDC; les públiques replicades, amb la clau de l'equip de plataforma que les va revisar i copiar.

Vam demanar una etiqueta i s'està executant un digest verificat. Exactament el que volíem.

Sigstore té el seu propi controlador d'admissió, especialitzat únicament en això:

I s'activa etiquetant el namespace, igual que el PSA:

Per a Rutas Norte, Kyverno, perquè ja el tenim de 08-03 i evita afegir un altre webhook d'admissió. El policy-controller té sentit si no vols un motor de política general.

Aquesta política és de les que poden aturar la plataforma:

• Si Rekor no respon i no hi ha caché, la verificació falla.
• Si la identitat de la canalització canvia (es migra de proveïdor de CI), totes les signatures noves deixen de validar.
• Si failurePolicy: Fail i Kyverno cau, no es pot crear cap pod.

Mitigacions obligatòries abans de posar Enforce:

1. Començar amb validationFailureAction: Audit durant setmanes.
2. useCache: true sempre.
3. Kyverno amb tres rèpliques, PDB i antiafinitat (08-03).
4. Un procediment documentat per desactivar la política en una emergència, amb qui ho pot fer i com es registra.
5. Excloure kube-system i rutas-norte-sistema.

Un SBOM (Software Bill of Materials) és la llista completa de tot el que hi ha dins d'una imatge: cada paquet del sistema, cada llibreria, cada dependència transitiva, amb la seva versió i la seva llicència.

Formats estàndard: SPDX (norma ISO) i CycloneDX (OWASP). Tots dos valen; l'important és tenir-ne un.

Adjuntar-lo a la imatge com a atestació signada:

Així el SBOM viatja amb la imatge, signat, i es pot recuperar en qualsevol moment:

Aquest és l'escenari que justifica tot l'esforç. Un dimarts qualsevol es publica una vulnerabilitat crítica en una llibreria de registre molt utilitzada. La pregunta que tota l'organització necessita respondre en minuts, no en dies, és:

És aquella llibreria en alguna de les nostres imatges? En quines? Amb quina versió? Quines són a producció?

Sense SBOM, la resposta implica descarregar cada imatge, inspeccionar-la, revisar els fitxers de dependències de cada repositori i esperar no haver-se deixat res. Dies de feina, amb incertesa al final.

Amb SBOM:

Dos minuts. I amb certesa, no amb esperança.

SLSA (Supply-chain Levels for Software Artifacts) és un marc que defineix nivells de garantia sobre com es va construir un artefacte. Una atestació de procedència respon a:

Els nivells de SLSA, resumits:

Un objectiu raonable per a una plataforma com Rutas Norte és L2: construcció automatitzada en un servei allotjat, amb procedència signada. L3 requereix un servei de construcció amb garanties fortes d'aïllament, cosa que sol implicar infraestructura específica.

I la peça que tanca el cercle: exigir l'atestació en admissió.

Amb això, una imatge sense SBOM no es desplega a producció. La conseqüència pràctica és que l'inventari mai no es queda desactualitzat, perquè és impossible desplegar alguna cosa que no estigui inventariada.

Una imatge construïda avui amb node:22.7.0-alpine no té vulnerabilitats conegudes. D'aquí a tres mesos, aquella mateixa imatge —sense que ningú l'hagi tocada— en tindrà unes quantes, perquè s'hauran publicat vulnerabilitats en paquets que conté.

Una imatge no es degrada: el món canvia al seu voltant.

Això té una conseqüència que molta gent no interioritza: si una imatge fa sis mesos que és a producció sense reconstruir-se, acumula sis mesos de vulnerabilitats sense apedaçar, encara que el codi de l'aplicació sigui perfecte.

La solució és reconstruir amb regularitat, encara que el codi no canviï.

Aquesta és la part de l'argument que cal saber defensar davant de qui pregunti "per a què reconstruir si no hem canviat res?".

Aquell últim punt és el decisiu. Un procediment de reconstrucció que s'executa cada setmana està provat. Un que s'executa una vegada l'any, quan hi ha una crisi, està sense provar exactament quan més importa.

I eines que automatitzen el seguiment:

Reunim tot en el document que regeix la plataforma.

Una imatge només es desplega a producció si compleix tots aquests requisits, i cadascun el verifica un mecanisme concret:

Aquest manifest reuneix el mòdul sencer: la ServiceAccount de 03-06 i 08-01, el securityContext de 08-02, el compliment de restricted de 08-03, i la referència per digest verificat d'aquesta lliçó.

Fer servir latest en qualsevol entorn que no sigui un experiment local. Trenca els rollbacks, fa irreproduïbles els desplegaments i pot deixar rèpliques amb versions diferents.

Fer servir etiquetes mòbils com :2.7 o :16. Es reassignen en cada pedaç. Semblen versions concretes i no ho són.

Creure que imagePullPolicy: Always protegeix d'una etiqueta reassignada. Garanteix que totes les rèpliques executin el contingut nou, que és just el que buscava qui la va reassignar. La solució és el digest.

Declarar el USER per nom al Dockerfile. runAsNonRoot: true no ho pot verificar i el pod no arrenca, amb un error la causa del qual és en un altre fitxer.

Deixar secrets a les capes de la imatge. Esborrar-los en un RUN posterior no els treu de la capa anterior. Fes servir RUN --mount=type=secret.

Fer servir npm install en lloc de npm ci. Pot resoldre versions diferents en cada construcció, fent la imatge irreproduïble.

Incloure dependències de desenvolupament a la imatge final. Marcs de proves i linters no pinten res a producció i solen ser la meitat de l'arbre de dependències.

Passar a distroless sense pla de depuració. No hi ha shell. Cal dominar kubectl debug amb contenidors efímers abans de necessitar-ho en una incidència.

Oblidar els certificats arrel en fer servir scratch. Totes les connexions HTTPS fallen amb un error de verificació de certificat.

Signar per etiqueta en lloc de per digest. Deixa ambigüitat sobre quin contingut es va avalar.

Guardar la clau privada de signatura a la canalització. Qui comprometi la CI pot signar qualsevol cosa. Fes servir signatura sense claus amb OIDC, o un KMS.

Signar a la canalització i no verificar al clúster. La signatura sense verificació és un adorn: qui pugui publicar directament al registre desplega el que vulgui.

Posar la política de verificació en Enforce des del primer dia. Pot aturar la plataforma sencera. Audit durant setmanes, useCache: true, alta disponibilitat del motor i un procediment d'emergència documentat.

Escanejar després de publicar. Durant aquell interval hi ha una imatge vulnerable disponible per desplegar.

Donar credencials de publicació als nodes de producció. Un node compromès pot enverinar el registre del qual s'abasteix tota la plataforma.

No reconstruir les imatges que no canvien. Acumulen mesos de vulnerabilitats sense apedaçar. Reconstrueix setmanalment.

Consell d'or: la pregunta que has de poder respondre en qualsevol moment és "què està corrent exactament a producció ara mateix, qui ho va aprovar i què conté?". Digest per al què, signatura per al qui, SBOM per al contingut. Si falta una de les tres, tens un buit.

Aquest és el Dockerfile actual de worker-notificacions:

1. Enumera tots els problemes de seguretat i de qualitat que té.
2. Reescriu-lo amb construcció multietapa, base mínima i usuari no root.
3. Escriu les ordres que verificarien que la imatge resultant compleix els requisits de la política de Rutas Norte.

El Deployment de botiga-web a producció fa servir:

1. Explica els tres riscos concrets d'aquesta configuració.
2. Escriu les ordres per obtenir el digest, verificar-ne la signatura i inspeccionar-ne el SBOM.
3. Escriu el fragment corregit del manifest.
4. Com comprovaries que les tres rèpliques estan executant el mateix contingut?

Rutas Norte incorpora passarela-sms, un component que envia avisos per SMS de canvis d'horari. Es construeix en un repositori diferent (https://git.rutasnorte.example/comunicacions/passarela-sms) per un equip diferent.

Escriu la regla de Kyverno que cal afegir a la política verificar-firma-imatges perquè:

• Només s'acceptin imatges de registry.rutasnorte.example/rutasnorte/passarela-sms*.
• Signades des del repositori comunicacions/passarela-sms (i no des d'un altre).
• Amb SBOM adjunt que contingui almenys un paquet.
• Substituint l'etiqueta pel digest verificat.

Indica també com la desplegaries sense risc de bloquejar desplegaments legítims, i què comprovaries abans de passar-la a Enforce.

Solució 1

1. Problemes del Dockerfile original:

El problema 9 és subtil i molt real: amb la forma shell, el PID 1 és l'intèrpret d'ordres, que no propaga SIGTERM al procés de Node. Kubernetes espera el terminationGracePeriodSeconds complet i després mata el pod amb SIGKILL, tallant les notificacions en curs.

2. Dockerfile reescrit:

I el .dockerignore, que resol els problemes 4 i 5:

.env i .git en aquella llista no són opcionals: COPY . . sense .dockerignore pot ficar credencials de desenvolupament i tot l'historial del repositori dins de la imatge, on queden per sempre.

3. Verificació:

De 412 paquets a la versió original a 187: menys de la meitat de superfície per vigilar.

Solució 2

1. Els tres riscos:

2. Ordres:

Nota: la data diu 2026-07-28, fa nou dies. Dins del marge de 30 dies de la política, però convé tenir-ho present.

3. Manifest corregit:

I amb Kustomize (10-04), per no escriure el digest a mà a cada entorn:

4. Comprovar que les tres rèpliques executen el mateix:

I la versió que retorna un únic valor si tot està bé:

Un 1 significa que totes les rèpliques executen el mateix contingut. Qualsevol número superior és un incident que cal investigar immediatament: significa que hi ha rèpliques amb continguts diferents sota el mateix nom.

Solució 3

Decisions a destacar:

• subject sense comodí. Escriure comunicacions/* permetria que qualsevol repositori d'aquell grup signés imatges de passarela-sms. En fixar la ruta exacta, només la canalització d'aquell repositori concret pot avalar aquestes imatges. És el mateix principi de mínim privilegi de 08-01, aplicat a la signatura.
• Regla separada, no ampliar l'existent. Podríem haver afegit comunicacions/* al subject de la regla principal, però això permetria que l'equip de comunicacions signés imatges d'api-reserves. Cada repositori signa el seu.
• El patró passarela-sms* amb asterisc cobreix variants com passarela-sms-worker si el component creix. Si es prefereix ser estricte, es treu l'asterisc.

Desplegament sense risc:

Què comprovar abans d'Enforce:

El punt 7 mereix èmfasi. Una política de verificació de signatures en Enforce pot impedir qualsevol desplegament si Rekor no respon o si la identitat de la canalització canvia. Ha d'existir un procediment escrit, amb noms, per desactivar-la en minuts, i aquell procediment ha d'haver-se assajat. Una mesura de seguretat que pot paralitzar la plataforma i no té sortida d'emergència és un risc operatiu, no una protecció.

Hem protegit la cadena de subministrament de les imatges de Rutas Norte:

• Una imatge es pot enverinar en cinc punts: la imatge base, les dependències, el procés de construcció, el registre i la descàrrega. Cadascun necessita la seva defensa, i les defenses es reforcen entre si: el digest garanteix el contingut, la signatura garanteix l'aval, el SBOM garanteix l'inventari.
• Imatges mínimes amb construcció multietapa: scratch per a binaris estàtics, distroless per a llenguatges amb runtime, alpine quan cal sistema operatiu. El cost és la depuració, que es resol amb contenidors efímers (kubectl debug).
• Usuari no root numèric al Dockerfile, que es reforça amb el runAsNonRoot del manifest (08-02): cadascun protegeix el buit de l'altre.
• latest és inacceptable i les etiquetes mòbils com :1.9 també. L'etiqueta immutable és acceptable; el digest és l'única referència criptogràficament reproduïble.
• imagePullPolicy: Always no protegeix d'una etiqueta reassignada: garanteix que totes les rèpliques executin el contingut nou. Amb digest, IfNotPresent és segur i no depèn que el registre respongui.
• El registre privat és el punt de control únic: imagePullSecrets a la ServiceAccount, separació estricta entre publicar i descarregar, immutabilitat d'etiquetes del costat del servidor, i rèplica de les imatges públiques que es fan servir.
• Cosign signa les imatges, preferiblement sense claus amb identitat OIDC, que elimina el problema de custodiar la clau privada i permet verificar qui i des d'on va signar.
• Signar no n'hi ha prou: cal verificar al clúster. La política de Kyverno amb verifyImages i mutateDigest: true rebutja el no signat i substitueix l'etiqueta pel digest verificat.
• El SBOM converteix "tenim aquella llibreria vulnerable?" en una consulta de dos minuts en lloc de dies d'investigació. Les atestacions de procedència (SLSA) responen a d'on va sortir la imatge i qui la va construir.
• Reconstruir setmanalment és més barat que apedaçar amb presses: menys delta, menys risc, i sobretot un procediment provat en lloc d'un que s'estrena el dia de la crisi.
• La política completa de Rutas Norte estableix qui publica on i els onze requisits que ha de complir una imatge per entrar a rutas-norte-pro, cadascun verificat per un mecanisme concret.

La plataforma està ara protegida en les quatre dimensions: qui pot fer què, què pot fer un contenidor, què parla amb què, i què s'executa exactament.

Però queden dues preguntes sense resposta, i són just les que fa qualsevol auditoria. La primera és "qui va fer què?": si demà descobrim que el Secret amb les credencials de postgres-reserves va ser llegit, o que un Deployment va desaparèixer, o que una ServiceAccount va fer alguna cosa estranya a les tres de la matinada, ara mateix no tenim manera de saber-ho. Hem posat portes, però no portem registre de qui les creua. La segona és "quins forats tinc ara mateix?": sabem escanejar una imatge abans de publicar-la, però les que fa mesos que són a producció acumulen vulnerabilitats noves cada setmana, i ningú no les està mirant.

L'última lliçó del mòdul, 08-06, Auditoria, Escaneig i Gestió de Vulnerabilitats, respon a totes dues: el registre d'auditoria de l'apiserver i com consultar-lo per respondre a preguntes concretes, l'escaneig continu amb Trivy dins i fora del clúster, l'avaluació davant dels estàndards CIS amb kube-bench, la detecció en temps d'execució amb Falco integrada amb l'Alertmanager del mòdul 7, i —el que de debò falta a la majoria d'equips— la gestió de vulnerabilitats com a procés, amb terminis, responsables i excepcions amb data de caducitat.