La lección anterior terminó con dos fragilidades. pedidos-servicio se identifica ante Keycloak con un client_secret que vive en un fichero de configuración, e inventario acepta su token sin poder saber si la conexión TLS que le llega sale del contenedor de pedidos o de un proceso cualquiera que haya copiado ese secreto. Y la contraseña de km0_analitica sigue donde la dejó 05-05: en la variable de entorno AIRFLOW_CONN_KM0_ANALITICA, visible para cualquiera que pueda hacer docker inspect o leer el docker-compose.yml. Las dos son la misma enfermedad: la red interna se sigue tratando como un lugar de confianza en el que basta con "estar dentro" para que te crean, y los secretos que permiten estar dentro están repartidos por ficheros, imágenes y entornos.

Esta lección abandona el perímetro. Primero, el principio: zero trust, cada llamada se autentica, se autoriza y se cifra, sin importar de dónde venga. Después, la herramienta para identificar servicios: certificados por carga de trabajo y mTLS, con una PKI interna que los emite y rota automáticamente, y la malla de servicios como forma de obtenerlo sin tocar el código. A continuación, la autorización servicio-a-servicio: qué puede llamar pedidos y qué solo puede leer analitica. Y por último, la gestión de secretos: qué es un secreto, por qué no puede estar en el código, la imagen ni el entorno, y cómo HashiCorp Vault lo custodia, lo entrega y, en el caso de las bases de datos, lo genera bajo demanda con caducidad. El código deja a pedidos e inventario hablando con certificados de ambos lados, a inventario autorizando por identidad de servicio, y al DAG km0_ventas_diarias entrando en km0_analitica con credenciales que Vault crea y destruye por él. El gateway del borde, la limitación de tasa y la auditoría son la lección siguiente.

1. Del perímetro a zero trust
2. Identidad de carga de trabajo: certificados por servicio
3. mTLS: autenticación en ambos extremos
4. PKI interna: CA raíz, intermedia, emisión y rotación
5. Malla de servicios: mTLS sin tocar el código
6. Autorización servicio-a-servicio
7. Amenazas internas y contramedidas
8. Gestión de secretos: qué es un secreto y dónde no va
9. HashiCorp Vault: motores, autenticación, leases y auditoría
10. Inyección de secretos en los servicios
11. Kilómetro Cero: PKI con OpenSSL y gRPC con mTLS
12. Kilómetro Cero: Vault y credenciales dinámicas para km0_analitica
13. Errores Comunes y Consejos
14. Ejercicios
15. Conclusión

El modelo clásico de seguridad es el castillo con foso: un cortafuegos separa "fuera" (hostil) de "dentro" (de confianza), y una vez dentro, los servicios se hablan libremente. La falacia 4 de 01-04, "la red es segura", es exactamente la creencia en que el foso basta. Y no basta, por razones que ya hemos visto acumularse:

• El "dentro" es enorme y heterogéneo: decenas de servicios, cientos de trabajos de Spark y Airflow, contenedores que se crean y destruyen, proveedores de nube, un portátil de desarrollador con VPN.
• Un solo componente comprometido (un catalogo con una dependencia vulnerable, una imagen con una puerta trasera) da acceso lateral a todo: hdfs dfs -rm desde cualquier contenedor, SELECT * en km0_pedidos, publicar en pedidos.eventos.
• Los atacantes con más impacto suelen ser internos, o externos que ya han cruzado el foso: credenciales filtradas, phishing a un operador, un proveedor con acceso.

Zero trust (confianza cero) sustituye "confío porque estás dentro" por "no confío en nadie por su posición en la red": cada petición, también entre servicios internos, debe demostrar quién la hace (autenticación), ser evaluada contra una política (autorización), y viajar cifrada. Los tres pilares ya los tenemos para usuarios (06-01, 06-03) y para el cifrado (06-02); lo que falta es que los servicios tengan identidad propia y verificable, y que nada de ello dependa de secretos esparcidos.

Para que inventario sepa que le habla pedidos, pedidos necesita una identidad de carga de trabajo (workload identity): una credencial ligada al servicio, no a un humano, que no sea una contraseña copiada a mano. La forma más sólida es un certificado X.509 con la identidad del servicio en el SAN: pedidos presenta su certificado, inventario lo verifica contra la CA interna y lee el nombre.

SPIFFE (Secure Production Identity Framework for Everyone) estandariza esto: cada carga de trabajo tiene un SPIFFE ID en forma de URI, spiffe://km0.internal/pedidos, que va en el SAN del certificado (un SVID, SPIFFE Verifiable Identity Document), y SPIRE es la implementación de referencia que emite y rota esos certificados verificando en qué nodo y con qué atributos corre cada proceso (attestation). Istio y otras mallas usan SPIFFE internamente. En Kilómetro Cero usaremos un SAN DNS (pedidos.km0.internal) y un URI SPIFFE en los certificados, para que el código de verificación sirva con cualquiera de los dos.

Lo importante del certificado como identidad, frente a un client_secret:

• La clave privada se genera donde se usa y nunca viaja: la CA solo firma la clave pública. Robar la configuración no da la clave.
• Tiene caducidad corta incorporada (horas o días) y se rota automáticamente: un certificado robado caduca antes de que se pueda explotar mucho.
• La verificación no exige consultar a nadie: cadena de firmas hasta la CA, como en 06-02.
• Vincula la identidad a la conexión, no a un token que se pueda reenviar: con mTLS, inventario sabe que el otro extremo de este socket es pedidos.

En el TLS de 06-02, solo el servidor presentaba certificado. mTLS (mutual TLS) añade que el cliente también lo presente y que el servidor lo verifique. El handshake es el mismo con un paso más:

Qué comprueba cada extremo:

La última fila es una decisión de diseño importante: la revocación de certificados en TLS (listas CRL, consultas OCSP) es lenta y frágil; la práctica moderna es emitir certificados de horas y rotarlos, de modo que revocar sea simplemente dejar de renovar.

mTLS convive con los tokens de 06-01, no los sustituye: el certificado dice qué servicio hace la llamada; el JWT en los metadatos dice en nombre de qué usuario. inventario verá ambos: "pedidos (certificado) reserva stock para u-ana (token)".

Una PKI (public key infrastructure) es el conjunto de CAs, procedimientos y herramientas que emiten, distribuyen y rotan certificados. La de 06-02 (un km0-ca.key en un directorio, firmas a mano con OpenSSL) sirve para aprender, pero no para producción, donde hacen falta:

• CA raíz fuera de línea: su clave privada solo se usa para firmar CAs intermedias, una vez al año, desde un equipo aislado; si una intermedia se compromete, se revoca esa intermedia y se emite otra sin tocar los almacenes de confianza (que contienen solo la raíz).
• CA intermedia en línea: la que firma certificados de servicios cada pocas horas. Tiene que estar automatizada y protegida (HSM en producción exigente, o Vault con su clave sellada).
• Emisión automática: el servicio (o un agente a su lado) genera un par de claves, envía un CSR con su identidad, la PKI verifica que tiene derecho a esa identidad (por su cuenta de Kubernetes, su rol AppRole, su nodo) y firma. Nadie toca openssl a mano.
• Rotación automática: el agente renueva el certificado a los dos tercios de su vida, y el servicio lo recarga sin reiniciar (gRPC y Envoy lo soportan).
• Herramientas: Vault PKI (motor pki de Vault: la CA intermedia vive en Vault y emite por API con políticas por rol), cert-manager (en Kubernetes: un recurso Certificate y el controlador lo emite y renueva, con Vault, una CA propia o Let's Encrypt como emisor), SPIRE, step-ca (smallstep). El apartado 11 hace la PKI a mano con OpenSSL para entender qué automatizan estas herramientas; el apartado 12 configura el motor pki de Vault para que sea él quien emita.

Configurar mTLS en cada servicio, en cada lenguaje, con rotación, es trabajo repetido y propenso a error. Una malla de servicios (service mesh) lo saca del código: junto a cada servicio corre un sidecar (un proxy Envoy) que intercepta todo su tráfico entrante y saliente; el servicio habla en claro con su sidecar en localhost, y los sidecars hablan entre sí con mTLS, con certificados que el plano de control de la malla emite y rota (SPIFFE por debajo). La malla añade además políticas de autorización (apartado 6), métricas, trazas (07-02) y patrones de resiliencia (07-04) sin que pedidos sepa nada.

Istio (Envoy como sidecar o en modo ambient sin sidecar, plano de control istiod, políticas PeerAuthentication y AuthorizationPolicy) y Linkerd (proxy propio en Rust, más ligero, mTLS por defecto) son las dos mallas principales; Consul Connect es la de HashiCorp. Todas presuponen Kubernetes, cuyo despliegue es tema de 07-05: aquí basta con saber que la malla es la forma industrial de obtener lo que en el apartado 11 haremos a mano, y que el precio es un proxy por instancia (latencia de ~1 ms por salto, memoria) y un plano de control que operar.

Cuándo mTLS en el código y cuándo malla: con pocos servicios y un solo lenguaje, en el código (grpcio lo hace bien); a partir de una decena de servicios, o con varios lenguajes, o cuando se quieren políticas y observabilidad uniformes, la malla. Kilómetro Cero, con seis servicios en Python, lo hace en el código en esta lección y evaluará la malla al pasar a Kubernetes.

Con mTLS, inventario sabe que le llama pedidos. Ahora decide si pedidos puede hacer eso. Es RBAC de 06-01 aplicado a identidades de servicio, y la política se expresa como una tabla que, en Kilómetro Cero, vive en el propio servicio (y en la malla, si la hubiera, como AuthorizationPolicy):

Cada celda vacía es una llamada que el servidor rechaza con PERMISSION_DENIED aunque el certificado sea válido y el JWT del usuario también. Con esta tabla, un analitica comprometido puede leer stock y catálogo, y nada más: no reserva, no cobra, no publica pedidos. Es el mínimo privilegio para servicios, y su efecto se mide en el ejercicio 1.

Dos matices. Primero, la identidad de servicio y la de usuario se combinan: ReservarStock exige que el llamante sea pedidos y que el JWT tenga rol cliente u operador; pedidos no puede reservar sin un usuario detrás salvo con su token de máquina svc-pedidos (06-03), que solo vale para LiberarReserva en compensaciones. Segundo, la política debería vivir fuera del código en cuanto crezca (OPA de 06-01, o la malla), pero su semántica es siempre esta tabla.

Un secreto es cualquier dato cuyo conocimiento da acceso: contraseñas de bases de datos, client_secret de Keycloak, claves de API de la pasarela de pago, claves de firma, claves privadas de certificados, KEK del cifrado de campos, tokens de acceso a MinIO, la clave HMAC de eventos. Kilómetro Cero acumula ya más de una docena. Y hay lugares donde no deben estar:

La contraseña analitica:analitica de AIRFLOW_CONN_KM0_ANALITICA está en tres de esas filas a la vez. Lo que se necesita es un sistema que custodie los secretos cifrados, controle quién puede leer cada uno, entregue cada secreto solo al proceso autorizado y solo mientras lo necesite, rote sin intervención y registre cada acceso. Eso es un gestor de secretos.

Vault es el gestor de secretos de referencia fuera de las nubes públicas (y dentro de ellas, cuando se quiere neutralidad). Conceptos:

• Sellado: los datos de Vault están cifrados con una clave maestra que, al arrancar, hay que reconstruir con varias partes (Shamir) o con un KMS de nube (auto-unseal). Un Vault sellado no entrega nada.
• Motores de secretos (secrets engines), montados en rutas:
  • kv (versión 2): pares clave-valor estáticos con versionado: kv/km0/pedidos/keycloak → {client_secret: ...}.
  • database: credenciales dinámicas. Vault tiene un usuario administrador en PostgreSQL y, cuando un cliente autorizado lo pide, ejecuta CREATE ROLE "v-airflow-abc123" WITH PASSWORD '...' VALID UNTIL '...' con los GRANT definidos, devuelve el usuario y la contraseña, y los destruye al expirar el lease. Cada trabajo tiene su propio usuario, efímero y auditable.
  • pki: la CA intermedia del apartado 4: vault write pki_int/issue/km0-servicios common_name=pedidos.km0.internal ttl=24h devuelve certificado y clave.
  • transit: el KMS del envelope encryption de 06-02: Vault cifra y descifra DEKs con claves que nunca salen.
  • Otros: AWS/GCP (credenciales de nube temporales), SSH, RabbitMQ, Kubernetes.
• Métodos de autenticación: cómo un cliente demuestra a Vault quién es: AppRole (un role_id fijo más un secret_id de un solo uso y corta vida que se entrega en el arranque), Kubernetes (el token de la cuenta de servicio del pod, que Vault verifica contra el API server: sin secreto previo), TLS certificates, OIDC/JWT (un token de Keycloak: pedidos-servicio podría autenticarse en Vault con él), AWS/GCP IAM, y userpass/token para humanos y desarrollo.
• Políticas: HCL que dice qué rutas puede leer o escribir cada identidad: path "kv/data/km0/pedidos/*" { capabilities = ["read"] }. Denegación por defecto.
• Leases y renovación: todo secreto dinámico tiene un lease con TTL; el cliente lo renueva mientras lo necesita, o Vault lo revoca al expirar. Revocar un lease revoca la credencial en el sistema destino (el DROP ROLE en PostgreSQL).
• Rotación: para secretos estáticos, kv guarda versiones y el servicio recarga; para la contraseña raíz de PostgreSQL que usa Vault, rotate-root la cambia por una que solo Vault conoce.
• Auditoría: un audit device escribe cada petición y respuesta (con los secretos hasheados) a fichero o syslog: quién pidió qué, cuándo, con qué política. Alimentará la auditoría de 06-05.

Alternativas: AWS Secrets Manager y Parameter Store, Google Secret Manager, Azure Key Vault (gestionados, integrados con IAM de cada nube, con rotación programada para RDS y similares); Kubernetes Secrets (objetos base64 en etcd: útiles como mecanismo de entrega al pod, pero no son un gestor: etcd debe cifrarse en reposo, no hay versionado ni credenciales dinámicas, y cualquiera con acceso al namespace los lee; el patrón habitual es que un operador, External Secrets o el Vault Agent Injector, los rellene desde Vault); SOPS (Mozilla: cifra ficheros YAML/JSON con claves de KMS o age para poder versionarlos; adecuado para configuración, no para credenciales dinámicas); Doppler, Infisical, 1Password Secrets Automation.

Custodiar el secreto no basta; hay que hacérselo llegar al proceso de forma que no reaparezca en los lugares del apartado 8:

La regla: preferir memoria o tmpfs a disco, ficheros a entorno, y leases renovables a valores fijos. Para Airflow, que no es código propio, el patrón es un backend de secretos: Airflow soporta VaultBackend (apache-airflow-providers-hashicorp), con el que PostgresHook(postgres_conn_id="km0_analitica") busca la conexión en Vault en lugar de en la variable de entorno; el apartado 12 lo configura y, además, usa hvac para pedir credenciales dinámicas.

Ampliamos la PKI de 06-02 con una CA de cliente conceptualmente separada (aquí, por sencillez, la misma raíz firma ambos usos, pero el certificado de cliente lleva clientAuth y un SPIFFE ID), y emitimos certificados para pedidos e inventario:

Cada servicio recibe serverAuth y clientAuth porque casi todos son ambas cosas (pedidos es servidor para la web y cliente de inventario). El servidor inventario exige ahora certificado de cliente:

El cliente pedidos presenta el suyo:

Y el interceptor que autoriza por identidad de servicio. gRPC expone el certificado del cliente en context.auth_context(); de él extraemos los SAN y los comparamos con la política del apartado 6:

(Para los métodos de streaming como ObservarCambios se envuelve handler.unary_stream de la misma forma; se omite por brevedad.) Ahora una reserva registra ambas identidades: en ReservarStock, servicio_llamante() devuelve spiffe://km0.internal/pedidos y claims_de(context)["sub"] (06-01) devuelve u-ana. Prueba el rechazo emitiendo un certificado para catalogo (./emitir.sh catalogo) y llamando a ReservarStock con él: PERMISSION_DENIED: spiffe://km0.internal/catalogo no puede invocar ReservarStock. Y sin certificado de cliente (ssl_channel_credentials solo con la CA): el handshake falla antes de llegar a ningún interceptor, con UNAVAILABLE: ... peer did not return a certificate.

En docker-compose.yml, cada servicio monta solo su clave y su certificado más la CA; km0-ca.key no se monta en ninguno. Para no reescribir certificados de 24 horas a mano, el apartado siguiente delega la emisión en Vault.

Configuración inicial, una vez (en producción esto es un script versionado, ejecutado con un token de administración que después se revoca):

Fíjate en rotate-root: tras ese comando, la contraseña cambiame deja de valer y nadie la conoce salvo Vault. Y en secret_id_num_uses=1: el secret_id se entrega al contenedor en el arranque (por el orquestador, o por un operador la primera vez), se canjea por un token de Vault y muere. Lo que queda en la configuración del servicio es el role_id, que por sí solo no sirve de nada.

Cada ejecución de cargar_postgres entra en PostgreSQL con un usuario que no existía diez segundos antes y no existirá diez segundos después; pg_stat_activity y los logs de PostgreSQL muestran v-approle-airflow-escritura-..., distinto en cada run, con lo que "¿quién borró las filas del día 19?" tiene respuesta exacta en el log de auditoría de Vault.

Y la tarea de dags/ventas_diarias.py (05-05) queda así, sin PostgresHook ni conexión configurada en el entorno:

En el docker-compose.yml de Airflow desaparece la línea AIRFLOW_CONN_KM0_ANALITICA: postgresql://analitica:analitica@... y aparece VAULT_ROLE_ID (no secreto) y el montaje tmpfs de /run/secrets. Para las conexiones que Airflow gestiona por su cuenta (WebHDFS, Spark), se configura el backend airflow.providers.hashicorp.secrets.vault.VaultBackend en airflow.cfg, y PostgresHook(postgres_conn_id=...) las buscaría en kv/km0/airflow/connections/<id> de forma transparente.

Para pedidos, el mismo cliente_vault() lee kv/km0/pedidos/keycloak para el client_secret de 06-03 (que por fin no está en el código) y pide su certificado a pki_int/issue/km0-servicios con common_name=pedidos.km0.internal y uri_sans=spiffe://km0.internal/pedidos, renovándolo a las 16 horas: el emitir.sh del apartado 11 queda como referencia didáctica.

• "Es interno, no necesita autenticación". Es la falacia 4 con otras palabras. Cada llamada entre servicios se autentica (certificado), se autoriza (política) y se cifra.
• mTLS con certificado válido pero sin comprobar el nombre. Que el cliente tenga un certificado de km0-ca solo dice que es alguien de la plataforma; analitica no debe poder reservar stock. Extrae el SAN y aplica la política.
• Certificados de un año rotados a mano. Caducan un domingo a las 3:00 y nadie se acuerda. Certificados cortos con emisión y renovación automáticas (Vault PKI, cert-manager, SPIRE).
• Montar la clave de la CA en los servicios "para que se generen su certificado". La clave de la CA solo la tiene la PKI; los servicios envían un CSR.
• Vault en modo dev en producción, o con el token raíz en uso diario. El modo dev es un aula; el token raíz se revoca tras la configuración inicial.
• Un secreto en Vault y una copia "por si acaso" en el entorno. La copia es la que se filtra. Un solo lugar.
• Leases que nadie renueva ni revoca. Una tarea larga muere a mitad porque su credencial caducó; o miles de roles zombis en PostgreSQL porque nadie revocaba. Renovar en tareas largas, revocar al terminar, TTL máximo razonable.
• Kubernetes Secrets como gestor de secretos. Son un mecanismo de entrega en base64; sin cifrado de etcd, sin auditoría por acceso, sin dinámicos. Rellénalos desde Vault o usa el injector.
• Secretos en logs. Un print(creds) para depurar acaba en Elasticsearch. Imprime el nombre de usuario y el lease_id, nunca la contraseña.
• Consejo: activa un escáner de secretos en CI (gitleaks, trufflehog) y un pre-commit hook: el momento más barato para encontrar una clave en el código es antes del commit.
• Consejo: ensaya el "día malo": revoca todos los leases de un rol (vault lease revoke -prefix database/creds/airflow-escritura) y comprueba que el DAG se recupera en el siguiente run pidiendo credenciales nuevas. Un sistema de secretos que nunca se ha rotado en producción no se sabe rotar.
• Advertencia de cumplimiento. El acceso a bases de datos con datos personales (km0_analitica contiene agregados, pero km0_pedidos no) y su auditoría están sujetos al RGPD; los procedimientos de custodia de claves y las políticas de Vault deben revisarse con un profesional de seguridad.

Una dependencia de catalogo incluye código malicioso que ejecuta comandos arbitrarios dentro del contenedor. Enumera qué puede hacer el atacante contra inventario, pedidos, pagos, Kafka, km0_pedidos y Vault (a) con la plataforma tal como estaba al final de 06-03 y (b) con lo implantado en esta lección. Para (b), indica exactamente qué pieza (certificado, política de inventario, política de Vault, ACL de Kafka) bloquea cada intento, y qué sí puede seguir haciendo.

La clave de km0 servicios CA (la intermedia en Vault) se sospecha comprometida. Describe los pasos para sustituirla sin parar la plataforma, en orden, y qué ocurre con las conexiones mTLS existentes y con las nuevas en cada paso. ¿Por qué no hace falta tocar km0-ca.crt en ningún servicio? ¿Qué habría pasado si los servicios hubieran confiado directamente en el certificado de la intermedia en lugar de en la raíz?

El consumidor de Flink de pedidos.eventos (05-04) necesita la clave HMAC de eventos (06-02) para verificar cada envoltura, y corre como un job de larga duración (semanas) en un clúster de Flink. Diseña cómo obtiene la clave de Vault (método de autenticación, política, mecanismo de inyección), cómo se entera de una rotación de la clave sin reiniciar el job, y cómo verifica eventos firmados con la clave anterior durante la transición. Compara con las credenciales dinámicas del DAG: ¿por qué aquí no sirve un lease de 2 horas?

Ejercicio 1.

(a) Al final de 06-03: catalogo está en la red interna y tiene la CA para verificar servidores, pero inventario no exige certificado de cliente; el atacante fabrica un token de usuario no (no tiene la clave privada de Keycloak), pero puede llamar a inventario con cualquier token que capture o, si catalogo tiene client_secret propio en el entorno, obtener un token svc-catalogo y probar ReservarStock (dependería solo de ROLES_POR_METODO); puede publicar en pedidos.eventos (Kafka sin autenticación de productor: eventos falsos, aunque el HMAC de 06-02 los haría rechazar si ya estaba implantado); puede conectarse a km0_pedidos si hay una cadena de conexión en el entorno de catalogo o si Cassandra no exige autenticación; puede leer docker-compose.yml o /proc/*/environ de su contenedor; Vault no existía. (b) Con esta lección: inventario exige mTLS, catalogo tiene certificado (spiffe://km0.internal/catalogo) y la política solo le permite ConsultarStock: ReservarStock, LiberarReserva y AjustarStock fallan con PERMISSION_DENIED (bloquea: PERMISOS_SERVICIO en ServicioInterceptor); pedidos y pagos aplican la misma tabla: catalogo no tiene ninguna celda, todo denegado; Kafka con autenticación por certificado y ACLs: catalogo solo puede leer inventario.alertas, no escribir en pedidos.eventos (bloquea: ACL del broker); km0_pedidos: catalogo no tiene credenciales (no hay cadena de conexión en su entorno; las de pedidos son dinámicas y viven en la memoria de pedidos); Vault: catalogo solo puede autenticarse con su role_id y un secret_id ya consumido; aunque obtuviera un token de Vault, la política catalogo solo le deja leer su propio kv/km0/catalogo/* y emitir certificados con su propio nombre (el rol km0-servicios debería restringirse por AppRole a allowed_domains concretos, o usar un rol por servicio; es una mejora que conviene aplicar). Lo que sí puede hacer: todo lo que catalogo puede: leer todo el catálogo y el stock (ConsultarStock), leer alertas de inventario, generar URLs prefirmadas de km0-fotos (con las credenciales de MinIO de catalogo, que deberían ser también dinámicas o de mínimo alcance), y servir contenido alterado a la web. El radio de daño ha pasado de "toda la plataforma" a "la lista de permisos de catalogo", que es la definición de zero trust.

Ejercicio 2.

(1) Generar una nueva CA intermedia en Vault (pki_int2/intermediate/generate/internal), firmarla con la raíz fuera de línea, instalarla con set-signed, y crear el rol km0-servicios en ella. (2) Cambiar la ruta de emisión que usan los servicios (o el agente) a pki_int2/issue/km0-servicios; a medida que cada servicio renueva (a las 16 h como máximo), obtiene un certificado de la nueva intermedia, cuya cadena incluye el nuevo certificado intermedio. Las conexiones existentes siguen funcionando (TLS no reverifica a mitad de sesión); las nuevas se verifican contra km0-ca.crt, que firma ambas intermedias, así que ambos tipos de certificado son válidos durante la transición. (3) Pasadas 24 horas (el max_ttl), ya no existe ningún certificado de la intermedia antigua; se revoca la intermedia antigua en la raíz (se publica en la CRL de la raíz, si se usa) y se elimina pki_int. (4) Si se quiere tolerancia cero, se puede además añadir la intermedia comprometida a una lista de rechazo en los servidores durante la ventana. No hace falta tocar km0-ca.crt porque los servicios confían en la raíz, y la raíz no se ha comprometido: cualquier intermedia firmada por ella es aceptable, y el certificado de servicio lleva la cadena completa en el handshake. Si hubieran confiado en la intermedia directamente, habría que actualizar el almacén de confianza de cada servicio antes de emitir con la nueva, y con dos intermedias simultáneas durante la transición: exactamente el despliegue coordinado que la jerarquía raíz-intermedia evita.

Ejercicio 3.

Autenticación: el job de Flink corre en un clúster (YARN, Kubernetes o standalone); si es Kubernetes, método kubernetes de Vault con la cuenta de servicio del job (sin secreto previo); si no, AppRole con secret_id entregado por el orquestador al lanzar el job. Política: path "kv/data/km0/comun/eventos" { capabilities = ["read"] } y nada más (Flink no necesita PostgreSQL ni PKI, salvo su propio certificado para Kafka, que sería pki_int/issue/km0-servicios). Inyección: Vault Agent como sidecar (o contenedor auxiliar) que renueva el token, escribe hmac_key en un fichero tmpfs y lo reescribe en cada cambio de versión del secreto en kv; el job lee el fichero en un RichFunction.open() y lo vigila (un hilo que comprueba el mtime cada minuto, o el propio agente que envía SIGHUP). Rotación: el kv v2 guarda versiones; la rotación consiste en escribir la nueva clave como versión N+1 sin borrar la N, y el fichero inyectado contiene ambas (hmac_key y hmac_key_anterior, o un pequeño JSON con kid → clave); los productores firman con la nueva e incluyen un kid en la envoltura; el consumidor verifica con la clave que indique kid, aceptando la anterior durante la retención del tópico (7 días, por ejemplo) y rechazándola después. Comparación: la credencial dinámica del DAG es una identidad temporal para una tarea de minutos; un lease de 2 horas obligaría al job de Flink a reautenticarse y recargar constantemente, y no tiene sentido como modelo: la clave HMAC es un secreto compartido de larga vida que cambia por rotación programada, no una credencial por ejecución. Lo que sí es de corta vida es el token de Vault con el que el agente lee el secreto, y ese sí se renueva cada hora.

Zero trust es la respuesta definitiva a la falacia 4: la red no es segura, así que ningún salto se fía de su posición en ella; cada llamada se autentica, se autoriza y se cifra. La identidad de un servicio es un certificado de corta vida cuya clave nunca sale del proceso, con un nombre (DNS o SPIFFE ID) en el SAN, y mTLS hace que ambos extremos de cada conexión sepan con quién hablan; una PKI con raíz fuera de línea, intermedias en línea y emisión automática (Vault PKI, cert-manager, SPIRE) convierte la rotación en algo que ocurre solo, y una malla de servicios (Istio, Linkerd) lo ofrece sin tocar el código cuando los servicios se multiplican. Sobre esa identidad, la autorización servicio-a-servicio reduce el radio de daño de cualquier compromiso a una fila de una tabla. Los secretos que quedan (contraseñas de bases de datos, claves de API, claves HMAC) salen del código, de las imágenes y de las variables de entorno para vivir en Vault: motores kv, database, pki y transit, autenticación AppRole o Kubernetes, políticas de denegación por defecto, leases con TTL y revocación, auditoría de cada acceso, e inyección en memoria o tmpfs. Kilómetro Cero tiene ahora pedidos e inventario con mTLS y ServicioInterceptor autorizando por SPIFFE ID, Vault en docker-compose.yml, y el DAG km0_ventas_diarias entrando en km0_analitica con un usuario que Vault crea para cada ejecución y destruye al terminar; la contraseña que 05-05 dejó en AIRFLOW_CONN_KM0_ANALITICA ya no existe, y la de analitica_admin solo la conoce Vault.

Todo esto protege el interior. Pero la plataforma tiene un exterior: Internet, desde donde llegan los navegadores de Ana, Marc y Lucía, la app de 140 repartidores, y también los bots, los robos de credenciales y las 40 000 peticiones por segundo de la primera hora de la Semana de la Vendimia. Hasta ahora cada servicio ha hecho su propia terminación TLS, su propia verificación de tokens y su propia defensa. La última lección del módulo construye el borde: una puerta de enlace única que termina TLS, valida tokens, enruta, limita la tasa por cliente con un token bucket en Redis, y deja registro inmutable de quién hizo qué, para cerrar el módulo con la tabla completa de quién puede qué en Kilómetro Cero.