Saltar al contenido principal
Flowker protege tus workflows, datos e integraciones mediante la autenticación de Access Manager y la gestión de credenciales por conexión. Lerian sirve la API sobre TLS. Esta página cubre el modelo de seguridad tal como está implementado en el release actual.

​
Autenticación de la plataforma

Flowker delega la autenticación de la plataforma en Access Manager. Cada solicitud a una ruta protegida de la API debe llevar un token Bearer (JWT de OIDC), y cada ruta protegida aplica un permiso por recurso y por acción. Así funciona la autorización basada en roles y en políticas.
Las credenciales inválidas o ausentes devuelven 401 Unauthorized.

​
Autenticación del proveedor

Cuando Flowker llama a un servicio externo, se autentica con las credenciales de la configuración de proveedor a través de la cual llama el nodo. Tus credenciales de plataforma y tus credenciales de proveedor permanecen separadas. Tipos de autenticación admitidos: El bloque config.auth de la configuración de proveedor contiene la autenticación que requiere el servicio externo, como un par { type, config }. Flowker la aplica a cada llamada que un nodo hace a través de esa conexión. Una lectura nunca devuelve la credencial que declara el tipo de autenticación. Guarda las credenciales solo en los campos que declara el tipo de autenticación. Para rotar un secreto, envía el nuevo valor en una actualización. Para conservar el actual, omite el campo o envíalo vacío. Esto funciona mientras auth.type siga siendo el mismo. Una actualización que cambia auth.type debe llevar un valor para cada secreto que el nuevo tipo requiere y el anterior no. De lo contrario, Flowker la rechaza con FLK-0952. Un cambio entre dos tipos que usan el mismo secreto, como de oidc_user a oidc_client_credentials, no necesita ese valor de nuevo.
Para los flujos de OIDC (oidc_client_credentials y oidc_user), Flowker gestiona la obtención y la renovación del token automáticamente. Para oidc_client_credentials, proporciona la URL del issuer, el client ID y el client secret. Para oidc_user, proporciona la URL del issuer, el client ID, el nombre de usuario y la contraseña. client_secret es opcional para clientes públicos.

​
Seguridad de red

TLS:
  • Lerian termina TLS para el tráfico de la API de Flowker.
  • Usa URLs base https:// para las llamadas externas. Flowker acepta una URI para el base_url del proveedor HTTP genérico. No lo restringe a HTTPS.
  • Transmite credenciales y payloads sensibles solo por enlaces cifrados.
Configuración de CORS: Flowker aplica estas reglas de CORS:
  • Solo los orígenes permitidos pueden llamar a la API desde un navegador. Para agregar un origen, contacta al soporte de Lerian
  • Las solicitudes de origen cruzado no pueden llevar credenciales (AllowCredentials permanece desactivado)
  • Las respuestas de preflight le indican al navegador que las guarde en caché durante una hora

​
Resiliencia

Flowker protege contra las fallas en cascada de los servicios externos con patrones de circuit breaker y de reintento. Circuit breaker: Cuando un servicio externo falla de forma repetida, el circuit breaker se abre y deja de enviar solicitudes. Esto evita que tus workflows se queden colgados esperando a un proveedor que no responde.
  • Transita por los estados closed → open → half-open
  • Cada circuito aplica a una configuración de proveedor y a un tenant, así que las fallas contra una conexión no afectan a otra
  • El estado half-open permite un número limitado de solicitudes de prueba antes de cerrarse por completo
Reintentos: Flowker resuelve el presupuesto de reintentos de cada nodo con las dos primeras reglas. La clase de falla decide luego si ese presupuesto se gasta:
  1. Activación en el nodo. Un retry.max_attempts mayor que 1 activa los reintentos sea cual sea el método. El valor es la cantidad total de intentos, y la plataforma lo limita a 5. Un retry.max_attempts de 1 no es una activación. Establece un solo intento.
  2. Método HTTP. Sin activación, Flowker trata POST y PATCH como no idempotentes y les da un solo intento. Todos los demás verbos reintentan, con 3 intentos totales de forma predeterminada. Esto incluye GET, HEAD, OPTIONS, PUT y DELETE.
  3. Clase de falla. El presupuesto se gasta solo en una falla transitoria: un error de red, un timeout en el intento, cualquier estado 5xx, o el estado 408 o 429. Todos los demás 4xx fallan en el primer intento por alto que sea el presupuesto. Un circuito abierto y una ejecución cancelada también detienen el bucle. Un cuerpo de solicitud que supera el límite de tamaño configurado y un cuerpo de respuesta que supera ese mismo límite también lo detienen.
El backoff es exponencial con jitter completo. Cada espera es un valor aleatorio entre cero y un techo. El techo empieza en 1 segundo y se duplica en cada intento. retry.backoff_seconds establece el primer techo, entre 1 y 60. La espera aleatoria evita que muchas ejecuciones reintenten contra el mismo servicio en el mismo momento.

​
Qué sigue

Guía de integración

Aprende a crear configuraciones de proveedor y a conectar servicios externos.

Observabilidad

Sigue las ejecuciones de workflows a través de sus registros de ejecución.