Cerrábamos la lección anterior con una observación incómoda: hemos dado a los componentes de Rutas Norte su configuración, sus credenciales y sus recursos, pero no les hemos dado identidad. Ahora mismo, los pods de tienda-web, api-reservas, postgres-reservas, redis-cache y worker-notificaciones están usando todos la misma ServiceAccount default de su namespace, con un token de acceso a la API de Kubernetes montado dentro que ninguno de ellos necesita y que es lo primero que buscaría un atacante que consiguiera ejecutar código en uno de esos contenedores. Esta lección lo arregla: entenderás qué es una ServiceAccount y en qué se diferencia de un usuario, cómo funcionan los tokens proyectados modernos, por qué automountServiceAccountToken: false debe ser tu opción por defecto, y hablarás con la API desde dentro de un pod con curl para ver con tus ojos tanto una respuesta autorizada como un 403 Forbidden bien merecido.

1. La identidad de una carga de trabajo
2. Usuarios frente a ServiceAccounts
3. La ServiceAccount default y por qué no debe usarse
4. Crear ServiceAccounts dedicadas para Rutas Norte
5. El token proyectado: cómo ha cambiado
6. Qué hay en /var/run/secrets/kubernetes.io/serviceaccount/
7. automountServiceAccountToken: false
8. Hablar con la API desde dentro de un pod
9. El 403 Forbidden y qué significa
10. imagePullSecrets en la ServiceAccount
11. La ServiceAccount dice quién eres, RBAC dice qué puedes hacer
12. Federación de identidad con las nubes

Toda petición que llega al kube-apiserver pasa por tres fases que ya conoces del módulo 1:

Cuando tú ejecutas kubectl get pods, la primera fase se resuelve con el certificado o el token de tu kubeconfig. Pero, ¿y cuando quien pregunta es un pod?

Los casos en que un pod necesita hablar con la API son más comunes de lo que parece:

Y en Rutas Norte hay un caso concreto que llegará en el módulo 6: informes-ocupacion, la tarea nocturna, tendrá que consultar la API para saber cuántas réplicas de api-reservas hubo activas cada hora y correlacionarlo con la ocupación. Necesita identidad y necesita permisos.

Pero la razón principal para estudiar esto no son los pods que sí hablan con la API: son los cinco que no lo hacen y que, sin embargo, llevan encima una credencial válida sin necesitarla. Eso es superficie de ataque gratuita.

Kubernetes distingue dos tipos de identidad, y la diferencia es de fondo:

El primer punto sorprende siempre: Kubernetes no tiene usuarios. No hay una base de datos de usuarios, ni un comando para crear uno. Cuando tu kubeconfig usa un certificado de cliente, Kubernetes lee el campo CN (Common Name) del certificado y lo toma como nombre de usuario, confiando en que la autoridad certificadora del clúster solo firma certificados legítimos. Con OIDC, delega en el proveedor de identidad. La gestión de personas es, deliberadamente, un problema de fuera.

Las ServiceAccounts, en cambio, son objetos de primera clase:

Solo hay una, la default, y todos nuestros pods la están usando. Fíjate en SECRETS 0: es la señal de que estamos en Kubernetes moderno, donde las ServiceAccounts ya no llevan un Secret con un token permanente asociado. Volveremos a ello en el apartado 5.

El nombre completo de una ServiceAccount en el sistema de autorización tiene esta forma:

Ese es el identificador exacto que usarás en los RoleBindings de RBAC, y también el que aparece en los registros de auditoría. Además, toda ServiceAccount pertenece automáticamente al grupo system:serviceaccounts y al grupo de su namespace, system:serviceaccounts:rutas-norte-pro, lo que permite conceder permisos a todas las de un entorno de una vez (algo que casi nunca es buena idea, pero conviene saber que existe).

Cada namespace obtiene una ServiceAccount llamada default en el momento de crearse. Si un pod no especifica ninguna, se le asigna esa.

Cinco razones para no usarla:

Razón 1: es compartida. Todos los pods del namespace tienen la misma identidad. Si mañana informes-ocupacion necesita permiso para leer Deployments y se lo concedes a default, se lo estás concediendo también a tienda-web, a redis-cache y a postgres-reservas. Es lo contrario del mínimo privilegio.

Razón 2: impide la trazabilidad. En el registro de auditoría todas las peticiones aparecen como system:serviceaccount:rutas-norte-pro:default. Ante un acceso sospechoso, no hay forma de saber qué componente lo hizo.

Razón 3: impide revocar de forma selectiva. Si worker-notificaciones se ve comprometido, quieres retirarle los permisos de inmediato. Con la default, retirárselos significa retirárselos a todo el namespace.

Razón 4: monta un token que casi nadie necesita. Por defecto, automountServiceAccountToken es true, así que todos nuestros pods llevan dentro un token válido de la API. Compruébalo:

Un servidor nginx que solo sirve ficheros estáticos tiene ahí una credencial de acceso a la API del clúster. Si alguien encuentra una vulnerabilidad de lectura arbitraria de ficheros en esa aplicación (algo nada exótico), lo primero que hará es leer ese token.

Razón 5: la tentación de darle permisos. Es tan cómodo que, en un apuro, alguien acaba enlazando la default a un ClusterRole potente para "que funcione ya". Y eso no se revierte nunca.

La regla es simple:

Una ServiceAccount por componente, y automountServiceAccountToken: false en todas salvo en las que de verdad hablen con la API.

Empecemos por el objeto. Es de los más simples de Kubernetes:

O de forma imperativa, para generar el YAML:

El plan completo para Rutas Norte, con la decisión razonada para cada componente:

Cinco de seis no necesitan token. Ese es el resultado normal: la inmensa mayoría de las aplicaciones de negocio no hablan con la API de Kubernetes. Y aun así, la configuración por defecto se lo monta a todas.

¿Y por qué crear una ServiceAccount para los que no la usan, si no van a hablar con la API? Por tres motivos:

1. Trazabilidad: si algún día uno de ellos hace una petición, sabrás cuál.
2. imagePullSecrets: la ServiceAccount es el sitio correcto para declararlos (apartado 10).
3. Preparación: cuando mañana api-reservas necesite un permiso concreto, la identidad ya existe y no hay que tocar el Deployment.

Los seis objetos, en k8s/base/serviceaccounts.yaml:

Y la asignación en el pod, con el campo serviceAccountName:

Un detalle histórico que verás en manifiestos antiguos: existe también un campo serviceAccount (sin Name). Está obsoleto desde hace muchas versiones y solo se conserva por compatibilidad. Usa siempre serviceAccountName.

Aplicamos y verificamos:

Cada componente con su identidad. Y el token ha desaparecido de donde no hacía falta:

Ese error es exactamente el resultado deseado. No hay credencial que robar.

Esta parte tiene historia y es importante conocerla, porque encontrarás manifiestos y tutoriales de la época anterior.

Al crear una ServiceAccount, un controlador generaba automáticamente un Secret de tipo kubernetes.io/service-account-token con un JWT dentro. Ese token:

• No caducaba nunca.
• No estaba ligado a ningún pod: quien lo copiara podía usarlo desde cualquier sitio, incluso desde fuera del clúster.
• Se guardaba en etcd, así que estaba en las copias de seguridad.
• No se podía revocar sin borrar el Secret y la ServiceAccount.

Era, en la práctica, una contraseña eterna en cada namespace. Si un token se filtraba en un log, en un volcado o en un repositorio, seguía siendo válido meses después.

El mecanismo actual es completamente distinto y mucho mejor:

Las propiedades del token moderno:

Veamos el contenido real de un token. Dentro de un pod que sí lo tenga montado:

Es un JWT estándar. Lo relevante:

• sub es el identificador que usará RBAC.
• exp - iat = 3600 segundos: una hora de vida.
• kubernetes.io.pod ata el token a un pod concreto. Si ese pod se borra, el apiserver rechaza el token aunque no haya caducado.
• aud limita para quién es válido.

Un aviso práctico importante: si tu aplicación lee el token una vez al arrancar y lo guarda en memoria, dejará de funcionar en una hora. Las bibliotecas cliente oficiales (client-go, kubernetes de Python, etc.) releen el fichero automáticamente. Si hablas con la API con curl o con una biblioteca HTTP genérica, tienes que releer el fichero en cada petición. Es una fuente de errores 401 desconcertantes que aparecen exactamente una hora después del despliegue.

Se puede personalizar la proyección con un volumen explícito:

El campo audience es especialmente útil para un patrón avanzado: emitir un token que solo sirva ante un servicio externo concreto, de modo que si se filtra no valga para hablar con la API de Kubernetes.

Y si alguna vez necesitas un token permanente (integrar una herramienta externa que no puede rotar), hay que crearlo explícitamente:

Evítalo siempre que puedas. Vuelve a introducir todos los problemas del modelo antiguo. Para casos puntuales, la alternativa correcta es pedir un token de vida limitada:

Cuando el token se monta, el directorio contiene tres ficheros:

Reconoces dos cosas de lecciones anteriores: la cadena de enlaces a ..data que permite la actualización atómica (aquí es lo que hace posible la rotación del token) y el tmpfs, es decir, memoria RAM.

El ca.crt es la pieza que suele olvidarse. Sin él, un cliente que hable con https://kubernetes.default.svc no puede validar el certificado del apiserver y hay que recurrir a --insecure, que es exactamente lo que no hay que hacer: sin validación, un atacante con acceso a la red del pod podría suplantar al apiserver y capturar el token.

Junto con las variables KUBERNETES_SERVICE_HOST y KUBERNETES_SERVICE_PORT que Kubernetes inyecta en todos los pods (las viste en la lección de variables de entorno), estos tres ficheros son todo lo necesario para hablar con la API. Es precisamente lo que las bibliotecas cliente llaman configuración dentro del clúster (InClusterConfig).

Este campo se puede poner en dos sitios, y la precedencia importa:

El pod siempre tiene la última palabra. Eso permite el patrón recomendado: poner false en la ServiceAccount como red de seguridad, y true explícito solo en el pod concreto que de verdad lo necesita.

Por qué esto importa tanto, en términos de seguridad: si un atacante consigue ejecutar código en un contenedor —a través de una vulnerabilidad de la aplicación, una dependencia comprometida o una inyección—, lo primero que hace un guion de explotación automatizado es leer ese token y probar qué permisos tiene. Es un paso estándar en cualquier herramienta de escalada de privilegios en Kubernetes.

Comparemos la superficie de ataque:

Sin token, incluso una configuración de RBAC descuidada queda neutralizada para ese pod: no hay credencial con la que ejercerla.

Comprobación del estado en todo el clúster, que es una auditoría que merece la pena hacer:

Los del sistema lo necesitan legítimamente. De Rutas Norte, solo informes-ocupacion. Ese es el objetivo.

Un apunte de operación: si añades automountServiceAccountToken: false a una ServiceAccount, los pods que ya corren conservan su token. El montaje se decide al crear el pod. Hay que recrearlos:

Vamos a hacerlo a mano para entender qué hacen por dentro las bibliotecas cliente. Usaremos informes-ocupacion, el único componente de Rutas Norte que sí necesita hablar con la API.

Paso 1: un pod con la ServiceAccount y el token montado.

Paso 2: preparar las variables dentro del pod.

kubernetes.default.svc es el Service del apiserver, que existe en el namespace default de todo clúster. Cualquier pod puede resolverlo por DNS, como viste en el módulo 2.

Paso 3: la primera petición, al endpoint de versión (que no requiere permisos).

Ha funcionado. Los tres elementos de la petición:

1. --cacert $SA/ca.crt: verifica que el servidor es realmente el apiserver del clúster. Nunca uses -k ni --insecure.
2. Authorization: Bearer $TOKEN: la autenticación. Es el mecanismo estándar de JWT.
3. La URL del Service interno, resuelta por DNS.

Paso 4: preguntar quién soy. Este endpoint es utilísimo para depurar:

Ahí está la identidad completa: el username con el formato que anticipábamos y los tres grupos automáticos. Desde fuera, el equivalente es:

Paso 5: intentar algo que requiere permisos.

Y aquí llega la parte instructiva.

Veamos el cuerpo completo de esa respuesta:

Este mensaje es una pequeña lección en sí mismo. Descompongámoslo:

La distinción entre 401 y 403 es fundamental y hay que tenerla clara:

Si obtienes un 401, el problema está en el token: revisa que lo estés leyendo bien, que no haya caducado (recuerda la hora de vida) y que el pod tenga el volumen montado. Si obtienes un 403, el token es correcto y lo que falta son permisos.

Y ese 403 es exactamente lo que debe pasar ahora mismo. Nuestra ServiceAccount informes-ocupacion no tiene ningún permiso concedido, porque conceder permisos es trabajo de RBAC, y RBAC es el tema de la lección 08-01. Una ServiceAccount recién creada, sin RoleBindings, no puede hacer absolutamente nada más allá de los pocos endpoints públicos como /version.

Esto merece subrayarse porque es el diseño correcto:

Kubernetes deniega por defecto. Crear una identidad no concede ningún permiso. Todo lo que una ServiceAccount pueda hacer tiene que estar concedido explícitamente.

Podemos comprobar los permisos sin hacer la petición, con kubectl auth can-i:

Y la lista completa de lo que sí puede:

Solo lo mínimo: preguntar quién es, preguntar qué puede hacer, y consultar la salud y la versión. Nada de leer pods, ni deployments, ni muchísimo menos los Secrets con la contraseña de postgres-reservas.

Como anticipo del módulo 8, así se vería la concesión mínima que informes-ocupacion necesitará, para que sepas hacia dónde vamos:

Fíjate en el subjects: ahí es donde la ServiceAccount que hemos creado hoy se conecta con los permisos. Las dos piezas encajan, pero son objetos distintos y responsabilidades distintas.

Limpiamos el pod de pruebas:

Recuperamos un cabo suelto de la lección de Secrets. Allí declaramos imagePullSecrets en cada pod para poder descargar imágenes de registry.rutasnorte.example:

Repetirlo en cada Deployment, cada Job y cada CronJob es tedioso y, sobre todo, fácil de olvidar: el fallo aparece semanas después, cuando alguien añade un componente nuevo y se encuentra con un ImagePullBackOff incomprensible.

La ServiceAccount es el sitio correcto:

Y el Deployment queda limpio:

Cómo funciona: cuando se crea un pod, un controlador de admisión copia los imagePullSecrets de la ServiceAccount al spec del pod. Puedes verlo:

El manifiesto no lo tenía y el objeto sí. Es el mismo fenómeno que con el LimitRanger de la lección anterior: un controlador de admisión ha mutado el objeto.

Tres detalles:

1. Se suman, no se sustituyen. Si el pod declara los suyos, se combinan con los de la ServiceAccount.
2. El Secret debe existir en el mismo namespace. Hay que crearlo en cada uno de los tres entornos.
3. No es retroactivo. Los pods ya creados no lo heredan; hay que recrearlos.

Y un truco muy común para no repetirlo por componente: añadirlo a la ServiceAccount default de cada namespace, de modo que cualquier pod que no especifique otra lo herede.

Es útil, pero recuerda que no exime de crear ServiceAccounts dedicadas: imagePullSecrets es lo único razonable que debe llevar la default.

Es la frase que resume la lección y conviene grabarla:

La ServiceAccount es la identidad; RBAC son los permisos. Son dos cosas independientes y ambas hacen falta.

Las combinaciones posibles y lo que significan:

Fíjate en la última fila, porque es la conclusión más importante en términos prácticos: la mejor forma de gestionar los permisos de un pod que no necesita la API es que no tenga token. Ningún RBAC mal configurado puede hacerle daño si no hay credencial que usar.

Lo que queda para 08-01: los objetos Role y ClusterRole (qué verbos sobre qué recursos), los RoleBinding y ClusterRoleBinding (a quién), la agregación de roles, los roles predefinidos del clúster (view, edit, admin, cluster-admin), y la escalada de privilegios que hay que evitar. Todo eso se apoya en la identidad que has creado hoy.

Un último apunte para que sepas que existe, porque es lo que usarás si Rutas Norte pasa a un clúster gestionado.

El problema: informes-ocupacion debe escribir sus informes en un bucket de almacenamiento en la nube (s3://informes-rutasnorte/). La forma antigua sería crear una clave de acceso permanente en el proveedor y guardarla en un Secret. Eso reintroduce todos los problemas que vimos en la lección de Secrets: una credencial estática, que hay que rotar a mano y que no caduca.

La solución moderna se llama federación de identidad de cargas de trabajo: el proveedor de nube confía en el emisor de tokens del clúster de Kubernetes y acepta el token de la ServiceAccount como prueba de identidad, entregando a cambio credenciales temporales.

Cómo se llama en cada proveedor:

Un ejemplo, solo para que reconozcas el patrón:

Con esa anotación, el SDK de AWS dentro del pod obtiene credenciales temporales automáticamente, sin ninguna clave estática en ningún Secret. La ServiceAccount de Kubernetes se convierte en la identidad reconocida también fuera del clúster.

Las ventajas son las mismas que ya conoces del token proyectado: nada permanente, rotación automática, ámbito limitado, y revocación inmediata al borrar la asociación. El detalle de configurarlo en cada proveedor es tema de Kubernetes Gestionado.

Consejos:

1. Crea la ServiceAccount junto al Deployment, en el mismo fichero. Que nunca haya un componente sin identidad propia.
2. automountServiceAccountToken: false por defecto en la plantilla base. Que montar el token sea una decisión consciente, no el comportamiento heredado.
3. Audita periódicamente qué pods llevan token. El comando jq del apartado 7 debería devolver solo componentes del sistema y los que de verdad lo necesitan.
4. Usa kubectl auth can-i --list --as=... en las revisiones. Es la forma rápida de ver los permisos efectivos de una identidad antes de aprobar un cambio.
5. Nunca concedas permisos a la default. Es la vía más rápida a una escalada de privilegios en todo el namespace.

1. Crea las seis ServiceAccounts de Rutas Norte en rutas-norte-pro con el esquema de etiquetas del módulo 2, poniendo automountServiceAccountToken: false en todas menos en informes-ocupacion.
2. Modifica los cinco Deployments existentes para que usen su ServiceAccount y recrea los pods.
3. Demuestra con un solo comando que cada pod usa la suya.
4. Demuestra que tienda-web ya no tiene el directorio del token y que informes-ocupacion sí.
5. Escribe un comando que liste todos los pods del clúster que sí tienen el token montado y explica cuáles de ellos son legítimos.

1. Crea un pod consultor-api con la ServiceAccount informes-ocupacion y el token montado.
2. Desde dentro, consulta /version y /apis/authentication.k8s.io/v1/selfsubjectreviews y muestra la identidad completa.
3. Intenta listar los pods del namespace, captura el código HTTP y el mensaje completo, e identifica en él el verbo, el recurso, el grupo de API y el ámbito.
4. Descodifica la carga útil del token y localiza sub, exp, el pod al que está ligado y su duración en minutos.
5. Intenta hacer la misma petición sin la cabecera Authorization y con un token manipulado (cambia un carácter). Explica los códigos que obtienes en cada caso y por qué son distintos.

Te encargan una auditoría de identidad de la plataforma antes de una revisión de seguridad.

1. Elabora una tabla con los seis componentes indicando: ServiceAccount, si monta token, si tiene imagePullSecrets y qué permisos efectivos tiene.
2. Identifica qué pods del clúster (incluido kube-system) montan token y clasifícalos en "legítimo" o "revisar".
3. Simula un incidente: un atacante logra ejecutar código dentro del contenedor de tienda-web. Enumera qué puede hacer con la configuración actual y qué habría podido hacer antes de esta lección.
4. Explica por qué imagePullSecrets en la ServiceAccount default es aceptable pero conceder permisos RBAC a la default no lo es.
5. Propón tres medidas adicionales de endurecimiento, indicando en qué lección del curso se estudia cada una.

Solución 1

El fichero k8s/base/serviceaccounts.yaml es el del apartado 4. Aplicación y modificación de los Deployments:

La auditoría de tokens montados:

Todos legítimos: CoreDNS vigila Services y Endpoints, kube-proxy también, metrics-server publica una API agregada, el controlador de Ingress lee objetos Ingress, y informes-ocupacion es el nuestro. De Rutas Norte, solo uno de seis.

Solución 2

Dentro del pod:

Descomposición del mensaje:

La carga útil del token:

Sin cabecera y con token manipulado:

La diferencia es sutil e instructiva:

• Sin cabecera → 403. No es que el apiserver no sepa quién eres: te clasifica como el usuario anónimo system:anonymous, que es una identidad válida sin permisos. Es un caso de autenticación exitosa como anónimo y autorización denegada. (Si el clúster tuviera desactivado el acceso anónimo, sí darías 401.)
• Token manipulado → 401. La firma del JWT no valida, así que el apiserver no puede establecer ninguna identidad. Es un fallo de autenticación puro.

Esa distinción es la que te dirá, en un incidente real, si tu problema es la credencial o los permisos.

Solución 3

1. La tabla de identidad:

2. Clasificación de los pods con token, con el comando de la solución 1: todos los de kube-system y el controlador de Ingress son legítimos (necesitan vigilar objetos de la API para funcionar). informes-ocupacion es legítimo y previsto. Si apareciera cualquier otro pod de rutas-norte-*, sería un "revisar" inmediato.

3. El incidente simulado. Un atacante con ejecución de código en tienda-web:

La cuarta fila es la que da la medida del riesgo: en un clúster donde alguien hubiera concedido permisos a la default "para probar", una vulnerabilidad en un servidor de ficheros estáticos habría permitido leer las credenciales de la base de datos con los datos personales de todos los clientes de Rutas Norte. Quitar el token elimina esa ruta por completo.

La última fila señala lo que no resuelve esta lección: la red sigue plana. Cualquier pod del namespace puede abrir una conexión TCP a postgres-reservas:5432. Eso lo cierran las políticas de red.

4. imagePullSecrets en la default es aceptable porque no concede ninguna capacidad a los pods: solo permite al kubelet descargar imágenes del registro privado, que es una operación previa al arranque y no una acción que el proceso del contenedor pueda ejercer. El contenido de ese Secret ni siquiera es visible desde dentro del pod.

Conceder permisos RBAC a la default no lo es porque la default la usa, por definición, todo pod que no especifique otra cosa: cualquier pod nuevo, cualquier pod de depuración, cualquier manifiesto pegado de internet. Un permiso concedido ahí se otorga a un conjunto abierto e impredecible de cargas de trabajo, presentes y futuras. Es lo contrario de una decisión explícita.

5. Tres medidas de endurecimiento adicionales:

Las tres, junto con lo de hoy, forman las capas de una defensa en profundidad: identidad mínima, permisos mínimos, red mínima y contenedor mínimo.

Has cerrado el módulo 3 dando identidad a la plataforma. Sabes que Kubernetes distingue entre usuarios, que no son objetos del clúster y los gestiona un sistema externo, y ServiceAccounts, que sí lo son, tienen namespace y se identifican como system:serviceaccount:<ns>:<nombre>. Conoces las cinco razones para no usar la default —es compartida, impide la trazabilidad, impide revocar de forma selectiva, monta un token que casi nadie necesita y tienta a concederle permisos— y has creado una ServiceAccount dedicada para cada uno de los seis componentes de Rutas Norte, asignándola con serviceAccountName.

Entiendes cómo ha cambiado el token: de aquellos Secrets con JWT eternos, no ligados a ningún pod y guardados en etcd, a los tokens proyectados de la API TokenRequest, que caducan en una hora, los rota el kubelet al 80 % de su vida, están atados al UID de un pod concreto, viven solo en tmpfs y se invalidan al borrar el pod. Sabes qué hay en /var/run/secrets/kubernetes.io/serviceaccount/ —token, ca.crt y namespace— y para qué sirve cada fichero, incluido el ca.crt que evita tener que usar --insecure. Y tienes clara la precedencia de automountServiceAccountToken, con el patrón recomendado: false en la ServiceAccount como red de seguridad y true explícito solo donde de verdad se necesita. En Rutas Norte, cinco de seis componentes ya no llevan credencial alguna dentro, lo que elimina de raíz el primer movimiento de cualquier guion de escalada de privilegios.

Has hablado con la API desde dentro de un pod con curl, montando la petición a mano con la CA, el token y el Service kubernetes.default.svc; has preguntado quién eres con SelfSubjectReview; y has recibido un 403 Forbidden que sabes descomponer en verbo, recurso, grupo de API y ámbito, distinguiéndolo del 401 que señala un problema de credencial y no de permisos. Ese 403 no era un fallo: era la demostración de que Kubernetes deniega por defecto y de que crear una identidad no concede absolutamente nada. Has movido los imagePullSecrets a la ServiceAccount para no repetirlos ni olvidarlos, y sabes que existe la federación de identidad con las nubes para que ni siquiera las credenciales externas tengan que ser estáticas.

Con esto cierras el módulo 3 y la plataforma Rutas Norte está mucho más sana que hace seis lecciones. La configuración vive fuera de la imagen, en ConfigMaps por entorno; la contraseña de postgres-reservas ya no está en Git, sino en un Secret montado en memoria con solo las claves que cada componente necesita; las variables de entorno están catalogadas componente a componente y entorno a entorno, con la Downward API dando trazabilidad a cada petición; los tres entornos tienen cuota y LimitRange, de modo que un error en desarrollo no puede tocar producción; cada pod tiene una clase de QoS asignada con criterio de negocio, con postgres-reservas como Guaranteed y último superviviente; y cada componente tiene su propia identidad ante la API, casi siempre sin credencial montada.

Pero la plataforma sigue teniendo un agujero muy visible: la red es completamente plana. Cualquier pod de rutas-norte-pro puede abrir una conexión a postgres-reservas:5432, y ningún cliente de internet puede llegar todavía a www.rutasnorte.example ni a api.rutasnorte.example, porque nuestros Services son todos ClusterIP y solo existen dentro del clúster. El módulo 4, Redes en Kubernetes, ataca eso de principio a fin: cómo funciona realmente la red del clúster y el modelo de "cada pod con su IP", los tipos de Service más allá de ClusterIP, el DNS interno que llevamos usando sin explicar del todo, los controladores de Ingress que por fin publicarán la tienda y la API en sus dominios, los certificados TLS gestionados automáticamente con cert-manager, y las políticas de red que impedirán que nadie que no sea api-reservas o worker-notificaciones pueda siquiera intentar conectarse a la base de datos con los datos personales de los clientes.