Entrevista de Kubernetes: ¿Cómo inyectarías de forma segura variables de entorno en tiempo de ejecución con un init container?

Planteamiento y contexto

Una imagen de aplicación inmutable lee DB_ADDRESS y TENANT_MODE únicamente cuando el proceso se inicia. Para cada Pod, un init container debe generar un archivo de entorno a partir de la configuración del tenant; el contenedor principal debe leer claves seleccionadas sin montar el directorio del escritor. Utiliza EnvFiles y fileKeyRef de Kubernetes, y explica cuándo ConfigMap o Secret sigue siendo la mejor opción.

La documentación de Kubernetes v1.35 lista EnvFiles como Beta y habilitado de forma predeterminada; el servidor debe ser al menos v1.34. Este no es un mapeo de archivo a entorno en vivo: el kubelet lee el archivo mientras se inicializa el contenedor, y las variables resultantes permanecen fijas para ese contenedor.

Qué evalúa el entrevistador

• ¿Puedes rastrear los datos desde un initContainer a través de emptyDir, fileKeyRef y el kubelet?
• ¿Puedes distinguir entre un fallo de admisión del Pod, un fallo de init, un fallo por clave faltante y cambios en el archivo después de que el proceso principal se haya iniciado?
• ¿Puedes describir con precisión la sintaxis del archivo env, optional, las restricciones de ruta y si el consumidor debe montar el volumen?
• ¿Puedes razonar sobre valores sensibles, acceso al nodo, exposición en registros (logs) y el balance frente al uso de Secret?
• ¿Puedes diseñar compuertas de versión (version gates), observabilidad, despliegue y rollback en lugar de limitarte a presentar un YAML?

Preguntas para aclarar primero

• ¿Qué versiones de Kubernetes se ejecutan en el control plane y en los nodos, y está habilitado EnvFiles en el clúster de destino?
• ¿La configuración es una captura instantánea (snapshot) de inicio o debe recargarse en caliente (hot-reload)? Si se requiere recarga en caliente, ¿puede la aplicación observar un archivo o reiniciarse de forma segura?
• ¿Qué init container crea el archivo, y su fallo debe mantener el Pod no listo (unready) y bloquear el contenedor principal?
• ¿Los valores incluyen contraseñas, tokens o datos personales? ¿Cuáles son los límites de confianza del administrador del nodo y del recolector de logs?
• Si falta una clave o está duplicada, ¿debe fallar todo el Pod o existe un valor predeterminado seguro?

Respuesta en 30 segundos

"Verificaría la versión del servidor y la feature gate EnvFiles, y luego usaría un emptyDir para que un init container genere un archivo KEY=value controlado. El contenedor principal lee las claves seleccionadas con env.valueFrom.fileKeyRef y no monta el volumen de escritura; si falta una clave requerida, se impide el inicio. El valor se inyecta únicamente al inicio del contenedor, por lo que cambios posteriores en el archivo no actualizan el entorno. Para valores sensibles se debe preferir Secret; EnvFiles aborda snapshots de inicio locales al Pod, con comprobaciones de versión, métricas, logs censurados y un rollback mediante canario."

Análisis detallado paso a paso

1. Confirmar capacidad y compatibilidad. Kubernetes documenta EnvFiles como Beta en v1.35 (habilitado por defecto), con un servidor mínimo v1.34. Agrega validaciones de admisión y de release para las versiones de API, kubelet y nodos; los clústeres con versiones mixtas deben probarse contra el nodo más antiguo.

1. Generar el archivo durante la inicialización. Utiliza un emptyDir en el Pod. El init container lo monta, valida las claves permitidas y requeridas, la versión de origen y los permisos; luego escribe un archivo temporal y lo renombra atómicamente. Si el init container falla, el contenedor principal no se inicia.

1. Seleccionar solo las claves requeridas. El fileKeyRef del contenedor principal especifica un volumeName, un path relativo y un key. optional: false (el comportamiento predeterminado) requiere el archivo y la clave; usa optional: true solo cuando exista un valor por defecto seguro. El contenedor principal no necesita montar el volumen, reduciendo el acceso a claves no relacionadas.

apiVersion: v1
kind: Pod
metadata:
  name: envfile-demo
spec:
  restartPolicy: Never
  initContainers:
    - name: render-config
      image: busybox:1.36
      command: ["sh", "-c", "printf \"DB_ADDRESS='db.internal'\\nTENANT_MODE='isolated'\\n\" > /config/.env.tmp && mv /config/.env.tmp /config/runtime.env"]
      volumeMounts:
        - name: runtime-config
          mountPath: /config
  containers:
    - name: app
      image: example/app:2026-08-01
      env:
        - name: DB_ADDRESS
          valueFrom:
            fileKeyRef:
              volumeName: runtime-config
              path: runtime.env
              key: DB_ADDRESS
              optional: false
        - name: TENANT_MODE
          valueFrom:
            fileKeyRef:
              volumeName: runtime-config
              path: runtime.env
              key: TENANT_MODE
              optional: false
  volumes:
    - name: runtime-config
      emptyDir: {}

1. Definir el ciclo de vida. El kubelet lee el archivo mientras inicializa el contenedor y establece el entorno. Reescribir runtime.env después de que el proceso ha iniciado no modifica su DB_ADDRESS existente; nuevos valores requieren un nuevo Pod o un mecanismo de recarga en caliente a nivel de aplicación.

1. Establecer el límite de seguridad. emptyDir no proporciona las protecciones de Secret, y un lector del sistema de archivos del nodo podría acceder al directorio del Pod. No registres valores altamente sensibles en los logs. Utiliza Secret, credenciales de corta duración y RBAC de mínimo privilegio para las claves, y restringe los roles que puedan inspeccionar archivos del nodo o datos de depuración del Pod.

1. Observar y revertir (rollback). Registra la versión de la configuración, el código de salida del init, eventos de claves faltantes, tiempo de inicio del Pod y estado de readiness mientras censuras los valores. Despliega primero en un conjunto reducido mediante canario. Si la plantilla o la feature gate son incompatibles, vuelve a las referencias de ConfigMap/Secret o a la imagen anterior y reemplaza los Pods que lleven el snapshot defectuoso.

Respuesta modelo

Mantendría la generación dentro del init container. Este lee la configuración autorizada del tenant, valida el conjunto de claves y la versión, escribe un archivo temporal y lo renombra atómicamente en emptyDir. El contenedor de la aplicación consume solo DB_ADDRESS y TENANT_MODE mediante fileKeyRef y no monta el volumen; las claves requeridas permanecen como optional: false, por lo que los fallos de inicialización o de claves detienen el Pod durante el proceso de arranque.

El pipeline de admisión y release requeriría un servidor al menos en v1.34 y verificaría el comportamiento Beta de EnvFiles en v1.35. Estas variables son snapshots de inicio, por lo que la configuración dinámica debería utilizar un observador de archivos soportado por la aplicación, un servicio de configuración o un reinicio progresivo (rolling restart). Las contraseñas y los tokens deben utilizar Secret en lugar de tratar a emptyDir como almacenamiento de secretos. La observabilidad registra versión, estado y resúmenes criptográficos censurados, con un despliegue canario y una ruta probada para volver a la plantilla anterior.

Errores comunes

• Síntoma: Montar todo el emptyDir en el contenedor principal → Por qué falla: La aplicación puede leer claves no relacionadas, aumentando la superficie de exposición → Solución: Inyectar solo las claves requeridas con fileKeyRef.
• Síntoma: Esperar que el proceso reciba nuevos valores tras reescribir el archivo → Por qué falla: Las variables de entorno se crean al inicio del contenedor → Solución: Hacer un roll del Pod o utilizar un mecanismo de configuración con recarga en caliente.
• Síntoma: Escribir contraseñas en emptyDir y tratarlo como un Secret → Por qué falla: El acceso al nodo y a la depuración todavía permite leer el archivo → Solución: Usar Secret, credenciales de corta duración y el principio de mínimo privilegio.
• Síntoma: Ignorar optional y la validación de claves → Por qué falla: Un Pod podría iniciarse con una configuración vacía o fallar solo en los logs de la aplicación → Solución: Hacer que las claves requeridas no sean opcionales y fallar durante la inicialización.

Preguntas de seguimiento y respuestas

¿Cómo se compara EnvFiles con ConfigMap y Secret?

EnvFiles es adecuado para configuraciones derivadas locales al Pod generadas durante el inicio. Utiliza ConfigMap para valores estáticos no sensibles y Secret para valores sensibles. Para actualizaciones en vivo, utiliza un observador de archivos compatible con la aplicación o un servicio de configuración; las variables de entorno no cambian automáticamente.

¿Qué sintaxis se acepta en el archivo?

Usa el formato de archivo env de Kubernetes como VAR='value'; las líneas en blanco, los espacios iniciales y los espacios alrededor de = siguen las reglas documentadas. No asumas que se acepta cualquier extensión de POSIX shell; prueba el parseo en la versión de Kubernetes de destino.

¿Qué restricciones de ruta aplican a fileKeyRef?

path debe ser relativo y no puede contener .. ni comenzar con ... Una clave faltante bloquea el inicio normal cuando la referencia no es opcional. Mantén el nombre del archivo fijo dentro del volumen en lugar de concatenar entradas del tenant en una ruta.

¿Cómo demuestras que no se expusieron valores sensibles?

Inspecciona logs de init y de la app, Events, endpoints de depuración, permisos de nodo y recolectores de respaldo; registra solo nombres de claves, versiones y resúmenes irreversibles. Si los administradores del nodo forman parte del modelo de amenazas, Secret no elimina la confianza requerida en el nodo; restringe también el acceso al nodo y a las operaciones.

Referencias

• Define Environment Variable Values Using An Init Container (Definir valores de variables de entorno mediante un init container)
• Kubernetes v1.34: Use An Init Container To Define App Environment Variables (Kubernetes v1.34: Uso de un init container para definir variables de entorno de la app)
• Feature Gates (Compuertas de características)
• Pod API Reference: FileKeySelector (Referencia de la API de Pod: FileKeySelector)

Lista de verificación para la entrevista

Comienza con el init escribiendo en emptyDir, el uso de fileKeyRef a nivel de clave y el snapshot de inicio. Luego aborda las compuertas de versión, la semántica de fallos, el límite de seguridad y la ruta de actualización. No describas EnvFiles como recarga en caliente ni como un reemplazo de Secret.

Conclusión en una frase

EnvFiles conecta la configuración de inicio generada por el Pod con las variables de entorno del contenedor, pero una respuesta sólida debe incluir la validación de claves, el momento de inicio, la confianza en el nodo y la ruta de actualización de la configuración.