Edera 1.12 lleva identidad de workload a KubernetesEdera 1.12 lleva identidad de workload a Kubernetes

El problema no es guardar un secreto

En Kubernetes seguimos resolviendo demasiadas autenticaciones con variables de entorno, Secrets y credenciales que duran más de lo necesario. Funciona, pero un worker de Laravel, un job de CI y un agente de IA acaban compartiendo patrones de acceso que son difíciles de revisar y de rotar bien. El problema real no es dónde guardo el secreto, sino cómo pruebo que el proceso que lo usa es exactamente el que dice ser.

Edera 1.12 incorpora identidad de workload basada en SPIFFE y SPIRE para sus zonas. La idea es que una carga reciba una identidad verificable vinculada a su ejecución, en lugar de depender únicamente de una clave entregada durante el despliegue. Esa identidad se materializa mediante credenciales X.509 de vida corta, llamadas SVID en el modelo SPIFFE. (docs.edera.dev)

Una identidad para cada carga que la necesite

Edera ejecuta un agente SPIRE dentro de cada zona habilitada para SPIRE, no uno compartido por nodo. Esto importa porque una zona es una máquina virtual aislada y el agente de un nodo convencional no puede inspeccionar directamente lo que ocurre dentro de ella. El servidor SPIRE valida la zona mediante el plugin de atestación edera-hypervisor, que consulta al daemon de Edera. (docs.edera.dev)

La identidad no se entrega por defecto solo por estar dentro de una zona con SPIRE. Al lanzar un workload, --enable-identity monta los certificados y la clave en modo lectura en /run/spire/identity. Si la aplicación ya entiende la Workload API de SPIRE, --enable-spire-access expone su socket en /shared/zone/sockets/agent.sock para que el propio proceso solicite y renueve sus credenciales. (docs.edera.dev)

Qué cambia para una aplicación Laravel

En una aplicación Laravel desplegada en Kubernetes, separaría identidades entre el contenedor web, los workers de Horizon, los jobs puntuales de mantenimiento y los procesos de CI. No todos necesitan acceder a los mismos servicios, aunque todos pertenezcan al mismo repositorio y usen la misma imagen base. Con selectores de workload se puede acotar una identidad a una carga concreta en vez de conceder acceso implícito al resto de procesos de la zona. (docs.edera.dev)

Esto encaja especialmente bien cuando Laravel necesita autenticarse contra un servicio interno con mTLS, una API privada o una infraestructura que ya confía en SPIFFE. El certificado puede proyectarse como archivo para herramientas que esperan una clave y un certificado convencionales. Para clientes que hablen SPIFFE de forma nativa, el socket permite obtener y rotar el SVID sin que la aplicación dependa de copiar ficheros durante el despliegue. (docs.edera.dev)

También me parece útil en un homelab donde mezclo servicios personales, runners y automatizaciones experimentales. Un runner de CI que compila una aplicación no debería heredar las credenciales del worker que procesa pagos, aunque ambos vivan en el mismo clúster. Lo mismo aplica a agentes de IA: aislar el runtime reduce superficie, pero asignar una identidad independiente limita además qué recursos puede solicitar ese runtime.

La configuración mínima que hay que revisar

La documentación indica que SPIRE depende de dos flags alpha en daemon.toml, ambos desactivados por defecto. Después de activarlos hay que reiniciar el daemon, iniciar el servidor con protect-ctl host spire-start y crear las zonas con protect-ctl zone launch --with-spire. No conviene asumir que habilitar el servidor convierte automáticamente todos los workloads en identidades SPIFFE. (docs.edera.dev)

[features]
spire-v0 = "enabled"
object-capabilities-v0 = "enabled"

Para una carga que solo necesite certificados montados, el punto de partida documentado es este. La decisión importante es si el proceso recibirá archivos gestionados por Edera o si necesita hablar directamente con la Workload API. Son permisos distintos y se pueden conceder de forma independiente. (docs.edera.dev)

protect-ctl workload launch --enable-identity

La letra pequeña antes de cambiar secretos

Esto no elimina por arte de magia todos los secretos de una aplicación Laravel. La base de datos, Redis, SMTP o un proveedor externo deben aceptar autenticación basada en certificados, tokens intercambiables o una integración que traduzca esa identidad a un permiso útil. Si un servicio solo entiende una contraseña estática, seguirá haciendo falta resolver esa contraseña de alguna forma.

Tampoco basta con montar un certificado para tener una política de mínimo privilegio. Hay que registrar identidades con selectores suficientemente específicos, porque una entrada basada solo en selectores de zona puede coincidir con todos los workloads de esa zona. Edera advierte además que los selectores de imagen por sí solos no expresan un conjunto cerrado de imágenes; para fijarlo hay que combinarlos con zone-image-count. (docs.edera.dev)

La parte más importante es el estado de madurez. La documentación técnica marca el soporte SPIRE como alpha y avisa de que la identidad de atestación de la zona todavía es autoafirmada por el agente dentro de la zona, por lo que no debe tratarse como una frontera de confianza endurecida. El anuncio de Edera 1.12 también lo presenta como Early Access, así que lo usaría para diseñar, probar integración y detectar dependencias, no como sustitución inmediata de un modelo de producción ya auditado. (docs.edera.dev)

Un buen sitio para empezar

Yo empezaría por un único worker de Laravel que acceda a un servicio interno no crítico mediante mTLS. Es un caso acotado para comprobar el ciclo completo: atestación, emisión, montaje, renovación y revocación de la identidad. Cuando eso esté claro, separar CI, automatizaciones y agentes de IA deja de ser una discusión sobre cuántos secretos repartir y pasa a ser una política explícita sobre qué workload puede hablar con qué servicio.

Fuente: anuncio de Edera 1.12 Documentación oficial: Workload identity with SPIFFE and SPIRE