Una workload puede tener identidad sin convertirse en una sesión
Una máquina puede ejecutar decenas de procesos con propietarios, propósitos y límites distintos. En una misma operación, un proceso puede autenticarse ante un servicio y leer un secreto de aplicación; esas acciones no tienen por qué compartir autoridad, ciclo de vida ni impacto. La pregunta es qué ejecución actuó, quién la observó, quién emitió la credencial, qué receptor la verificó, qué política autorizó la acción y qué material quedó expuesto.
En Asteria, receipt-worker corre varias réplicas en producción. Cada réplica debe escribir en ledger-api sólo para el tenant asignado, obtener shipping-api-key para una operación acotada y publicar métricas. Una réplica de staging, una rotación de claves y un proceso comprometido producirán síntomas diferentes, aunque todos puedan describirse de forma imprecisa como un problema de identidad. La pregunta conductora es:
¿Qué autoridad identificó esta ejecución, con qué credencial se presentó, qué secreto recibió, qué política decidió el receptor y qué evidencia permite concluir algo sin conservar material reutilizable?
Para leer el resto del capítulo, usa estas unidades: un host o nodo aloja procesos; un proceso es una instancia ejecutable; una workload es una unidad de software que ejecuta con un propósito y puede tener varias réplicas; un principal es el sujeto al que una decisión atribuye una acción.
La machine identity identifica una máquina bajo una autoridad y un ámbito. La workload identity atribuye una identidad a una workload concreta bajo un trust domain y una política de emisión. Un issuer emite una identidad o credencial; un verifier comprueba un artefacto contra una política de confianza; un secret manager almacena y entrega material confidencial bajo su propia política. Ninguna de esas identidades es por sí sola autorización, propiedad del código ni sesión. Una sesión es el estado que un receptor mantiene después de aceptar una autenticación; no es sinónimo del token o documento presentado.
La unidad sigue esta cadena causal: bootstrap y atestación, asignación de identidad, emisión de una credencial, presentación, verificación y autorización local; después, secretos, ciclo de vida, federación y diagnóstico. SPIFFE aporta el vocabulario normativo central; SPIRE aparece sólo como implementación de referencia. Kubernetes y OAuth Token Exchange se tratarán como perfiles o extensiones delimitadas, no como definiciones universales.
Host, proceso y workload no tienen por qué ser el mismo principal
El host es la máquina física, virtual o lógica que proporciona el entorno de ejecución. Un nodo es el host visto por un programador (scheduler) u orquestador. En él pueden coexistir agentes, procesos del sistema y workloads de aplicaciones. El identificador node-7 describe una unidad administrativa o de infraestructura; no prueba que cualquier proceso que se ejecute allí tenga permiso para escribir en ledger-api.
Un proceso tiene una identidad observable para su entorno de ejecución: usuario del sistema, identificador de proceso (PID), grupo de control (cgroup), imagen, ruta, espacio de nombres (namespace) o atributos equivalentes. Esos atributos son entradas para una decisión de identificación, no una credencial por sí mismos. El mismo nombre de proceso puede aparecer en producción y staging; un espacio de nombres puede ser reutilizado; un PID puede reciclarse. Si el receptor acepta sólo un texto enviado por el proceso, el proceso elige la identidad que pretende tener.
Una workload agrupa el propósito operativo que la plataforma registra. Dependiendo del despliegue, puede corresponder a un proceso, a varios procesos auxiliares o a réplicas de una misma carga. Una cuenta de servicio (service account) del orquestador puede aportar contexto administrativo, pero no es automáticamente la definición de la identidad criptográfica de la workload. El vínculo que importa es el que una autoridad observa y evalúa: «esta ejecución, en este nodo y bajo estos atributos, coincide con esta entrada de política».
El SPIFFE ID es un URI (Uniform Resource Identifier, identificador uniforme de recursos) de la forma spiffe://trust-domain/path. El trust domain delimita una raíz de identidad y el ámbito en el que el emisor interpreta ese ID. El path puede nombrar una workload, equipo o servicio según la política del administrador; el texto no crea aislamiento ni autorización por sí mismo. Un bundle es el material público de confianza —por ejemplo, raíces o claves públicas— que permite validar identidades de ese trust domain; distribuirlo no concede autorización de negocio. En Asteria, dos ejemplos sintéticos podrían ser spiffe://prod.asteria.example/workloads/receipt-worker y spiffe://staging.asteria.example/workloads/receipt-worker. El parecido textual no elimina la diferencia de autoridad.
El primer error que debe evitarse es usar la identidad de máquina como principal universal. El nodo puede estar atestado y autorizado para hospedar una workload, mientras ledger-api exige una identidad de workload concreta. El segundo es invertir la relación: que un proceso conozca el SPIFFE ID esperado no demuestra que sea el proceso al que la política asigna ese ID. El ID debe venir de una autoridad confiable, acompañado por una credencial verificable y sujeto a una política local.
Desliza horizontalmente para leer el diagrama a tamaño completo.
La figura separa el plano de control/emisor, la frontera del nodo y la frontera del proceso. La workload puede nacer sin un secreto portador duradero dentro de su memoria o imagen, pero esa ausencia no elimina el bootstrap. La confianza se desplaza hacia el ancla configurada, el agente, el mecanismo de atestación, el control del endpoint local y la política de registro. El bundle no es un secreto ni una autorización de negocio.
La siguiente figura anticipa el recorrido completo que el capítulo descompone a continuación: observación de la ejecución, asignación de identidad, emisión por perfil, renovación y rechazo. Funciona como mapa de orientación; las autoridades de atestación y las validaciones propias de X.509-SVID y JWT-SVID se justifican en las secciones siguientes.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Bootstrap y atestación: una autoridad observa antes de emitir
Bootstrap es el establecimiento inicial de la autoridad necesaria para que un nodo, agente o endpoint pueda participar en la emisión. Puede incluir una clave o token de arranque, una identidad de plataforma, un canal seguro o un mecanismo de hardware. El detalle cambia entre despliegues; la propiedad común es que debe existir una primera confianza y que su custodia condiciona todo lo que siga. «Secretless» describe que el proceso de aplicación no lleva un secreto estático preinyectado; no significa que el sistema carezca de anclas de confianza.
Attestation es la obtención y evaluación de evidencia sobre una plataforma o ejecución bajo una política. En el modelo de Remote ATtestation Procedures (RATS), el Attester presenta Evidence y el Verifier la evalúa.
El Verifier combina Evidence con Endorsements, Reference Values y una Appraisal Policy. Produce un Attestation Result. El Relying Party (RP) recibe ese resultado y aplica su propia política; Evidence no es una identidad, un permiso ni evidencia de ausencia de compromiso del software.
En Asteria puede existir una fase de atestación del nodo: el plano de control decide si el agente de node-7 reúne las condiciones para recibir material de bootstrap. Después hay una fase de atestación de workload: el agente identifica al solicitante local, obtiene selectors —atributos observados como espacio de nombres, identidad del proceso o vínculo con una workload— y los compara con una política de registro. La identificación del solicitante y estos selectors son comprobaciones de la implementación del endpoint; no son automáticamente la Evidence del modelo RATS. En SPIRE, la atestación del nodo y de la workload son fases distintas; esa separación es una propiedad de esa arquitectura de referencia, no una exigencia universal de todo sistema de identidad de workload.
El resultado de una atestación no sustituye al control del receptor. Un Verifier puede producir un Attestation Result positivo porque sus entradas satisfacen su política. ledger-api todavía debe decidir si acepta ese resultado para emitir identidad, permitir una conexión o conceder una acción concreta. Puede aceptar para receipt-worker en producción y rechazar para staging aunque ambos presenten evidencia criptográficamente consistente. También puede responder review si falta actualización reciente, existe una discrepancia de bundle o no está disponible el Verifier.
Desliza horizontalmente para leer el diagrama a tamaño completo.
La figura hace visibles tres fallos que no deben colapsarse: Evidence que no pasa la evaluación, RP que rechaza el resultado y Verifier no disponible. En un modelo de credencial transportada (passport), el resultado puede acompañar a la solicitud; en un modelo de consulta previa (background check), el RP consulta al Verifier. La arquitectura RATS contempla ambos modelos, pero no autoriza a dibujarlos como un único flujo sin estado. En cualquier variante, la pregunta es qué actor conoce qué evidencia y qué decisión puede justificar.
La Workload API de SPIFFE introduce otra frontera. Es una interfaz local mediante la cual la workload obtiene un SVID y material de confianza. La autenticación del solicitante ocurre fuera del protocolo de mensajes, mediante propiedades del endpoint y de la plataforma; el endpoint debe protegerse para que una workload no autorizada no obtenga la identidad de otra. Por eso un socket Unix, un proceso auxiliar (sidecar) o un agente no son anclas de confianza automáticas. Si cualquier proceso puede leer el endpoint, el supuesto de aislamiento se rompe aunque la respuesta esté firmada.
Microejemplo de fallo local. receipt-worker solicita un SVID y el socket de la Workload API no responde. El cliente registra el endpoint, el código de error y el reloj, aplica un retroceso progresivo (backoff) limitado y, según la política de Asteria, devuelve reject para la emisión o degrade para una operación que pueda continuar sin credencial nueva. No deriva una identidad del nombre del proceso, del espacio de nombres ni de un token anterior usado como sustituto silencioso. La evidencia conserva la decisión y su procedencia, nunca una credencial reutilizable.
De la ejecución observada a una credencial presentable
Un SVID (SPIFFE Verifiable Identity Document) es un documento verificable que presenta un SPIFFE ID. Este capítulo compara dos perfiles relevantes de la Workload API: X.509-SVID y JWT-SVID. La especificación actual también define un perfil opcional WIT-SVID (Workload Identity Token SVID), que queda fuera de este foco.
Un X.509-SVID codifica el SPIFFE ID en el URI Subject Alternative Name (SAN) de un certificado X.509 y se usa normalmente con una clave privada para autenticación de seguridad de la capa de transporte (TLS). Un JWT-SVID (JSON Web Token SVID) es un token JSON firmado destinado a un audience. El SVID prueba la relación con una autoridad y un trust domain bajo las condiciones de su perfil; no es una sesión, un permiso de negocio ni una clave global.
El camino de emisión debe mantener separados el ID y el material que lo presenta. La autoridad asigna el SPIFFE ID según la política de registro. La Workload API entrega, para X.509, un certificado, su clave privada y el bundle aplicable; para JWT entrega un token firmado con los claims definidos por el perfil. La clave privada y el token pueden ser secretos en sentido de confidencialidad, pero el ID público no lo es. Renovar la credencial puede cambiar serial, clave o token sin cambiar el ID lógico; no se debe asumir que la renovación extiende material idéntico.
Para un X.509-SVID, el receptor valida la ruta de certificado contra un ancla de confianza configurada, la cadena y las restricciones del perfil; comprueba que el URI SAN tenga el SPIFFE ID esperado y que el certificado sea válido en el tiempo de la conexión. En una conexión mutual TLS (mTLS, TLS mutuo), el peer demuestra posesión de la clave privada asociada. La autenticación del canal permite identificar al peer, pero ledger-api aún evalúa principal, action, resource y contexto. Un mTLS válido para spiffe://prod.asteria.example/workloads/receipt-worker puede permitir ledger:read y rechazar ledger:write para otro tenant.
Para un JWT-SVID, el receptor valida la firma y el algoritmo permitido usando la clave JWT-SVID del bundle del trust domain correspondiente al sub, que contiene el SPIFFE ID. El perfil exige sub, aud y exp; iss no es un requisito universal del JWT-SVID. Si el despliegue añade iss, debe declararlo como requisito local y validarlo contra el emisor configurado. kid ayuda a seleccionar una clave entre candidatas ya confiables; no autentica esa clave por sí mismo. La firma no evita que alguien copie el JWT y lo presente dos veces. La audiencia, la vida corta, los controles contra repetición y la vinculación del emisor al poseedor (sender-constraining) sólo aplican según el perfil y la política del recurso.
La diferencia entre formatos es operativa. X.509-SVID suele viajar con el handshake TLS y puede identificar el canal completo; JWT-SVID suele viajar en una solicitud de capa 7 y exige un receptor que procese sus claims. No son intercambiables porque ambos estén firmados. Un JWT-SVID tampoco es un token de identificación de OpenID Connect (OIDC): el primero representa una workload para una audiencia bajo SPIFFE; el segundo representa un evento de autenticación de un usuario final para un Relying Party (RP) OIDC. Como frontera con cc-0046, un iss+sub de OIDC identifica al usuario final dentro del emisor y del RP de ese flujo; no se convierte en un SPIFFE ID ni en una identidad de workload. Un token de acceso OAuth tiene otro propósito y otro contrato.
Un token proyectado de Kubernetes es un perfil de despliegue útil para observar la misma separación. El orquestador puede proyectar a un Pod un token de cuenta de servicio con audiencia, expiración y vínculo al Pod, y renovarlo según la configuración de la plataforma. Eso no convierte a Kubernetes en la definición de identidad de workload ni hace que el token sea aceptado por cualquier API. El receptor valida la firma, la audiencia, el tiempo y la política; comprueba el vínculo con un objeto sólo cuando el perfil y el receptor pueden evaluarlo.
La diferencia entre receptores es decisiva: el API server de Kubernetes puede validar mediante TokenReview y comprobar referencias de objetos, de modo que un token ligado a un Pod eliminado puede quedar invalidado de inmediato. Un validador externo que sólo usa el descubrimiento y las claves de OIDC puede seguir aceptando el token hasta exp si no consulta TokenReview. Un espacio de nombres o nombre de Pod no es autenticación universal; la versión de la documentación y el comportamiento del clúster forman parte de la afirmación sensible a versión.
Verificar no es autorizar: la política sigue en el receptor
La verificación responde si un artefacto puede aceptarse como prueba en un contexto. La autorización decide si el principal puede realizar una acción sobre un recurso bajo condiciones. El PDP (Policy Decision Point) evalúa una política; el PEP (Policy Enforcement Point) aplica su decisión. En ledger-api, el certificado o JWT aporta un principal acotado; el PEP todavía comprueba recurso, tenant, método, endpoint, red, estado de la workload y cualquier condición temporal.
Una matriz de decisión para la ruta positiva de Asteria debe indicar qué perfil define cada comprobación. aud no aparece en un certificado X.509-SVID: en ese formato, el recurso y el destinatario se resuelven mediante la política local. En un JWT-SVID, aud sí es una parte obligatoria del perfil.
Desliza horizontalmente para consultar todas las columnas.
Para ambos perfiles, la vinculación con la ejecución sólo se comprueba cuando el receptor tiene una señal verificable para hacerlo. La política local decide la acción sobre resource; por tanto, audience y resource son dimensiones distintas.
La ruta de staging muestra por qué cada control importa. Si spiffe://staging.asteria.example/workloads/receipt-worker tiene una firma correcta pero el receptor espera el trust domain de producción, la decisión de confianza es reject, no «aceptar porque el nombre coincide». Si el bundle de producción está desactualizado y no contiene la clave válida para una renovación, la política de actualización reciente (freshness) y renovación coordinada (rollover) puede permitir una ventana temporal explícita, producir review, degrade o rechazar de forma controlada; nunca se acepta una raíz que no esté configurada ni una URL aportada por el token. Si mTLS establece una conexión pero la solicitud pide ledger:write sobre otro tenant, la autenticación no produce un permit: la política local debe devolver deny para ese recurso.
La evidencia de diagnóstico debe conservar el emisor, el ID no sensible, la versión de bundle, las marcas de tiempo, el resultado de cada control y la razón de la decisión. No debe guardar el JWT completo, la clave privada ni el valor de shipping-api-key. Un hash o identificador no reutilizable puede correlacionar eventos, pero sólo si se documenta qué propiedad preserva y qué no permite inferir.
El secreto de aplicación es otro objeto
Un secreto es material cuya confidencialidad debe preservarse: una clave de API, una contraseña de servicio, una clave privada o un token portador. Un secret manager es la autoridad o servicio que almacena y entrega ese material bajo una política. La identidad de workload responde «quién es el solicitante»; el secreto responde «qué material puede usar ese solicitante». Tener un SVID válido no concede automáticamente lectura de todos los secretos.
Para shipping-api-key, Asteria necesita una cadena separada:
- El workload se autentica ante el secret manager con su identidad de workload.
- El secret manager evalúa
principal, acciónread, recursoshipping-api-key, entorno y tenant. - Si la política permite la lectura, entrega una versión concreta y, si aplica, un lease, es decir, una concesión con duración y condiciones de renovación o revocación.
- El agente o la aplicación materializa el secreto en memoria, un archivo con permisos acotados o una interfaz de programación; el modo elegido cambia el ciclo de vida.
- El consumidor lo usa para una operación concreta, sin imprimirlo en registros, etiquetas, métricas ni trazas.
- La autoridad publica una versión nueva, mantiene un solapamiento acordado y retira la anterior cuando los consumidores confirman la recarga o se alcanza el límite temporal.
El valor del secreto no debe confundirse con su versión, lease o referencia. Que el gestor registre «entregué V2 a la workload X» no demuestra que la aplicación haya recargado V2 ni que el servicio receptor haya rechazado V1. Una variable de entorno de un proceso vivo no se actualiza automáticamente; puede requerir reinicio o un mecanismo explícito de recarga. Un archivo reemplazado atómicamente tampoco garantiza que todos los entornos de ejecución hayan cerrado el descriptor anterior.
Desliza horizontalmente para leer el diagrama a tamaño completo.
La rotación de shipping-api-key puede tener estos estados: V1 activa; V1+V2 en solapamiento; consumidor cargó V2; el servicio receptor acepta V2; el servicio receptor rechaza V1; V1 retirada. En Asteria, éste es el criterio operativo para afirmar una rotación completa: entrega de V2, recarga o confirmación del consumidor, prueba positiva con V2 y prueba negativa con V1 dentro de la ventana declarada. Es un oráculo de este caso, no una definición universal de rotación. Si el consumidor no confirma la recarga, la autoridad debe decidir si mantiene V1, aplica degrade, detiene la workload o bloquea el tráfico. Crear V2 en el almacén es el comienzo de la transición, no su final. Revocar un lease puede impedir una nueva entrega, pero no demuestra que una copia ya materializada haya desaparecido de memoria, disco, registros o conexiones en vuelo.
La clave privada de un X.509-SVID y shipping-api-key comparten la necesidad de protección, pero sus responsables y usos no son iguales. La primera permite probar una identidad dentro de un perfil; la segunda permite una operación que el servicio receptor entiende. La primera puede rotarse con la credencial; la segunda puede tener una política de negocio y un sistema de versiones distinto. El desprovisionamiento debe tratar ambos carriles: retirar la entrada de registro o bloquear la identidad, y revocar o rotar el secreto y sus leases.
Ciclo de vida: expiración, rotación, revocación y conexiones
Una credencial de vida limitada reduce la ventana en la que material copiado puede ser aceptado, pero no equivale a revocación instantánea. Expiración es que el reloj supera exp o NotAfter. Rotación es reemplazar material o claves por una versión nueva, normalmente con solapamiento. Revocación es una decisión o mecanismo por el que un receptor deja de aceptar material antes de su fin natural. Una caché conserva una decisión o clave durante una ventana y puede retrasar la observación de un cambio. El cierre de conexión termina un canal concreto; no invalida automáticamente tokens, copias o conexiones de otros consumidores. El desprovisionamiento retira la autoridad o relación de una workload, cuenta, entrada de registro o secreto.
Una línea temporal de incidente debe distinguir al menos t_compromise, t_detect, t_contain y t_exp_or_reject_last. Con esas distinciones, el incidente se ordena por material, receptor y estado observado.
Si se expone un JWT-SVID, el receptor puede aplicar una política de denegación o un mecanismo de revocación si el despliegue lo tiene; de lo contrario, la expiración es un límite residual y la audiencia determina qué receptores pueden verse afectados. Si se expone una clave privada de hoja X.509, detener la workload y rotar la hoja puede contener nuevas conexiones, pero las conexiones ya establecidas y las cachés necesitan tratamiento propio. Si se compromete una clave de firma del emisor, el alcance puede abarcar múltiples identidades emitidas bajo ella: hay que retirar la clave, distribuir un bundle o un conjunto de claves web JSON (JWKS) nuevo y adjudicar los artefactos existentes.
El receptor debe declarar qué hace ante pérdida de la Workload API, reloj atrasado, bundle desactualizado, conexión en vuelo o respuesta de renovación ausente. Un modo de fallo abierto puede preservar disponibilidad a costa de aceptar material fuera de la ventana; un modo de fallo cerrado puede rechazar llamadas legítimas. No hay una elección abstractamente correcta: la política debe expresar la propiedad que se prioriza y el impacto de cada estado. La observación «la nueva clave fue publicada» no basta; se necesita una prueba positiva con la nueva y una prueba negativa con la antigua en cada receptor relevante.
Una workload comprometida puede conservar una credencial válida hasta que expire o el receptor la deniegue. Rotar no demuestra contención; hace falta observar que el material anterior deja de ser aceptado, que los consumidores cargaron el nuevo y que el alcance residual está acotado. La ausencia de registros no demuestra ausencia de uso. Las evidencias deben evitar capturar secretos o tokens reutilizables y conservar sólo la procedencia necesaria para reconstruir la secuencia.
Federar e intercambiar: cambiar el artefacto, no clonar la autoridad
La federación SPIFFE permite que los trust domains cooperen mediante bundles extranjeros y una política de aceptación. Un bundle distribuido aporta material para validar identidades de otro dominio; no obliga al receptor a aceptar toda identidad extranjera. Deben permanecer explícitos el trust domain de origen, la procedencia y actualización reciente del bundle, la autoridad que lo publica, la política del receptor y el recurso que puede alcanzarse.
En Asteria, prod.asteria.example puede necesitar llamar a un recurso en billing.partner.example. Una relación federada no convierte el SPIFFE ID local en un ID global ni permite presentar cualquier SVID a cualquier API. El receptor puede aceptar sólo spiffe://prod.asteria.example/workloads/receipt-worker para una acción concreta, y rechazar otra workload del mismo dominio. La federación resuelve una pregunta de validación; la autorización sigue siendo local.
Como extensión acotada, un despliegue puede usar OAuth 2.0 Token Exchange. El Security Token Service (STS) recibe un subject_token que representa al sujeto cuya autorización se solicita intercambiar. Un actor_token opcional representa al actor que actúa en nombre del sujeto. El cliente autentica al STS; éste valida emisor, token, cliente y política, interpreta resource, audience, scope y requested_token_type, y emite un token de salida con ciclo de vida propio.
Desliza horizontalmente para leer el diagrama a tamaño completo.
El token de salida no es un reenvío transparente del subject_token. Su audiencia, recurso, alcance, tipo y expiración pueden ser más estrechos. El recurso B valida el token según requested_token_type, el perfil del token de salida, su emisor, audiencia, recurso y política local. Comprueba alcance, actualización reciente y vinculación del emisor al poseedor sólo cuando ese perfil y el despliegue los definen; por ejemplo, mTLS con certificado vinculado o DPoP (Demonstrating Proof of Possession at the Application Layer). RFC 8693 no define por sí sola el modelo de confianza del despliegue y no invalida automáticamente el token de entrada. Tampoco permite inferir suplantación o delegación sólo porque aparezcan subject y actor.
La diferencia con una llamada local es crucial. En la llamada local, ledger-api valida el SVID y aplica su política. En el intercambio, el STS toma una decisión adicional y crea otro artefacto para otro consumidor. Si el mapeo no existe, la audiencia no está permitida o el emisor no es confiable, la respuesta es reject o un alcance reducido, no una copia del poder original. El servicio receptor no debe aceptar el token de entrada «porque ya fue válido en A».
Token proyectado de Kubernetes como perfil, no como definición
En un clúster Kubernetes, una cuenta de servicio puede asociarse a un Pod y un token proyectado puede llevar audiencia y expiración. El kubelet o la plataforma puede renovar ese material; el comportamiento depende de la versión y configuración. La identidad del token pertenece al emisor y a la política que el receptor de la API configure. Un token proyectado puede servir para que una workload llame a un servicio interno, pero no prueba por sí solo que el proceso tenga permiso sobre todo el espacio de nombres ni que un receptor externo deba aceptarlo.
La comparación con SPIFFE es más útil si se limita a forma y ciclo de vida. Ambos perfiles pueden ofrecer un artefacto firmado, audiencia y duración, pero difieren en emisor, campos, distribución de confianza, vinculación y consumidores. Un Pod recreado puede recibir un token nuevo; un nombre de despliegue puede sobrevivir a réplicas distintas. La política del receptor debe especificar qué vínculo espera y cómo trata rotación, caché y desprovisionamiento. No hay que dibujar el token de Kubernetes como una identidad universal ni asumir que cuenta de servicio, workload y proceso son sinónimos.
Incidente Asteria: separar síntomas y decisiones
Durante un despliegue, Asteria observa cuatro señales: una réplica de staging alcanza un endpoint de producción; algunas conexiones de receipt-worker fallan tras la renovación del bundle; shipping-api-key aparece en V1 aunque el almacén ya publica V2; y un Pod comprometido sigue enviando solicitudes después de que el equipo rotó las credenciales. Tratar todo como una única alerta impide decidir qué autoridad debe intervenir.
Primero se fijan hechos no reutilizables: emisor observado, SPIFFE ID, trust domain, versión del bundle, kid o serial no sensible, marcas de tiempo, audiencia, receptor, versión del secreto, estado del lease, conexión y resultado de cada control. No se copia el JWT, la clave privada ni el valor de la clave de API. Después se separan hipótesis:
- Staging en producción: la firma puede ser válida, pero emisor/trust domain, audiencia o política de producción no coinciden. Se prueba la misma solicitud con la identidad de producción y se espera
rejectpara staging. - Bundle desactualizado: el receptor no conoce la clave de renovación o usa una caché incompatible. Se registra la versión configurada, se refresca sólo desde la fuente autorizada y se prueba la clave nueva sin aceptar una raíz aportada por el token. Si existe una ventana de rollover declarada, el resultado puede ser
review,degradeo aceptación temporal según esa política; una raíz no configurada sigue siendoreject. - Secreto V1: el almacén tiene V2, pero el agente o la aplicación no completó la recarga. Se comprueba quién autorizó la lectura, cuándo se materializó cada versión y qué versión aceptó el servicio receptor. La creación de V2 no es evidencia de aplicación.
- Pod comprometido: el proceso conserva una credencial válida o una copia del secreto. Rotar ambos materiales acota futuro uso, pero la contención se demuestra con denegación o revocación efectiva, cierre de conexiones, expiración, desprovisionamiento y controles negativos contra el material antiguo.
La tabla de adjudicación debe separar cuatro clases de salida. accept, reject y review describen confianza o credencial: el primero acepta el artefacto, el segundo lo rechaza y el tercero deja la decisión pendiente. permit y deny describen autorización de una acción sobre un recurso; no se debe usar accept como sinónimo de permit. degrade describe una degradación controlada de disponibilidad cuando la política la permite, y unknown indica evidencia insuficiente, no una autorización implícita. Por ejemplo, un SVID de producción con bundle y tiempo válidos puede ser accept para autenticar al peer; una solicitud ledger:write fuera del tenant es deny por política; una respuesta sin evidencia de recarga es review; la ausencia de observación del receptor remoto es unknown; la pérdida del endpoint local puede llevar a degrade o reject según el contrato. Cada decisión declara precondición, autoridad, receptor y límite.
Desliza horizontalmente para leer el diagrama a tamaño completo.
La matriz de impacto diferencia cinco exposiciones: bootstrap del agente, clave privada y certificado de una hoja, JWT-SVID portador, secreto de aplicación y clave de firma del emisor. La primera puede exigir una nueva atestación y revisión de identidades emitidas; la segunda, detener y rotar la workload; la tercera, revisar audiencia y aplicar deny o esperar expiración; la cuarta, versionar y rotar el secreto y los consumidores; la quinta, retirar la autoridad de firma, distribuir un bundle nuevo y revisar muchas credenciales. No tienen el mismo riesgo de reutilización, alcance ni camino de contención.
El caso también muestra una propiedad de los incidentes: «desprovisionado» no significa que todo estado haya desaparecido. Retirar una entrada de registro puede impedir nuevas emisiones, mientras una credencial existente sigue siendo aceptada hasta expiración o deny. Revocar un lease puede detener nuevas lecturas del secreto, pero una copia en memoria requiere una acción sobre el proceso. Cerrar la conexión de ledger-api no cierra automáticamente otras conexiones ni invalida el token que las origina. El diagnóstico debe mostrar qué estados fueron observados y cuáles siguen siendo unknown.
Síntesis: una identidad verificable es el inicio de una decisión
El modelo de Asteria no dice que una workload sea una identidad humana dentro de un contenedor ni que eliminar un secreto estático elimine la confianza. Dice algo más preciso:
host/proceso/workload observados → bootstrap y atestación → asignación bajo trust domain y política → SVID/credencial de vida limitada → presentación al receptor → validación de emisor, bundle, ID y tiempo (más aud sólo en perfiles que lo definen) → autorización local sobre acción y recurso → ciclo de vida de rotación, revocación, caché, conexión y desprovisionamiento.
El secreto de aplicación recorre otro carril: almacenamiento → autorización de lectura → lease/entrega → materialización → uso → recarga → rotación o revocación → eliminación o expiración. El cierre profesional no es memorizar etiquetas, sino adjudicar cada decisión a su autoridad, receptor, ventana y evidencia: la identidad autenticada aporta un principal; la política local decide la acción; el ciclo de vida determina cuánto tiempo puede seguir siendo válido el material. La federación y Token Exchange añaden otra autoridad y otro artefacto, no una transferencia automática de confianza.
La conclusión profesional debe ser limitada y comprobable. «La firma es válida» sólo cubre una parte del control. Para aceptar una llamada hay que saber quién emitió, qué trust domain y bundle se usaron, para qué receptor y audiencia se destinó cuando el perfil la define, durante qué ventana, qué workload presentó el material y qué política local concedió la acción. Para afirmar contención hay que observar rechazo o expiración efectiva en los receptores relevantes, no sólo una rotación publicada. Para diagnosticar Asteria, la evidencia útil es la que conserva procedencia, tiempo y decisión sin conservar un secreto reutilizable.
Fuentes primarias para continuar
- SPIFFE. SPIFFE ID, Trust Domain and Bundle y Federation.
- SPIFFE. X.509-SVID, JWT-SVID y Workload API.
- SPIRE. Concepts: node attestation, workload attestation y registration entries. Documentación de implementación, no definición universal.
- IETF. RFC 9334: RATS Architecture.
- IETF. RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile.
- IETF. RFC 7515: JSON Web Signature y RFC 7519: JSON Web Token.
- IETF. RFC 8693: OAuth 2.0 Token Exchange, RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens y RFC 9449: OAuth 2.0 Demonstrating Proof of Possession at the Application Layer.
- Kubernetes. Service Accounts y Service Accounts administration. Perfil sensible a la versión.
- NIST. SP 800-57 Part 1 Rev. 5: Recommendation for Key Management.