Comunicaciones entre procesos

Implementado. El diseño es dec-0119 y su adopción en Styx es dec-0120. Los subjects, emisores y límites concretos están en referencia/bus/, generada de BUS_ROUTES.

Una sola puertaCopiar enlace

Todo lo que cruza un proceso pasa por spire: el transporte en proceso, el socket Unix de control y NATS llevan el mismo sobre, las mismas políticas y los mismos límites. Prohibido abrir conexiones NATS o sockets de control por otro camino: lo vigilan un test de arquitectura en TypeScript y la auditoría de seguridad en Zig. Los bytes de vídeo no pasan por spire.

Amenazas y cierreCopiar enlace

Identidad de servicioCopiar enlace

• NATS: modo operador con un usuario por servicio y su propia NKey, cuya semilla se monta como fichero de sólo lectura. Los permisos de publicar y suscribir se generan de BUS_ROUTES y un test regenera la ACL y la compara con la desplegada. Deny por defecto.
• Socket Unix: directorio 0750 y socket 0660 con grupo propio, comprobación de credenciales del par en cada conexión y un apretón de manos de spire en el que el par firma un reto con su clave de servicio. El uid solo no basta en contenedores con uids compartidos o mapeados. Sin apretón válido en pocos segundos se cierra sin procesar ningún mensaje.
• En proceso: sin criptografía (mismo proceso), pero con la misma política y la misma validación de contrato, de modo que mover un handler fuera de proceso no cambia su semántica.

Autorización obligatoriaCopiar enlace

Registrar un handler exige contrato, policy y función, y la policy no tiene valor por defecto. En Zig, si falta, no compila. En TypeScript, el tipo la exige y el servicio no arranca si algún subject suscrito no la tiene. La policy comprueba que el emisor está en la lista del subject y, si el mensaje actúa en nombre de un usuario, evalúa can(actor, acción, recurso) con el mismo motor que HTTP. Los clientes también declaran lo que envían: un servicio no puede publicar un subject que no figura en su contrato.

El sobreCopiar enlace

Incluye identificador (UUIDv7, para idempotencia), subject y versión de contrato, emisor, el JWT del usuario si lo hay, marca temporal y nonce, plazo, ids de correlación y traza, y una firma Ed25519 de la cabecera con el digest del payload.

• El actor no lo afirma el servicio: reenvía el JWT de acceso y el receptor lo verifica contra el JWKS de identity-svc. Un servicio comprometido no puede fabricar un actor.
• Anti-replay: ventana de reloj acotada y nonce de 128 bits, con caché por emisor y nonce. Una reentrega legítima de JetStream trae el mismo id y se trata como duplicado idempotente; el mismo nonce con otro id es un replay, se rechaza y se audita.

Validación y límitesCopiar enlace

• El payload se valida contra el contrato en ambos sentidos: entrada y salida. La salida también, para atrapar fugas de campos internos.
• Tamaño máximo por subject (declarado en el contrato, con un techo común), tasa por emisor y subject con cubo de fichas, concurrencia de handlers y contrapresión: un consumidor lento se desconecta y se audita. Un mensaje que llega caducado se descarta sin ejecutar el handler.
• El codec Zig es un parser de entrada no confiable y cumple los invariantes de seguridad del data plane: lectores acotados, aritmética comprobada, fuzz.

AuditoríaCopiar enlace

spire emite eventos evt.security.comms.* firmados y logs con atributos security.* para apretones fallidos, firmas inválidas, claves desconocidas, replay, denegaciones de policy, violaciones de contrato, límites superados y subjects no autorizados. Nunca payloads ni tokens.