Entrevista de diseño de sistemas: ¿Cómo diseñarías la identidad federada de cargas de trabajo con SPIFFE?

Problema y contexto

Una empresa ejecuta microservicios multi-tenant en dos nubes y un clúster privado. Diferentes equipos operan cada entorno, y producción debe mantenerse separada de staging. Un servicio de pagos invoca a un servicio de reportes, pero los secretos de API de larga duración y los roles específicos de la nube no se pueden copiar en las imágenes. Diseña la identidad federada de cargas de trabajo entre dominios de confianza.

Las cargas de trabajo necesitan identidades de corta duración y verificables. Los destinatarios deben confiar únicamente en dominios de confianza externos, SPIFFE IDs, audiencias y acciones de negocio aprobados. Cubre la nomenclatura de SPIFFE IDs, SPIRE Server y Agent, atestación de nodos y cargas de trabajo, X.509-SVID o JWT-SVID, obtención de foreign-bundles, mapeo de autorizaciones, rotación, revocación, almacenamiento en caché, recuperación ante desastres y migración desde credenciales estáticas.

Conserva estos invariantes:

1. La fuente de identidad demuestra qué proceso controlado se está ejecutando, no simplemente que una máquina tiene una dirección de red.
2. Un paquete (bundle) de dominio de confianza no otorga automáticamente autoridad local a cada carga de trabajo externa.
3. Un destinatario deja de aceptar un SVID expirado o revocado dentro del límite declarado.
4. Las claves privadas son generadas por la carga de trabajo o por un administrador de claves controlado; el plano de control no distribuye claves privadas de larga duración.
5. La federación intercambia material de identidad y confianza; el servicio de recursos aún realiza la autorización de negocio.

Qué evalúa el entrevistador

Una respuesta sólida traza los límites entre un dominio de confianza, SPIFFE ID, SVID, SPIRE Server, Agent y Workload API. SPIFFE define la nomenclatura de identidades y documentos verificables; SPIRE implementa la atestación de nodos y cargas de trabajo y la emisión de SVIDs. La identidad no es permiso: spiffe://prod.example/ns/payments/sa/worker aún necesita una política de permisos (allow policy) en el servicio de reportes.

La segunda señal es la federación. SPIFFE Federation intercambia material de confianza público a través de un endpoint de paquete configurado y autenticado por TLS. Un destinatario debe saber qué dominio de confianza representa la URL; no debe descargar una raíz para un dominio arbitrario desde una solicitud. La Workload API puede devolver paquetes externos, y un verificador selecciona el paquete que coincide con el dominio de confianza del SVID.

La tercera señal es la cadena de pruebas. La atestación de nodo prueba el nodo del Agent, y la atestación de carga de trabajo compara los atributos confiables del kernel, kubelet o runtime de contenedores contra los selectores de registro. Un namespace, etiqueta o identidad de cliente autoafirmada por sí sola no es suficiente contra una credencial de servicio robada.

Por último, analiza las operaciones: un paquete de federación expirado, rotación de claves raíz, un Agent desconectado, cachés obsoletas, un punto único de falla en el plano de control, desincronización de reloj (clock skew) entre nubes, servicios heredados que no pueden cargar SVIDs y reversión (rollback) sin deshabilitar la verificación.

Preguntas para aclarar primero

• ¿Qué dominios de confianza realmente necesitan confianza? Si pagos solo llama a reportes, no construyas un grafo de confianza totalmente mallado; define un enlace unidireccional o mínimo.
• ¿X.509-SVID o JWT-SVID? mTLS y la identidad de conexión se adaptan a enlaces de servicio de larga duración; HTTP entre nubes o recursos OIDC externos pueden necesitar una audiencia JWT. Sus cachés de validación y ventanas de filtración difieren.
• ¿Quién opera el endpoint del foreign-bundle? Una misma empresa puede compartir la gobernanza; una empresa diferente necesita material público explícito, identidad TLS y mapeo de dominios revisado.
• ¿Cuál es el objetivo de revocación? Por ejemplo, una vida útil máxima de SVID de 15 minutos, sondeo de paquetes cada 60 segundos y bloqueo de nuevas conexiones en cinco minutos tras una revocación de emergencia.
• ¿Cómo se prueba a sí misma una carga de trabajo? Un Kubernetes ServiceAccount, un documento de instancia en la nube, TPM y un token de unión (join token) de un solo uso controlado tienen diferentes supuestos.
• ¿Pueden los servicios heredados consumir SPIFFE? Si no es así, ¿puede un sidecar o gateway traducir de manera restringida? Su identidad y permisos necesitan su propio límite.

Una respuesta en 30 segundos

«Crearía dominios de confianza independientes para producción, staging y on-premise, y asignaría SPIFFE IDs estables que no contengan secretos de tenants. El SPIRE Server de cada dominio posee las entradas de registro. Un Agent prueba su nodo y luego usa atributos de procesos locales para la atestación de cargas de trabajo; la carga de trabajo obtiene un X.509-SVID o JWT-SVID de corta duración desde la Workload API.

El dominio de pagos configuraría únicamente el endpoint del foreign-bundle del dominio de reportes y fijaría (pin) el dominio, la identidad TLS y el mapeo permitido. El servicio de reportes valida la firma, la expiración del SVID, la audiencia y el paquete del par, y luego autoriza el SPIFFE ID completo, el entorno, el contexto del tenant y la acción. Las actualizaciones de paquetes y SVIDs utilizan APIs de streaming, TTLs cortos y métricas de versión. Si el plano de control no está disponible, el material previamente verificado y acotado puede atender tráfico de bajo riesgo, pero las nuevas conexiones de alto riesgo fallan cerradas (fail closed). La migración ejecuta credenciales antiguas y SVIDs en paralelo, realiza despliegues canary por grupo de servicios y elimina los secretos solo después de que se comprueben los objetivos de auditoría y revocación».

Diseño paso a paso

Paso 1: Particionar dominios de confianza y nombrar identidades

Un dominio de confianza es un espacio de nombres de identidad y un límite de raíz de confianza. Producción, staging, entornos PCI u organizaciones con gobernanza independiente deben usar dominios separados en lugar de una raíz global única. Un ID podría ser:

spiffe://prod.example/ns/payments/sa/worker
spiffe://reports.partner/ns/analytics/sa/reader

La ruta debe expresar un principal de negocio estable y un alcance de gobernanza, no el nombre de un pod, una IP o un hash de despliegue efímero. La versión, el tenant y la región pueden ser selectores, entradas de políticas o claims de tokens. Codificar cada despliegue en el ID convierte el mantenimiento de la rotación y la autorización en una migración de toda la flota.

Registra la federación como enlaces explícitos: prod.example puede validar el paquete de reports.partner, pero solo para la audiencia reports-api y la acción ReportRead. Un destinatario no debe permitir una llamada simplemente porque ambos dominios usen SPIFFE.

Paso 2: Establecer Server, Agent y entradas de registro

El SPIRE Server almacena entradas de registro, material de firma y autorización de nodos. Un Agent se ejecuta en cada nodo de carga de trabajo y expone la Workload API local. El Server envía a un Agent solo las entradas que el Agent está autorizado a gestionar, limitando el radio de impacto ante el compromiso de un nodo.

Una entrada debe vincular un SPIFFE ID, SPIFFE ID padre, conjunto de selectores, perfil de SVID permitido y audiencia. Los selectores provienen de un orquestador confiable o propiedad del nodo: Kubernetes namespace, cuenta de servicio, digest de imagen o identidad de instancia en la nube. No confíes únicamente en etiquetas editables por el usuario ni trates una cadena de configuración arbitraria como evidencia de atestación.

Paso 3: Diseñar la atestación en dos etapas

Al iniciar el nodo, el Agent prueba su identidad con un documento de instancia en la nube, Kubernetes ServiceAccount, TPM o un token de unión de un solo uso. El Server valida de forma independiente la prueba y emite la identidad del Agent. Luego, la carga de trabajo llama a la Workload API a través de un socket de dominio Unix o un endpoint restringido. El Agent usa hechos del ID de proceso, kernel, kubelet o runtime de contenedores para obtener selectores, comparar entradas de registro y devolver un SVID.

Esto explica por qué la Workload API no necesita usar autenticación de cliente de red ordinaria: el Agent identifica a un invocador local fuera de banda. Los permisos de socket, el aislamiento de namespaces y la confianza en el kernel del host o kubelet pertenecen al modelo de amenazas. Si el Agent no puede identificar al invocador, debe devolver PermissionDenied en lugar de una identidad predeterminada de altos privilegios.

Paso 4: Elegir un perfil de SVID y gestionar claves

X.509-SVID se adapta a mTLS y a la identidad de servicio a nivel de conexión. JWT-SVID se adapta a intercambios HTTP u OIDC externos donde un audience debe viajar con la aserción. Un verificador de JWT-SVID debe usar el paquete para el dominio de confianza del sujeto; un JWKS arbitrario no es la misma raíz de confianza.

Los SVIDs deben ser de corta duración y transmitirse a través de la Workload API. La carga de trabajo o un administrador de claves del Agent genera la clave privada y la mantiene en memoria restringida o en un descriptor de archivo. El Server firma la clave pública correspondiente, pero nunca escribe una clave privada de larga duración en una imagen, variable de entorno o configuración ordinaria. Una carga de trabajo con múltiples identidades puede usar un hint o selección explícita para audiencias internas y externas, de modo que el valor por defecto no pueda usarse indebidamente.

Paso 5: Establecer la federación de paquetes entre dominios de forma segura

El plano de control de federación revisa el dominio externo, el endpoint del paquete, el perfil del endpoint, el certificado TLS y el prefijo de SPIFFE ID permitido. Un cliente sabe de antemano qué dominio de confianza representa la URL. La autenticación TLS prueba el endpoint de transporte; el paquete devuelto aún necesita verificaciones de dominio, versión, firma y expiración.

Almacena un foreign-bundle en un almacén de confianza versionado. Durante la validación del par, selecciona el paquete según el dominio de confianza del SVID; rechaza si no hay coincidencia. No conviertas un foreign-bundle en una raíz emisora local, y no reemplaces la configuración de forma permanente debido a una redirección temporal. El sondeo (polling), los ETags, la expiración y la última versión exitosa deben ser observables.

Paso 6: Mapear la identidad a la autorización de recursos

El PEP del servicio de reportes verifica el par mTLS o el JWT-SVID, y luego envía el SPIFFE ID completo, el dominio de confianza, la audiencia, el tenant y la acción a un PDP. Una regla de ejemplo es:

allow if trust_domain == "prod.example"
   and spiffe_id == "spiffe://prod.example/ns/payments/sa/worker"
   and audience == "reports-api"
   and action == "ReportRead"
   and tenant == resource.tenant

La alcanzabilidad de red, los SVIDs válidos y un enlace de federación no constituyen un permiso de negocio. El servicio de recursos aún comprueba la propiedad del tenant, el acceso a nivel de fila, las aprobaciones y los límites de tasa (rate limits). Si una identidad de carga de trabajo debe llegar a IAM en la nube o a un servicio OIDC externo, utiliza un broker restringido vinculado a la audiencia, alcance, TTL del SVID y propósito; nunca entregues un rol de nube amplio a cada carga de trabajo.

Paso 7: Coordinar rotación, revocación y consistencia de caché

La expiración de SVID se gestiona a través de streams de la Workload API. Los clientes reemplazan certificados y claves atómicamente y permiten que las nuevas conexiones utilicen primero el material nuevo. La rotación de paquetes de confianza utiliza una superposición acotada entre las raíces antiguas y nuevas; elimina la raíz antigua solo después de que los verificadores hayan cargado la nueva versión y se hayan drenado los SVIDs y conexiones antiguas. Un compromiso de emergencia no utiliza la superposición normal; publica una versión de revocación o denegación y acorta la ventana de aceptación.

Almacena en caché la versión del paquete, emisor, dominio de confianza, expiración del SVID y versión de la política. Un objetivo de revocación declarado de cinco minutos requiere que el establecimiento de conexiones, la validación de JWT y las cachés de sidecars observen la actualización dentro de esos cinco minutos. Las conexiones largas necesitan un drenaje con límite de antigüedad de certificado; cambiar una base de datos del plano de control sin gestionar las conexiones existentes no completa la revocación.

Paso 8: Planificar escalabilidad, fallas y migración

El uso de recursos de SPIRE Server crece con las entradas de registro, y una sola instancia es un punto de falla. Realiza sharding por región o dominio de confianza, utiliza múltiples Servers para alta disponibilidad (HA), limita qué entradas recibe cada Agent y monitorea la latencia de emisión, recuento de Agents, recuento de entradas, solicitudes a la Workload API y retraso de paquetes (bundle lag). Evita un grafo de federación totalmente mallado; utiliza enlaces controlados o brokers.

Cuando el plano de control no está disponible, un SVID no expirado puede admitir conexiones existentes acotadas de bajo riesgo, pero el sistema no debe emitir identidades indefinidamente. Un paquete expirado, prueba de nodo fallida, falla del administrador de claves o mapeo de dominio desconocido debe fallar cerrado para nuevas conexiones de alto riesgo. Durante la migración de secretos estáticos, ejecuta ambas rutas, realiza despliegues canary por grupo de servicios, verifica la auditoría y revocación, y luego elimina el secreto antiguo. La reversión regresa a una ruta aún controlada, nunca a la autenticación deshabilitada.

Respuesta modelo de alta calidad

«Separaría los entornos de producción, staging y socios en dominios de confianza y usaría SPIFFE IDs estables para las cargas de trabajo. Cada SPIRE Server posee entradas de registro y una raíz emisora. Un Agent prueba su nodo y luego la Workload API local utiliza atributos del proceso y del orquestador para la atestación de cargas de trabajo. Las cargas de trabajo obtienen X.509-SVIDs de corta duración para mTLS o JWT-SVIDs para una audiencia fija; las claves privadas permanecen con la carga de trabajo, el Agent o un administrador de claves controlado.

Pagos y reportes tienen un único enlace de federación revisado. El cliente fija el endpoint y el dominio y valida TLS, la versión del paquete y la expiración. La validación del par selecciona el paquete externo por el dominio de confianza del SVID y rechaza si falta coincidencia. El servicio de reportes valida el SVID, el emisor, la audiencia y la expiración, y luego autoriza el SPIFFE ID completo, el tenant y la acción. La federación proporciona material de verificación; no otorga permisos de negocio.

Los SVIDs y los paquetes rotan mediante streams, TTLs cortos, métricas de versión y material obsoleto acotado; las conexiones largas se drenan por antigüedad del certificado. Una falla en la prueba o en el plano de control nunca emite una identidad desconocida, y las llamadas de alto riesgo fallan cerradas. La migración de secretos estáticos utiliza rutas paralelas, despliegues canary, simulacros de revocación y conciliación de auditorías hasta que cada servicio pueda demostrar sus límites de identidad, autorización y recuperación».

Errores comunes

• Compartir un solo dominio de confianza en todos los clústeres. La filtración de una sola raíz o configuración afecta a todos los entornos; divide los dominios por gobernanza y riesgo.
• Tratar un SPIFFE ID como autorización de negocio. La identidad responde quién es; el servicio de recursos aún comprueba audiencia, tenant, acción y propiedad.
• Realizar solo atestación de nodos. Un proceso malicioso en el nodo puede suplantar a un servicio; utiliza también selectores de carga de trabajo.
• Usar un nombre de pod o IP mutable como principal de larga duración. Las reconstrucciones y traslados rompen la autorización; usa un ID estable y selectores de políticas.
• Tratar una URL de federación como raíz de confianza. Preconfigura el dominio y valida TLS, contenido del paquete, versión y expiración.
• Permitir a cada principal externo desde un foreign-bundle. La federación suministra material de verificación; la política debe restringir prefijos de ID, audiencia, acción y tenant.
• Colocar claves privadas de larga duración en imágenes o variables de entorno. Las copias las exponen; genéralas y rótalas en el límite de la carga de trabajo o del administrador de claves.
• Aceptar paquetes o SVIDs obsoletos indefinidamente. Eso viola la revocación; rastrea versiones, TTLs y antigüedad de las conexiones, y recházalos tras alcanzar el límite.
• Permitir por defecto durante una interrupción del plano de control. Una identidad desconocida no debe obtener autoridad; utiliza material antiguo acotado o falla cerrado según el riesgo.
• Migrar mTLS sin auditoría y autorización. El cifrado no prueba permiso de negocio; registra el ID del par, versión de política, tenant y decisión.

Preguntas de seguimiento y respuestas

Si dos dominios de confianza necesitan comunicación bidireccional, ¿deben ambos importar el paquete del otro?

No necesariamente. Si pagos solo llama a reportes, crea un enlace unidireccional: reportes confía en el paquete externo de pagos, mientras que pagos no necesita confiar en reportes. Agrega el enlace inverso solo cuando reportes también inicie llamadas, con audiencias y políticas independientes. La confianza mutua no es permiso total.

¿Por qué no usar directamente la identidad de cargas de trabajo del proveedor de nube?

La identidad en la nube es útil dentro de un plano de control en una sola nube, pero los entornos multinube, privados y de socios tienen diferentes emisores, SDKs y políticas. SPIFFE proporciona nomenclatura portátil, SVIDs e intercambio de paquetes. IAM de nube externa aún puede usar un broker de federación OIDC restringido; SPIFFE no reemplaza la autorización de negocio.

¿Es segura una Workload API no autenticada?

Se basa en la identificación de procesos fuera de banda en lugar de tratar un socket como una API de red abierta. Restringe los permisos de sockets o endpoints, aísla el host y el namespace, y compara las entradas de registro con datos del kernel, kubelet o runtime de contenedores. Un invocador no identificable recibe una denegación, nunca un SVID potente por defecto.

¿Qué sucede si el endpoint de un foreign-bundle no está disponible temporalmente?

Mantén el último paquete confiable con su versión y expiración. Puede validar conexiones existentes de bajo riesgo mientras sea reciente; más allá de la antigüedad máxima obsoleta o para nuevas conexiones de alto riesgo, falla cerrado. Monitorea el retraso de paquetes, la última versión exitosa y las denegaciones en lugar de aceptar una raíz antigua indefinidamente.

¿Cómo manejan las conexiones de larga duración la rotación y revocación de SVIDs?

La Workload API transmite nuevo material; los clientes se actualizan atómicamente y usan el nuevo certificado para nuevas conexiones. Drena por antigüedad máxima del certificado o ventana de revocación, y vuelve a verificar la política antes de operaciones de confirmación (commits) de alto riesgo. Reemplazar un archivo sin gestionar las conexiones establecidas no prueba que la identidad antigua haya desaparecido.

¿Cómo pruebas que los selectores no pueden ser falsificados?

Los selectores provienen de APIs confiables del nodo u orquestador y son verificados por el Server o Agent. Las etiquetas editables por el usuario son solo sugerencias. Combina digest de imagen, cuenta de servicio, namespace, propiedades del proceso y prueba del nodo, y audita y aprueba los cambios de registro.

¿Cómo reviertes una migración de secretos estáticos?

Acepta el secreto antiguo y el SVID en paralelo, habilita el SVID por grupo de servicios y registra el éxito, autorización y revocación para ambas rutas. En caso de falla, detén la nueva emisión y regresa al secreto antiguo aún controlado, y luego continúa con el despliegue canary tras solucionar el problema. Define la evidencia de retiro y una compuerta de eliminación; nunca deshabilites la autenticación como método de reversión.