La lección anterior sacó la configuración de tienda-web de la imagen y la puso en un ConfigMap, pero terminaba con una advertencia: un ConfigMap no protege nada. Cualquiera que pueda listar ConfigMaps en rutas-norte-pro lee su contenido íntegro en texto plano. Y la deuda que arrastramos desde el módulo 2 es precisamente de las que no admiten eso: la contraseña de postgres-reservas está escrita en claro en un manifiesto versionado en Git, y esa base de datos guarda el nombre, el DNI, el teléfono y el correo de cada cliente de Rutas Norte. Esta lección la salda con el objeto Secret, pero sobre todo te enseña a no fiarte de él más de lo que merece: verás por qué base64 no es cifrado, por qué el cifrado en reposo de etcd no viene activado por defecto, quién puede leer un secreto sin que te enteres, y qué usa el ecosistema cuando el Secret nativo se queda corto.

Advertencia importante. Esta lección explica los mecanismos que Kubernetes ofrece para gestionar credenciales y te da un punto de partida sólido, pero no sustituye a un diseño de seguridad profesional. postgres-reservas almacena datos personales de clientes reales (nombre, DNI, teléfono, correo), lo que en la Unión Europea entra de lleno en el ámbito del RGPD y, en España, de la LOPDGDD. El diseño concreto de la gestión de credenciales, el cifrado en reposo, la política de rotación, los registros de auditoría y las medidas de seguridad aplicables debe revisarlo y aprobarlo un profesional de seguridad o el responsable de cumplimiento normativo de tu organización. Trata todo lo que sigue como conocimiento técnico necesario, no como una recomendación de cumplimiento.

1. La deuda del módulo 2 y por qué duele
2. Qué es un Secret y en qué se diferencia de un ConfigMap
3. Base64 no es cifrado: la demostración
4. Los tipos de Secret
5. Crear Secrets: imperativo y declarativo con stringData
6. Consumir un Secret como volumen
7. El secreto postgres-reservas-credenciales en Rutas Norte
8. imagePullSecrets para el registro privado
9. Cifrado en reposo en etcd
10. Quién puede leer un secreto
11. Rotación de credenciales
12. Qué no se debe hacer nunca
13. Las soluciones reales del ecosistema

Este es el manifiesto que tenemos hoy en el repositorio de Rutas Norte:

El problema no es solo estético. Enumeremos el daño real:

1. Git no olvida. Aunque borres la línea hoy y hagas commit, la contraseña sigue en el historial. Sacarla de ahí exige reescribir el historial del repositorio (git filter-repo) y forzar el push a todos los clones. En la práctica, una credencial que ha estado en Git se considera comprometida y hay que rotarla, no borrarla.
2. Se propaga sin control. Cada desarrollador que clonó el repositorio tiene la contraseña de producción en su portátil. También la tienen el CI, el sistema de copias del repositorio, el buscador de código interno y cualquier análisis estático que guarde caché.
3. No hay trazabilidad. No existe forma de saber quién ha leído esa contraseña ni cuándo.
4. Rotarla es un despliegue de código. Cambiar la contraseña exige un commit, una revisión, un merge y un despliegue. Eso empuja a no rotarla nunca.
5. Bots automatizados la encontrarán. Si el repositorio llega a ser público un solo minuto, hay rastreadores que localizan credenciales en segundos.

El objetivo de esta lección es que ese manifiesto quede así:

El manifiesto se puede publicar sin filtrar nada. Ese es el listón de los doce factores que veíamos en la lección anterior.

Un Secret es, estructuralmente, casi idéntico a un ConfigMap: metadata más datos, sin spec ni status, con namespace, y con el mismo límite de 1 MiB. La diferencia está en el tratamiento que Kubernetes le da y en las expectativas que crea.

Las tres diferencias que de verdad importan:

Primera: stringData. Es un campo solo de escritura. Escribes en él texto plano y el apiserver lo codifica en base64 y lo mueve a data antes de guardarlo. Es lo que hace tolerable escribir Secrets a mano.

Segunda: el montaje en tmpfs. Cuando un Secret se monta como volumen, el kubelet crea un sistema de ficheros en memoria RAM, no en el disco del nodo. Consecuencia práctica: si el nodo se apaga bruscamente, la credencial no queda escrita en ningún disco recuperable. Es una protección real, aunque limitada.

Tercera: describe no muestra el contenido.

Solo los tamaños. Esto evita el accidente clásico de mostrar la contraseña en una sesión compartida o dejarla en el log de una consola. Pero es un detalle de presentación, no un control de seguridad, como demuestra el apartado siguiente.

Esta es la idea más importante de la lección y hay que interiorizarla haciéndola.

Creamos el Secret:

Lo miramos en YAML:

A primera vista parece cifrado. No lo es. Base64 es una codificación reversible sin clave, diseñada en los años 80 para transportar binarios por canales de texto. Cualquiera puede deshacerla:

Tres segundos y un comando. Ni contraseña, ni clave, ni permisos especiales más allá de poder leer el Secret.

Podemos sacar todo el contenido de golpe:

O, desde Kubernetes 1.30, con el visor incorporado:

Qué implica esto exactamente:

Entonces, ¿para qué sirve base64? Para dos cosas legítimas y ninguna de ellas es seguridad:

1. Permitir contenido binario. Un certificado en formato DER o una clave privada con bytes no imprimibles no cabe en un campo de texto YAML. Base64 lo hace posible.
2. Evitar problemas de escapado. Una contraseña con comillas, saltos de línea o $ rompería el YAML. Codificada, no.

La regla que debes memorizar: un Secret de Kubernetes no protege el dato; lo que hace es darle un lugar donde aplicar controles (RBAC, cifrado en reposo, auditoría, montaje en memoria) y separarlo del manifiesto de la aplicación. La protección la aportan esos controles, no el objeto.

El campo type no es decorativo: determina qué claves exige Kubernetes y qué componentes saben usar el Secret.

Notas de uso en Rutas Norte:

• Opaque es el que usaremos para postgres-reservas-credenciales, para la clave de la pasarela de pago y para el token del proveedor de correo de worker-notificaciones. Es el tipo por defecto si no pones nada.
• kubernetes.io/dockerconfigjson será el que permita descargar imágenes de registry.rutasnorte.example (apartado 8).
• kubernetes.io/tls será el que sostenga el certificado de www.rutasnorte.example. Lo verás en TLS y Certificados, donde cert-manager lo generará y renovará solo.
• kubernetes.io/service-account-token: cuidado con este. Antes de Kubernetes 1.24, cada ServiceAccount tenía asociado un Secret de este tipo con un token sin caducidad. Ya no se crean automáticamente y crearlos a mano es una mala idea salvo casos muy concretos: un token eterno es un token que nunca se puede revocar de forma limpia. El mecanismo actual lo verás en ServiceAccounts.

El tipo también se valida. Esto falla:

El tipo basic-auth exige exactamente la clave username, no usuario. Esa validación es útil: evita que un Ingress o un controlador reciba un Secret con la forma equivocada.

Cuidado con el historial del shell. Ese comando queda escrito en ~/.bash_history con la contraseña dentro. Dos formas de evitarlo:

El printf '%s' en lugar de echo es deliberado: echo añade un salto de línea final que acabaría dentro de la contraseña. Es un error clásico y desconcertante: la contraseña "parece correcta" pero PostgreSQL la rechaza. Si usas echo, pon -n.

Si escribes el manifiesto a mano, usa siempre stringData, nunca data:

Ventajas de stringData frente a data:

• Se escribe y se lee sin codificar ni descodificar nada.
• Elimina el error de codificar con echo sin -n, que mete un \n en el valor.
• Un diff en una pull request es legible... lo cual, ojo, también es el motivo por el que este fichero no puede ir a Git tal cual.

Si una clave aparece en stringData y en data, gana stringData.

Y aquí llega la pregunta obvia: si este fichero no puede ir a Git, ¿dónde vive? Tres respuestas legítimas, en orden de madurez:

1. Solo en el clúster. El fichero se aplica una vez desde un puesto seguro y se destruye. Simple, pero se pierde la trazabilidad y hay que documentar aparte qué claves existen.
2. En Git, cifrado. Sealed Secrets o SOPS permiten versionar un fichero que solo el clúster puede descifrar (apartado 13).
3. Fuera de Kubernetes. Un gestor de secretos externo (Vault, AWS Secrets Manager) es la fuente de verdad y un operador lo sincroniza (apartado 13).

Mientras tanto, lo mínimo imprescindible en el repositorio de Rutas Norte:

Y un secret-postgres.yaml.ejemplo con valores ficticios, versionado, para que el equipo sepa qué claves hacen falta.

El mecanismo es idéntico al de los ConfigMaps de la lección anterior, cambiando configMap por secret y name por secretName:

Dentro del contenedor:

Dos cosas a destacar:

• type tmpfs: el volumen está en memoria RAM. Nunca toca el disco del nodo. Al morir el pod, desaparece.
• La misma cadena de enlaces a ..data que en los ConfigMaps, con la misma consecuencia: si el Secret cambia, el fichero montado se actualiza (con el mismo retardo del kubelet, y con la misma excepción de subPath, que no propaga).

Esa capacidad de refresco es la razón principal para preferir el volumen frente a la variable de entorno cuando se trata de credenciales. Una aplicación bien escrita puede releer el fichero y adoptar una contraseña rotada sin reiniciarse. Volveremos a ello en el apartado 11.

El consumo como variable de entorno (secretKeyRef, envFrom con secretRef) es igual de común y a menudo más práctico, sobre todo con imágenes de terceros como postgres:16, que esperan POSTGRES_PASSWORD en el entorno. Lo verás con todo el detalle en Variables de Entorno. Adelanto la comparación, porque condiciona el diseño:

Muchas imágenes serias admiten la variante _FILE: POSTGRES_PASSWORD_FILE=/etc/secretos/postgres/password. Cuando exista, prefiérela: combina la compatibilidad de la variable con la seguridad del fichero.

Vamos a saldar la deuda de verdad. Diseño completo:

El Secret, en k8s/entornos/dev/secret-postgres.yaml (fuera de Git):

El Deployment de postgres-reservas, ya sin contraseñas en claro:

Y api-reservas, que la consume como fichero:

Fíjate en el detalle de diseño: api-reservas recibe solo username y password gracias a items. No recibe la clave url, que contiene la contraseña duplicada, ni ninguna otra clave que pueda añadirse al Secret en el futuro. Es el principio de mínimo privilegio aplicado al contenido de un objeto.

Verificación de que la deuda está saldada:

grep no encuentra nada en el repositorio y la aplicación tiene su credencial. Ese es el objetivo.

Las imágenes de Rutas Norte viven en registry.rutasnorte.example, que es privado. Sin credenciales, el pod falla así:

ImagePullBackOff con un 401 es siempre lo mismo: faltan credenciales de registro.

Se crea el Secret del tipo adecuado:

Lo que guarda dentro es un fichero .dockerconfigjson:

Otra demostración de que base64 no protege nada: el campo auth es simplemente usuario:contraseña codificado.

Y se referencia en el pod:

Tres detalles importantes:

1. imagePullSecrets va en spec del pod, no dentro de containers. Aplica a todas las imágenes del pod, incluidos los init containers.
2. Se pueden listar varios, uno por registro. El kubelet elige el que casa con el servidor de la imagen.
3. Hay que repetirlo en cada pod del namespace, lo cual es tedioso y fácil de olvidar. La solución elegante es declararlo en la ServiceAccount: todos los pods que la usen lo heredarán sin escribirlo. Lo verás en ServiceAccounts.

Buena práctica de seguridad: el token del registro debe ser de solo lectura de imágenes (pull), nunca uno con permiso de subida. Si el clúster se ve comprometido, un token de pull limita el daño a poder descargar imágenes; uno de push permitiría sustituirlas por versiones maliciosas. La lección de Seguridad de Imágenes profundiza en esto.

Llegamos al punto que más gente desconoce.

Por defecto, los Secrets se guardan en etcd sin cifrar. Codificados en base64, sí; cifrados, no. Quien tenga acceso al disco de un nodo del plano de control, a una copia de seguridad de etcd o a un volcado del sistema de ficheros, tiene todas las credenciales del clúster.

Demostración (en un clúster donde tengas acceso al plano de control):

La contraseña se lee directamente en el volcado. Ni siquiera hace falta descodificar base64: etcd guarda el objeto serializado con los valores ya en binario.

La solución es una EncryptionConfiguration en el apiserver:

Y se activa arrancando el apiserver con --encryption-provider-config=/etc/kubernetes/enc/encryption-config.yaml.

Los proveedores disponibles:

Cuatro reglas críticas:

1. El orden importa. El primer proveedor de la lista es el que cifra al escribir. Todos los de la lista se prueban al leer. Por eso identity debe ir al final durante la migración: permite leer los Secrets que ya existían sin cifrar.
2. Activarlo no cifra lo que ya existe. Solo se cifra lo que se escribe a partir de ese momento. Hay que forzar una reescritura de todo:

3. La clave del fichero es la joya de la corona. Si usas aescbc o secretbox, la clave está en texto plano en el disco del nodo del plano de control. Quien tenga ese fichero y una copia de etcd lo tiene todo. Por eso kms v2 es la única opción realmente sólida en producción: la clave de cifrado de datos se envuelve con una clave que vive en un HSM o en el KMS de la nube y nunca se escribe en el nodo.
4. En Kubernetes gestionado (EKS, AKS, GKE) esto lo activas con una casilla, delegando en el KMS del proveedor. Es una de las razones de peso para usar un clúster gestionado, como verás en 10-06.

Para Rutas Norte, que guarda DNI y datos de contacto de clientes, el cifrado en reposo con KMS no es opcional: es una medida técnica de las que el RGPD espera ver documentada. Y de nuevo: la decisión concreta debe validarla el responsable de cumplimiento.

Un Secret no tiene ninguna protección propia. Todo depende de RBAC, que se estudia a fondo en Control de Acceso Basado en Roles. Aquí basta con entender por qué es inseparable.

Quién puede leer postgres-reservas-credenciales hoy:

Las dos entradas que sorprenden y hay que subrayar:

list filtra los contenidos. Mucha gente concede list secrets pensando que solo permite ver los nombres. No es así: kubectl get secrets -o yaml con permiso de list devuelve los objetos completos, con sus datos. En RBAC, list sobre secretos es equivalente a get.

Poder crear pods equivale a poder leer todos los secretos del namespace. Quien pueda desplegar un pod puede montar cualquier Secret del namespace y volcarlo. No hay forma de evitarlo con RBAC sobre secretos: hay que restringir la creación de pods. Es la razón principal por la que el namespace es la unidad real de aislamiento de credenciales y por la que Rutas Norte separa dev, pre y pro: nadie con acceso de desarrollo debe poder crear pods en rutas-norte-pro.

Un buen ejercicio de auditoría, que anticipa el módulo 8:

Rotar una credencial es cambiarla de forma periódica y, obligatoriamente, cuando se sospecha que se ha filtrado. Y aquí aparece un problema que Kubernetes no resuelve solo.

El problema: un pod que arrancó ayer tiene la contraseña vieja. Si la cambias en el Secret:

• Si la consume como volumen: el fichero se actualiza en un par de minutos. Pero la aplicación solo se enterará si relee el fichero. La mayoría lee al arrancar y guarda la conexión abierta.
• Si la consume como variable de entorno: no se actualiza nunca. Las variables de entorno de un proceso se fijan al ejecutarlo y no hay forma de cambiarlas desde fuera.

La secuencia correcta de rotación, con doble credencial válida, que es lo que evita el corte de servicio:

En comandos:

Un aviso sobre ALTER USER: en PostgreSQL un usuario tiene una sola contraseña, así que el paso 1 la sustituye y los pods viejos se romperán en cuanto abran una conexión nueva. En un sistema con rotación seria se usan dos usuarios (rutasnorte_a y rutasnorte_b) y se alterna entre ellos, que es lo que hacen los motores de secretos dinámicos de Vault. Diséñalo antes de necesitarlo.

Puntos que conviene fijar:

• Automatiza la detección del cambio. La técnica del hash del Secret en una anotación del template, que verás en 03-03, hace que actualizar el Secret dispare el despliegue solo, sin rollout restart manual.
• Rota siempre tras una exposición. Si la contraseña estuvo en Git, rotarla es obligatorio aunque hayas reescrito el historial.
• Vigila los pods rezagados. Un CronJob o un pod que no forma parte de un Deployment no se reinicia con rollout restart. Hazte una lista de consumidores antes de rotar.

Sobre el punto de args, una demostración de lo expuesto que queda:

Cualquiera con permiso de lectura sobre pods —un permiso que se concede a mucha gente, incluidos los sistemas de monitorización— acaba de leer la contraseña del correo.

El Secret nativo resuelve el dónde vive la credencial dentro del clúster. No resuelve cómo llega ahí de forma segura y auditable, ni cómo se versiona, ni cómo se rota sola. Para eso existen estas cuatro familias. No vamos a hacer un tutorial de ninguna —cada una da para un curso—, pero debes saber cuándo mirar hacia cada lado.

Un ejemplo de cómo se ve un ExternalSecret, solo para que reconozcas el patrón cuando te lo encuentres:

Lo elegante del patrón: este fichero sí puede ir a Git. No contiene la credencial, solo dice dónde encontrarla. Y refreshInterval: 1h significa que si alguien rota la contraseña en Vault, el Secret del clúster se actualiza solo en menos de una hora.

Dónde encaja cada cosa en la madurez de una plataforma como Rutas Norte:

1. Hoy (donde estamos): Secrets nativos creados a mano, fuera de Git, con .gitignore y un fichero de ejemplo. Aceptable en dev.
2. Siguiente paso: cifrado en reposo con KMS en el clúster y RBAC estricto sobre secretos en rutas-norte-pro.
3. Madurez: External Secrets Operator apuntando al gestor de secretos corporativo, con rotación automática y auditoría de cada lectura.

Consejos finales:

1. Trata todo Secret como si fuera a filtrarse. Diseña asumiendo que alguien lo leerá: credenciales distintas por entorno y por componente, con el mínimo privilegio en la base de datos.
2. Instala un detector de credenciales en el pre-commit. gitleaks o detect-secrets cuestan diez minutos de configuración y evitan el 90 % de los accidentes.
3. Ten un inventario de secretos. Qué existe, quién lo consume, cuándo se rotó por última vez, quién es el responsable.
4. Documenta las claves, nunca los valores. Un secret-postgres.yaml.ejemplo con password: CAMBIAME versionado es útil y seguro.
5. Y lo dicho al principio: que el diseño lo revise un profesional de seguridad o el responsable de cumplimiento. Con datos personales de clientes, esto no es negociable.

1. Crea un Secret pasarela-pago en rutas-norte-dev con las claves api_key (valor sk_test_4eC39HqLyjWDarjtT1zdp7dc) y entorno (valor sandbox).
2. Muestra el objeto en YAML y comprueba que no se lee el valor.
3. Descodifica api_key con un solo comando encadenado.
4. Comprueba qué muestra kubectl describe de ese Secret y explica por qué eso no es una medida de seguridad.
5. Responde: si un compañero tiene el verbo list sobre secretos en ese namespace pero no get, ¿puede leer la clave? Demuéstralo con kubectl auth can-i.

1. Escribe el manifiesto del Secret postgres-reservas-credenciales para rutas-norte-dev usando stringData, con username, password y database, y con el esquema de etiquetas de Rutas Norte.
2. Modifica el Deployment de postgres-reservas para que tome las tres variables del Secret.
3. Modifica api-reservas para que monte solo username y password como ficheros en /etc/secretos/postgres con permisos de solo lectura.
4. Verifica que el volumen está en tmpfs.
5. Demuestra con grep que en k8s/ no queda ninguna contraseña en claro, y añade las reglas necesarias al .gitignore.

api-reservas corre con 4 réplicas en rutas-norte-pro y hay que rotar la contraseña de la base de datos porque un antiguo miembro del equipo la conocía.

1. Escribe la secuencia completa de pasos, indicando en cuál de ellos hay riesgo de corte y cómo lo evitas.
2. Ejecuta la actualización del Secret con un solo comando que funcione tanto si el Secret existe como si no.
3. Haz que los pods adopten la credencial nueva sin quedarte sin servicio en ningún momento.
4. Verifica que los 4 pods nuevos están arriba y que ninguno conserva la credencial anterior.
5. Identifica qué consumidores del Secret no se reinician con kubectl rollout restart y qué harías con ellos.

Solución 1

La descodificación:

describe solo muestra el tamaño. No es una medida de seguridad, sino de higiene visual: evita mostrar la credencial por accidente en una pantalla compartida o en la salida de un script. Quien tiene permiso para hacer describe tiene el verbo get, y con get -o yaml obtiene el valor. La protección real la dan RBAC y el cifrado en reposo, no el formato de salida.

Sobre list:

Sí puede leerla. list devuelve los objetos completos, no solo sus nombres. Es un error de concesión de permisos muy extendido.

Solución 2

El Deployment de postgres-reservas es el del apartado 7. El fragmento de api-reservas:

Verificación del tmpfs y de que solo hay dos ficheros:

Dos ficheros, no tres: database no se ha proyectado porque no está en items. Y el volumen es tmpfs, es decir, RAM.

Sin resultados. El .gitignore:

La línea !k8s/**/*.yaml.ejemplo permite versionar las plantillas con valores ficticios, que son las que documentan qué claves hacen falta.

Solución 3

La secuencia, con el riesgo señalado:

1. Crear la contraseña nueva en PostgreSQL. Riesgo alto si el motor solo admite una contraseña por usuario: los pods vivos se romperán en la siguiente conexión. Se evita creando un usuario nuevo (rutasnorte_b) en lugar de cambiar el del actual, dejando ambos válidos.
2. Actualizar el Secret. Sin riesgo: los pods vivos ya tienen la credencial cargada en memoria.
3. rollout restart. Sin riesgo si maxUnavailable está bien puesto: el módulo 2 nos garantiza sustitución progresiva.
4. Revocar la credencial vieja. Riesgo si queda algún consumidor sin reiniciar; por eso va después de verificar.

El truco --dry-run=client -o yaml | kubectl apply -f - es el idiomático: genera el objeto y lo aplica, funcionando tanto para crear como para actualizar, cosa que kubectl create solo no hace (fallaría con AlreadyExists).

Los cuatro pods son nuevos (mismo pod-template-hash, AGE menor de un minuto y RESTARTS 0). Verificación de la credencial efectiva:

Consumidores que no se reinician con rollout restart de los Deployments:

• CronJobs como informes-ocupacion (módulo 6): los pods se crean en cada ejecución, así que tomarán la credencial nueva solos; pero si hay una ejecución en curso durante la rotación, fallará. Hay que mirar kubectl get jobs antes de revocar.
• Pods sueltos creados a mano para depurar. Se localizan con kubectl get pods -n rutas-norte-pro -o json | jq '.items[] | select(.metadata.ownerReferences == null) | .metadata.name'.
• StatefulSets (módulo 6): rollout restart funciona, pero es ordinal y más lento; hay que esperar a que termine.
• Clientes fuera del clúster: herramientas de informes, copias de seguridad, cuadros de mando. No los ve Kubernetes y son los que provocan el incidente al revocar. Por eso el inventario de consumidores del apartado 11 no es burocracia.

Has saldado la deuda más grave del módulo 2. La contraseña de postgres-reservas ya no está en ningún manifiesto de Git: vive en un Secret, api-reservas la recibe como fichero montado en memoria con solo las claves que necesita, y postgres-reservas la toma de secretKeyRef para inicializarse. Un grep sobre k8s/ no devuelve nada.

Pero lo importante de esta lección no es el objeto, sino el criterio. Sabes que un Secret se diferencia de un ConfigMap en stringData, en el montaje en tmpfs, en que describe oculta el contenido y en que existe un campo type que valida la forma. Y sabes, porque lo has demostrado con un comando, que base64 no es cifrado: la protección real la aportan RBAC, el cifrado en reposo y el aislamiento por namespaces, no el objeto en sí. Conoces los siete tipos de Secret y para qué sirve cada uno, las tres formas de crearlos, y por qué stringData es siempre preferible a data al escribir a mano.

Sabes que el cifrado en reposo en etcd no viene activado, has visto la contraseña legible en un volcado de etcd, conoces los cinco proveedores de EncryptionConfiguration y por qué kms v2 es el único realmente sólido, y que activarlo no cifra retroactivamente lo existente. Tienes claro quién puede leer un secreto —con las dos sorpresas: list filtra contenidos y poder crear pods equivale a poder leerlo todo—, cómo se rota una credencial sin cortar el servicio y por qué las variables de entorno no se refrescan nunca. Tienes la lista de lo que jamás debe hacerse y un mapa del ecosistema real —Sealed Secrets, SOPS, External Secrets Operator, Vault, los KMS de las nubes— para cuando el Secret nativo se quede corto. Y no olvides la advertencia del inicio: con los datos personales que guarda Rutas Norte, el diseño definitivo debe validarlo un profesional de seguridad o el responsable de cumplimiento.

Las dos lecciones han dejado un cabo suelto común. Hemos visto los objetos que guardan la configuración y los secretos, y una de las formas de llevarlos al contenedor: el fichero montado. Falta la otra, la que aparece en el 80 % de los manifiestos del mundo real y que ambas lecciones han mencionado sin desarrollar. La siguiente, Variables de Entorno, la cubre entera: env, envFrom con prefix, valueFrom con configMapKeyRef y secretKeyRef, el flag optional, la Downward API para que api-reservas registre en sus trazas qué pod y qué nodo atendió cada petición, la expansión $(VAR) y sus reglas, las colisiones cuando la misma clave llega por varias vías, y la técnica del hash de la configuración en una anotación que resuelve de una vez el problema de que las variables de entorno no se refresquen nunca.