Fase 3.3
Injection Flow

Flujo de Inyeccion · End-to-End

Nueve pasos desde que el developer hace kubectl apply hasta que el contenedor lee el secret del filesystem. Entender este flujo es entender como funciona la integracion Vault-Kubernetes.

01

Los Nueve Pasos

Cada paso es una pieza del mecanismo de inyeccion. El developer solo ve el paso 1 (el YAML que escribe) y el paso 9 (los secrets en el filesystem). Los pasos 2-8 son responsabilidad de Kubernetes, el Injector y Vault.

1
Developer aplica el Deployment
kubectl apply -f deployment.yml. El pod spec incluye annotations de Vault: agent-inject, agent-inject-secret-*, role.
2
API Server recibe la solicitud
Antes de persistir el pod en etcd, el API Server envia un AdmissionReview al MutatingWebhook registrado por el Injector.
3
Injector inspecciona el pod
Busca annotations vault.hashicorp.com/agent-inject. Si no existen, responde sin cambios. Si existen, procede a modificar el spec.
4
Injector modifica el pod spec
Agrega un volumen emptyDir (vault-secrets), un init container (vault-agent-init) y opcionalmente un sidecar (vault-agent). El contenedor principal original no se modifica.
5
API Server crea el pod modificado
El pod que llega a etcd ya tiene el init container inyectado. El developer nunca ve esta modificacion en su YAML original.
6
Init container arranca
vault-agent-init se ejecuta antes que el contenedor principal. Se autentica con Vault usando el ServiceAccount token. Recupera los secrets declarados en las annotations.
7
Secrets se escriben en disco
El init container escribe cada secret como un archivo en /vault/secrets/. El formato depende de si se uso agent-inject-template o no.
8
Init container termina
El init container sale con codigo 0. El volumen emptyDir con los secrets persiste.
9
Contenedor principal arranca
La aplicacion lee los secrets desde /vault/secrets/. No necesita saber que Vault existe — solo lee archivos.
02

Timeline

En un cluster local con k3s, el proceso completo desde kubectl apply hasta que la app arranca con secrets tarda aproximadamente 4 segundos.

t=0s
kubectl apply enviado
El Deployment YAML llega al API Server.
t=0.1s
Admission webhook triggered
API Server llama al Injector en /mutate.
t=0.2s
Pod spec modificado
Injector agrega init container + volumen al spec.
t=0.3s
Pod creado en etcd
El pod se persiste con las modificaciones del Injector.
t=2s
Init container inicia
vault-agent-init arranca. Se autentica con Vault.
t=3s
Secrets recuperados
Vault devuelve los secrets. El init container los escribe en /vault/secrets/.
t=4s
App container arranca
El contenedor principal inicia. Los secrets ya estan en disco.
03

Resultado en el Filesystem

El resultado final de todo el flujo: archivos en /vault/secrets/ que la aplicacion lee como cualquier otro archivo de configuracion.

dentro del contenedor
$ls -la /vault/secrets/
-rw-r--r-- 1 vault vault 64 May 31 10:00 admin
-rw-r--r-- 1 vault vault 128 May 31 10:00 db
# Contenido del secret grafana admin
$cat /vault/secrets/admin
GF_SECURITY_ADMIN_USER=admin
GF_SECURITY_ADMIN_PASSWORD=s3cur3-p4ss
# El contenedor fuente estas variables en su entrypoint
$source /vault/secrets/admin && ./start.sh
El contenedor no sabe que Vault existe. Desde la perspectiva de la aplicacion, los secrets son archivos en /vault/secrets/. No hay llamadas HTTP a Vault, no hay SDKs, no hay logica de autenticacion. El Injector y el init container abstraen todo eso. Si se migra de Vault a OCI Vault o a AWS Secrets Manager, la aplicacion no cambia — solo cambia el mecanismo de inyeccion.

Siguiente: Dev Mode vs Production

El flujo de inyeccion funciona igual en modo dev y en produccion. La ultima pagina de la Fase 3 detalla que cambia entre ambos modos y como es la transicion a un Vault production-ready.

Dev vs Prod