Fase 3.2
Kubernetes Auth

Kubernetes Auth · ServiceAccount Trust

El metodo de autenticacion que permite a los pods demostrar su identidad ante Vault usando su ServiceAccount token. Sin esta configuracion, el Vault Agent Injector no puede recuperar secrets porque Vault no confia en los tokens de Kubernetes.

01

Como Funciona la Autenticacion

Cada pod en Kubernetes tiene un ServiceAccount token montado en /var/run/secrets/kubernetes.io/serviceaccount/token. El Kubernetes Auth de Vault valida este token contra la API de Kubernetes: si el token es valido, Vault asigna al pod las politicas definidas en el role que matchea su ServiceAccount.

Pod presenta su SA token
→
Vault lo reenvia al API Server de K8s
→
API Server valida: token valido + SA existe
→
Vault busca el role que matchea ese SA
→
Vault asigna las politicas del role al token
Vault no genera ni almacena credenciales de Kubernetes. Actua como un federated identity provider: confia en que Kubernetes ya autentico al pod. Si el API Server dice que el token es valido, Vault lo acepta. Esto se llama trust delegation — una practica estandar en seguridad.
02

Configuracion

Tres pasos: habilitar el metodo, configurar la conexion con el API Server, y crear roles que asocien ServiceAccounts con politicas de Vault.

1. Habilitar el metodo

vault (dentro del pod)
vault auth enable kubernetes

2. Configurar la conexion con K8s

Configuracion del endpoint de Kubernetes en Vault
vault auth enable kubernetes

vault write auth/kubernetes/config \
  kubernetes_host="https://kubernetes.default.svc" \
  token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
  kubernetes_ca_cert="@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt" \
  issuer="https://kubernetes.default.svc.cluster.local"

vault write auth/kubernetes/role/grafana \
  bound_service_account_names=grafana \
  bound_service_account_namespaces=aiops \
  policies=grafana-policy \
  ttl=1h

Vault necesita tres datos para validar tokens de Kubernetes: la URL del API Server (kubernetes_host), un token con permisos de TokenReview (token_reviewer_jwt), y el CA certificate para verificar la firma del API Server. En k3s, estos tres valores estan disponibles en /var/run/secrets/ dentro de cada pod.

3. Crear roles

Cada role define que ServiceAccounts (namespace + nombre) pueden autenticarse y que politicas de Vault reciben. Un ServiceAccount que no matchea ningun role es rechazado — no puede leer ningun secret.

03

Roles y Politicas

La asociacion ServiceAccount → Role → Policy es el corazon de la autorizacion en Vault + Kubernetes. Cada capa agrega una restriccion.

ServiceAccount
grafana / aiops
Identidad del pod en Kubernetes
→
Role
grafana
Matchea SA grafana en ns aiops. Asigna policies + TTL.
→
Policy
grafana-policy
Define que paths de Vault puede leer

Ejemplo de Policy HCL

grafana-policy.hcl
path "secret/data/grafana/*" {
  capabilities = ["read"]
}

path "secret/data/n8n/*" {
  capabilities = ["read", "list"]
}

Esta politica permite leer cualquier secret bajo secret/data/grafana/ y listar y leer bajo secret/data/n8n/. El pod de Grafana puede leer sus propios secrets y los de n8n, pero no puede escribir ni acceder a otros paths. Principio de least-privilege.

04

TTL y Renovacion

Los tokens generados por Kubernetes Auth tienen TTL limitado. El Vault Agent (init container o sidecar) los renueva automaticamente antes de que expiren.

1h
TTL del token inicial
Definido en el role (ttl=1h). Despues de 1 hora, el token expira y deja de funcionar.
Auto
Renovacion automatica
El Vault Agent sidecar renueva el token antes de que expire. La app nunca ve un token vencido.
7 dias
Max TTL
Despues de 7 dias, el token no se puede renovar mas. El pod necesita reiniciarse para obtener uno nuevo.

Siguiente: Flujo de Inyeccion

Con el Injector y el metodo de autenticacion configurados, la pagina siguiente recorre el flujo completo end-to-end: desde el kubectl apply hasta el secret en el filesystem del contenedor.

Flujo de Inyeccion