Les dues lliçons anteriors han deixat Quilòmetre Zero amb tokens RS256 que tots els serveis verifiquen i amb canals xifrats pels quals viatgen. Però han donat per resolt una cosa que no ho està: d'on surten les identitats. serveis/identitat/tokens.py signa amb una clau el .pub de la qual es va copiar a mà a cada servei; el login és un formulari propi amb Argon2; els empleats de Quilòmetre Zero tenen comptes corporatius en un altre sistema; els productors preferirien entrar amb el seu compte de Google; l'app de repartidors no hauria de mostrar mai una contrasenya de llarga durada; i comandes necessita un token de màquina per cridar inventari quan actua pel seu compte (una saga de compensació de 03-05, per exemple) sense cap usuari al darrere. Resoldre cada cas a cada servei és inviable i, pitjor, insegur: cada implementació pròpia de login és una oportunitat d'error.

Aquesta lliçó centralitza la identitat en un proveïdor d'identitat (IdP) i explica els protocols que permeten que una identitat establerta allà valgui a tota la plataforma: LDAP com a directori d'empleats, SAML 2.0 per a l'inici de sessió únic empresarial, i OAuth 2.0 amb OpenID Connect per a aplicacions web, mòbils i màquina a màquina. Veurem la federació amb identitats socials, el cicle de vida d'una identitat (alta, canvis de rol, baixa), l'autenticació multifactor i la recuperació de comptes. I ho posarem en marxa: Keycloak com a IdP a docker-compose.yml amb un realm km0, tres clients, rols i grups per productor, i OpenLDAP per als empleats; un client OIDC en Python amb PKCE, l'obtenció d'un token de màquina per a comandes, i una cerca LDAP. La identitat dels serveis per certificat (mTLS) i la custòdia de secrets són 06-04; la vora que valida tot això de manera centralitzada, 06-05.

1. Per què centralitzar la identitat
2. Proveïdor d'identitat davant d'aplicacions
3. Directoris LDAP: DIT, dn, ou, cerques i bind
4. SAML 2.0: inici de sessió únic empresarial
5. OAuth 2.0: delegació d'accés
6. OpenID Connect: identitat sobre OAuth 2.0
7. LDAP, SAML i OAuth2/OIDC comparats
8. Federació i identitats socials
9. Cicle de vida, MFA i recuperació
10. Quilòmetre Zero: Keycloak com a IdP i OpenLDAP per als empleats
11. Codi: client OIDC amb PKCE, client credentials i cerca LDAP
12. Errors Comuns i Consells
13. Exercicis
14. Conclusió

Quilòmetre Zero té quatre poblacions amb necessitats diferents:

Si cada servei gestiona els seus usuaris, apareixen els problemes coneguts: contrasenyes diferents a cada lloc (i reutilitzades), un empleat que deixa l'empresa continua tenint accés a analitica perquè ningú no l'ha esborrat d'allà, MFA a la web però no al panell d'operadors, i quatre implementacions de recuperació de contrasenya amb quatre conjunts d'errors. La centralització ho resol: una font de veritat de qui existeix i quins atributs té, un punt on aplicar MFA i polítiques de contrasenya, una baixa que tanca totes les portes, i aplicacions que deixen de tocar credencials.

El proveïdor d'identitat (IdP) és el sistema que autentica els subjectes i emet proves d'identitat (assertions SAML, tokens OIDC) que les aplicacions consumeixen. Les aplicacions passen a ser parts confiants (relying parties, o service providers a SAML): no veuen mai la contrasenya, només la prova signada.

Keycloak, l'IdP que farem servir, cobreix tot el quadre: base d'usuaris pròpia, federació amb LDAP i amb proveïdors socials, emissió de tokens OIDC i assertions SAML, MFA, i una consola d'administració. Alternatives amb el mateix paper: Auth0/Okta, Azure AD (Entra ID), AWS Cognito, Ory, Authentik. Els protocols són estàndard; canviar d'IdP no hauria de canviar el codi de les aplicacions.

LDAP (Lightweight Directory Access Protocol) és el protocol de consulta de directoris: bases de dades jeràrquiques optimitzades per a lectures, que emmagatzemen persones, grups, equips i els seus atributs. Active Directory de Microsoft és la implementació més estesa a les empreses (amb Kerberos per a l'autenticació a Windows); OpenLDAP i 389 Directory Server són les de codi obert. A Quilòmetre Zero el directori guarda els empleats, que és el que sol haver-hi ja a qualsevol empresa abans que existeixi la plataforma.

El directori és un arbre, el DIT (Directory Information Tree). Cada entrada té un DN (distinguished name) únic, que és la ruta des de l'arrel:

Conceptes:

• Entrada i atributs: cada node té atributs amb tipus definits per classes d'objecte (inetOrgPerson aporta cn, sn, mail, uid; groupOfNames aporta member). L'esquema és estricte: no es pot inventar un atribut sense declarar-lo.
• dn, ou, cn, uid, dc: distinguished name, organizational unit, common name, user id, domain component. El dn és la clau primària; la resta són atributs amb convenis.
• Cerca: s'indica una base (ou=persones,dc=km0,dc=internal), un abast (base, one, subtree) i un filtre amb sintaxi de prefix: (&(objectClass=inetOrgPerson)(memberOf=cn=operadors,ou=grups,dc=km0,dc=internal)) retorna els operadors; (|(mail=j*)(uid=j*)) els que comencen per j.
• Bind: l'autenticació LDAP. Un simple bind envia dn i contrasenya; el servidor els verifica contra el hash desat (SSHA, o millor, Argon2 a l'OpenLDAP modern). Autenticar un usuari "contra LDAP" és: (1) amb el compte tècnic, cercar el dn amb l'uid o el mail que coincideix; (2) intentar un bind amb aquest dn i la contrasenya que l'usuari ha teclejat. Si el bind té èxit, la contrasenya és correcta.
• LDAPS / StartTLS: LDAP en clar envia les contrasenyes en clar; sempre per TLS (port 636) o amb StartTLS sobre el 389.

LDAP no és un protocol de SSO: cada aplicació que autentica contra LDAP veu la contrasenya de l'usuari. Per això el paper de LDAP en una plataforma moderna és ser la font d'usuaris i grups que l'IdP consulta, i no una cosa que les aplicacions toquin directament. Només l'IdP fa bind.

SAML (Security Assertion Markup Language, 2005) és el protocol clàssic de SSO entre empreses: un empleat entra un cop a l'IdP corporatiu i accedeix a desenes d'aplicacions de tercers (correu, nòmines, CRM) sense tornar-se a autenticar. És XML signat, transportat per redireccions del navegador.

Actors i peces:

• IdP: autentica i emet assertions: documents XML signats que afirmen "el subjecte [email protected] s'ha autenticat a les 10:02 amb contrasenya i MFA, i té aquests atributs (grups, departament)".
• SP (service provider): l'aplicació, que confia en l'IdP perquè en té el certificat de signatura, i que consumeix l'assertion.
• Metadades: cada part publica un XML amb els seus URL i certificats; s'intercanvien un cop en configurar la confiança.
• Bindings: com viatja el missatge: HTTP-Redirect (a l'URL), HTTP-POST (formulari autoenviat). Tot passa pel navegador; IdP i SP no es parlen directament.

El flux SP-initiated (l'usuari comença a l'aplicació):

El flux IdP-initiated comença en un portal de l'IdP amb icones d'aplicacions; és menys segur (no hi ha InResponseTo que lligui la resposta a una petició) i es desaconsella llevat que sigui necessari. SAML continua sent obligatori quan l'IdP d'un client corporatiu només parla SAML; per a aplicacions noves, OIDC és més simple i està millor adaptat a APIs i mòbils. Keycloak parla tots dos, així que el panell d'operadors de Quilòmetre Zero podria fer servir SAML si demà s'integra amb un IdP corporatiu extern, i OIDC avui.

OAuth 2.0 (RFC 6749, 2012) va néixer per a un problema diferent de l'autenticació: delegar accés. L'Anna vol que una app de tercers llegeixi les seves comandes de Quilòmetre Zero sense donar-li la seva contrasenya. OAuth defineix com aquesta app obté un token d'accés limitat (a certs scopes, durant cert temps) amb el consentiment de l'Anna. Que després es faci servir com a base de l'autenticació és obra d'OpenID Connect (apartat 6).

Rols:

Els scopes són cadenes que acoten el permís: comandes:llegir, comandes:crear, repartiment:posicio. El token porta els scopes concedits i el resource server els comprova. Els tipus de client: confidencial (pot guardar un secret: un servei de backend) i públic (no pot: una SPA al navegador, una app mòbil; qualsevol secret incrustat és extraïble).

La raó de PKCE mereix aturar-s'hi. En un mòbil, l'IdP retorna el codi a l'app mitjançant un URL personalitzat (km0://callback?code=...), i una altra app maliciosa podria registrar el mateix esquema i capturar-lo. Amb PKCE, el codi només serveix juntament amb el code_verifier original, que mai no ha sortit de l'app legítima. En una SPA, protegeix igualment contra un codi robat per un script o pels logs d'un proxy.

OpenID Connect (OIDC, 2014) afegeix a OAuth 2.0 el que li faltava per autenticar: un ID token (un JWT, exactament els de 06-01, signat per l'IdP) amb claims sobre qui és l'usuari i com s'ha autenticat, un endpoint userinfo per obtenir més atributs, i descobriment automàtic de la configuració.

• ID token: claims iss, sub, aud (= client_id), exp, iat, més auth_time, nonce (antirepetició, generat pel client), amr (mètodes: pwd, otp), i de perfil (email, name, preferred_username) segons els scopes openid profile email. Va adreçat al client: li diu qui ha entrat.
• Access token: continua sent el d'OAuth, adreçat als resource servers (aud: [comandes, inventari]). Keycloak també l'emet com a JWT RS256 amb els rols del realm, que és el que l'AuthInterceptor de 06-01 verifica. No s'ha de fer servir l'ID token per cridar les APIs, ni l'access token per saber qui hi ha a la web.
• Discovery: GET https://identitat.km0/realms/km0/.well-known/openid-configuration retorna un JSON amb tots els endpoints (authorization_endpoint, token_endpoint, userinfo_endpoint, jwks_uri, end_session_endpoint) i els algorismes suportats.
• JWKS (JSON Web Key Set): jwks_uri publica les claus públiques de signatura de l'IdP, cadascuna amb el seu kid. Això substitueix el fitxer .pub copiat a mà de 06-01: els serveis descarreguen les claus, les guarden a la memòria cau, i quan veuen un kid desconegut les refresquen. La rotació de claus de signatura passa a ser automàtica.

El flux complet amb authorization code + PKCE, a Quilòmetre Zero:

Fixa't que web-km0 és un client confidencial (té backend i secret) i tot i així fa servir PKCE: no costa res i OAuth 2.1 ho exigeix. app-repartidors és públic i fa servir només PKCE.

No competeixen: el patró habitual és LDAP darrere de l'IdP, SAML o OIDC davant, i OIDC per a tot el que és nou.

Federar és acceptar identitats d'un altre IdP. Keycloak actua com a broker: la Formatgeria Montblanc prem "Entra amb Google", Keycloak redirigeix a Google (que és al seu torn un IdP OIDC), rep l'ID token de Google, el verifica, i crea o enllaça un compte local al realm km0 amb sub propi. Les aplicacions de Quilòmetre Zero només veuen tokens de Keycloak: no saben ni els importa si l'usuari ha entrat amb contrasenya, amb Google o amb Apple.

Avantatges: menys contrasenyes per gestionar, registre amb un clic, MFA delegada al proveïdor social. Precaucions: el correu no verificat d'alguns proveïdors no s'ha de fer servir per enllaçar automàticament amb un compte existent (un atacant registra al proveïdor X un correu aliè i hereta el compte); Keycloak l'obliga a verificar. I els comptes d'empleats no es federen mai amb proveïdors socials: vénen del LDAP corporatiu, amb MFA obligatori.

Una identitat no és un registre estàtic:

• Alta (onboarding): els clients s'autoregistren (amb verificació de correu); els productors són aprovats per un operador (rol productor i grup del productor, apartat 10); els empleats apareixen a LDAP des de RR. HH. i Keycloak els sincronitza. SCIM (System for Cross-domain Identity Management) és l'estàndard REST perquè un sistema de RR. HH. o un IdP creï, modifiqui i elimini usuaris a altres aplicacions automàticament; és el que evita l'"algú l'ha de donar d'alta a mà a cinc llocs".
• Canvis de rol: la Marta passa d'atenció al client a operacions: canvia el seu grup a LDAP, Keycloak ho reflecteix a la següent sincronització o al següent login, i el seu proper token porta els rols nous. Amb tokens de 15 minuts (06-01), la latència màxima és aquesta.
• Baixa (offboarding): desactivar a LDAP o a Keycloak, revocar sessions i refresh tokens. Els access tokens vius caduquen en minuts. És la raó per la qual les baixes es fan a l'IdP i mai aplicació per aplicació.
• Revisió periòdica (access review): llistar qui té operador i confirmar que continua sent cert. Els permisos només creixen si ningú no els revisa.
• MFA: obligatòria per a operadors i productors (TOTP amb una app, o WebAuthn/passkeys); opcional però fomentada per als clients. Es configura un cop a l'IdP i s'aplica a tot. Keycloak la imposa per flux d'autenticació i per rol.
• Recuperació: el punt més atacat. Enllaç d'un sol ús per correu amb caducitat curta, mai preguntes de seguretat, verificació addicional per a comptes amb MFA (codis de recuperació), i registre de cada recuperació a l'auditoria de 06-05. Un flux de recuperació feble anul·la la millor MFA.

Afegim dos serveis a docker-compose.yml. Keycloak necessita la seva pròpia base de dades; OpenLDAP s'inicialitza amb un LDIF amb els empleats d'exemple:

start-dev i --hostname=http://localhost:8080 són de desenvolupament: en producció, Keycloak va darrere de TLS amb start i un hostname real. El fitxer identitat/empleats.ldif crea l'arbre de l'apartat 3:

I el realm, exportat a identitat/realm-km0.json (Keycloak l'importa en arrencar). L'essencial, en forma de taula perquè el JSON complet ocupa centenars de línies:

Amb docker compose up -d keycloak openldap, la consola a http://localhost:8080 mostra el realm km0, i curl http://localhost:8080/realms/km0/.well-known/openid-configuration retorna el document de discovery. En Jordi i la Marta apareixen com a usuaris federats des de LDAP, amb el rol operador heretat del grup; cap contrasenya seva no és a Keycloak.

El serveis/identitat/tokens.py de 06-01 queda retirat: Keycloak emet. El que sobreviu és serveis/comu/auth.py, amb una única modificació: en lloc del .pub en fitxer, fa servir el JWKS.

L'AuthInterceptor d'inventari i el decorador requereix_rol no canvien ni una línia: els tokens de Keycloak porten roles i productor_id gràcies als mappers.

Aquest mòdul és el que fa servir el backend de web-km0 (i, amb les diferències comentades, l'app de repartidors). S'implementa amb requests perquè es vegi cada pas; authlib ho embolcalla en tres crides i és el que es faria servir en producció.

Integrat a Flask, /login crida iniciar_login, desa pendent a la sessió i redirigeix; /callback crida completar_login, desa sub, access_token i refresh_token a la sessió de servidor (Redis, 06-01) i redirigeix a la pàgina. El navegador només té la galeta HttpOnly de la sessió.

Comprovació ràpida des del terminal, amb un usuari anna creat al realm:

Quan comandes actua per si mateix (compensació d'una saga, reconciliació nocturna), no hi ha cap token d'usuari per reenviar. Demana el seu:

El token resultant té sub: service-account-comandes-servei, roles: [svc-comandes], aud: inventari. A ROLS_PER_METODE d'inventari (06-01) s'afegeix svc-comandes a ReservarEstoc i AlliberarReserva. És la primera identitat de màquina real de la plataforma; 06-04 la reforçarà amb un certificat en lloc d'un client_secret.

Els serveis no haurien de parlar amb LDAP (ho fa Keycloak), però un operador sí que necessita de vegades consultar el directori: per exemple, un script intern que llista qui és a operadors per a la revisió d'accessos de l'apartat 9.

Dos detalls de seguretat al codi: el filtre de cerca es construeix amb valors controlats (grup ve d'un argument de l'script); si vingués d'una entrada d'usuari caldria escapar-lo (ldap3.utils.conv.escape_filter_chars) per evitar la injecció LDAP, l'equivalent de la injecció SQL. I el compte tècnic és de només lectura: si algú roba nomes-lectura, pot llistar empleats però no modificar grups.

• Fer servir l'ID token per cridar les APIs (o l'access token per identificar l'usuari a la web). L'ID token té aud: web-km0 i comandes l'ha de rebutjar; l'access token pot ser opac en altres IdPs. Cada token per al seu destinatari.
• Ometre state o nonce "perquè ja hi ha PKCE". Protegeixen contra atacs diferents: state contra CSRF al callback (que t'iniciïn sessió al compte de l'atacant), nonce contra la reutilització d'un ID token, PKCE contra la intercepció del codi.
• redirect_uri amb comodins. L'IdP només ha d'acceptar URIs exactes; un comodí permet que el codi acabi en un domini de l'atacant.
• Flux password "perquè és una app pròpia". Anul·la MFA, el consentiment i la federació, i acostuma l'usuari a teclejar la seva contrasenya a apps. Authorization code + PKCE serveix també per a apps natives.
• Secrets de client a apps mòbils o SPAs. Són públics per definició; registra'ls com a públics amb PKCE.
• Aplicacions que fan bind contra LDAP directament. Cadascuna veu contrasenyes i cap no aplica MFA. LDAP darrere de l'IdP.
• Enllaçar comptes socials per correu no verificat. És la via clàssica d'apropiació de comptes.
• Baixes aplicació per aplicació. Una baixa és desactivar a l'IdP (o a LDAP) i revocar sessions; si necessites tocar cinc sistemes, el disseny està malament (SCIM existeix per a això).
• Copiar el JWKS a mà o fixar una sola clau. L'IdP rota claus; fes servir jwks_uri amb memòria cau i refresc per kid desconegut.
• Consell: exporta el realm de Keycloak (kc.sh export) i versiona'l a identitat/realm-km0.json: la configuració d'identitat és codi, es revisa i es desplega igual que la resta.
• Consell: prova el flux amb un IdP real en desenvolupament (Keycloak a Compose), no amb un "mode sense autenticació". Les diferències entre entorns en autenticació són la font clàssica de sorpreses en producció.
• Advertència de compliment normatiu. Les dades d'identitat (correus, noms, grups d'empleats, proveïdors socials enllaçats) són dades personals; el seu tractament, la retenció i la política de MFA i recuperació s'han de revisar amb un professional de seguretat i protecció de dades.

Un repartidor té instal·lada una app maliciosa que registra l'esquema km0:// i captura la redirecció km0://callback?code=XYZ&state=... abans que app-repartidors. Explica què pot fer l'app maliciosa amb aquest codi (a) si app-repartidors fos un client confidencial amb el secret incrustat a l'APK, (b) si fos públic sense PKCE, (c) amb la configuració de l'apartat 10. Indica en cada cas quina comprovació de Keycloak falla o no falla.

La Marta Puig (mpuig) deixa Quilòmetre Zero un divendres a les 17:00. Descriu quines accions fa RR. HH./IT, a quin sistema, i què passa amb: la seva sessió oberta al panell d'operadors, el seu refresh token, un access token emès a les 16:55, el seu compte a la wiki interna (que fa servir SAML contra Keycloak) i els seus permisos a analitica. Què hauria d'existir perquè tot això fos una única acció? I què falla si analitica mantingués la seva pròpia taula d'usuaris?

km0_vendes_diaries (05-05) i el consumidor de Flink de comandes.esdeveniments (05-04) no tenen usuari. Dissenya per a cadascun: el client al realm km0 (nom, tipus, flux, scopes/audiència), els rols de servei, com obtenen i renoven el token, i quina comprovació afegeix inventari o el broker de Kafka. Assenyala quina part d'aquest disseny 06-04 canviarà i per què.

Exercici 1.

(a) L'app maliciosa extreu el secret de l'APK (és trivial), bescanvia el codi amb client_id + client_secret i obté els tokens del repartidor: Keycloak no la pot distingir de l'app legítima; cap comprovació no falla. (b) Sense PKCE, un client públic bescanvia el codi només amb client_id i redirect_uri; l'app maliciosa ho fa abans que la legítima i obté els tokens; la legítima rep un error en intentar bescanviar un codi ja usat, que és l'únic senyal, tardà. (c) Amb PKCE S256 obligatori, el bescanvi exigeix el code_verifier el SHA-256 del qual es va enviar com a code_challenge a la petició d'autorització; l'app maliciosa té el codi però no el verificador (mai no ha sortit d'app-repartidors); Keycloak calcula el hash del verificador que enviï (o en rebutja l'absència) i respon invalid_grant. El codi queda inservible; l'app legítima, si és la primera a bescanviar-lo, entra amb normalitat. state no intervé en aquest atac (protegeix el callback contra CSRF, no contra la intercepció).

Exercici 2.

IT desactiva uid=mpuig a OpenLDAP (o RR. HH. ho fa via SCIM/sincronització des del seu sistema). Keycloak, en mode READ_ONLY amb sincronització periòdica, veu el compte desactivat al següent cicle (o immediatament si IT també el desactiva a Keycloak i en revoca les sessions des de la consola, que és el recomanable). La sessió del panell d'operadors: si el panell guarda una sessió de servidor amb l'access token, continua funcionant fins que el token caduqui (16:55 + 15 min = 17:10 com a màxim) o fins que intenti refrescar; el refresh token va ser revocat en tancar les seves sessions a Keycloak, així que el refresh falla i el panell l'expulsa. La wiki amb SAML: la propera vegada que necessiti reautenticar-se (o immediatament si la wiki rep single logout), l'IdP no l'autentica; la seva sessió local a la wiki dura el que duri la seva galeta, i per això les sessions de les aplicacions SAML es configuren curtes. analitica: si valida tokens de Keycloak, no hi ha res a fer allà. Perquè tot sigui una única acció cal que la baixa es faci només a la font (LDAP/RR. HH.) i que flueixi per sincronització o SCIM fins a l'IdP, amb revocació automàtica de sessions. Si analitica mantingués la seva pròpia taula d'usuaris amb contrasenya, la baixa no hi arribaria: la Marta continuaria entrant a analitica dilluns, que és exactament el motiu de l'apartat 1.

Exercici 3.

Airflow: client airflow-servei, confidencial, només service accounts (client credentials), scope/audiència analitica i hdfs (si el llac es protegeix amb tokens; a la pràctica HDFS fa servir Kerberos, fora del curs), rol de servei svc-analitica-escriptura; el DAG obté el token en un PythonOperator inicial (o un hook que el guardi a la memòria cau com token_de_servei) i, com que les tasques duren més de 15 minuts, el renova per client credentials quan caduca (sense refresh token: client credentials es repeteix). Flink: client flink-comandes-consumidor, confidencial, client credentials, audiència kafka, rol svc-consumidor-comandes; el broker de Kafka es configura amb SASL_SSL i el mecanisme OAUTHBEARER, que valida el JWT contra el JWKS de Keycloak i aplica ACL: aquest principal només pot llegir comandes.esdeveniments amb el seu grup de consumidors, i no escriure enlloc. inventari afegeix svc-analitica-... als mètodes de només lectura si Airflow el consulta. El que 06-04 canvia: el client_secret de tots dos viu avui a la configuració d'Airflow i del job de Flink, és a dir, en un fitxer o variable d'entorn; se substituirà per autenticació amb certificat de client (mTLS) o per un secret injectat i rotat per Vault, i les credencials de PostgreSQL del DAG passaran a ser dinàmiques.

Centralitzar la identitat vol dir que existeix un únic lloc on es decideix qui existeix, com s'autentica i quins atributs té, i que les aplicacions consumeixen proves signades en lloc de contrasenyes. LDAP és el directori: un arbre d'entrades amb dn, unitats organitzatives, grups i bind, ideal com a font d'empleats darrere de l'IdP i pèssim com a protocol de login d'aplicacions. SAML 2.0 és el SSO empresarial per assertions XML, encara necessari per integrar IdPs corporatius. OAuth 2.0 delega accés amb scopes i fluxos, dels quals només tres importen avui (authorization code amb PKCE, client credentials i refresh), i OpenID Connect li afegeix la identitat: un ID token per a l'aplicació, un access token per a les APIs, discovery per configurar-se sol i JWKS perquè la verificació RS256 de 06-01 roti claus sense intervenció. La federació amb identitats socials, el cicle de vida amb SCIM, la MFA per rol i una recuperació acurada completen el quadre. Quilòmetre Zero té ara Keycloak amb el realm km0, els clients web-km0, app-repartidors i comandes-servei, rols i grups per productor, OpenLDAP amb en Jordi i la Marta, oidc_client.py amb PKCE i validació contra JWKS, token_de_servei() per a comandes, i una consulta LDAP per a la revisió d'accessos.

I tanmateix, dues coses continuen sent fràgils. comandes-servei s'identifica amb un client_secret, que és una contrasenya de màquina desada en algun lloc; inventari accepta aquesta identitat perquè el token és vàlid, però no té manera de saber si la connexió TLS que li arriba ve de debò del contenidor de comandes o de qualsevol procés que hagi robat el secret. I la contrasenya de km0_analitica continua en una variable d'entorn del DAG, tal com la va deixar 05-05. La següent lliçó abandona la idea de perímetre: cada servei tindrà el seu propi certificat, cada connexió s'autenticarà en tots dos sentits (mTLS), l'autorització es farà també per identitat de servei, i els secrets deixaran d'escriure's en fitxers per viure a Vault, amb credencials dinàmiques que caduquen soles.