Seguridad

Protege workflows, datos e integraciones de Flowker con autenticación vía Access Manager, credenciales por conexión y TLS gestionado por el despliegue.

Flowker protege tus workflows, datos e integraciones mediante autenticación vía Access Manager y gestión de credenciales por conexión. El TLS para el tráfico de API lo gestiona tu despliegue. Esta página cubre el modelo de seguridad tal como está implementado en la versión actual.

​

Autenticación de la plataforma

---

Flowker delega la autenticación de la plataforma a Access Manager, habilitado con PLUGIN_AUTH_ENABLED. Cuando está habilitado, cada solicitud a una ruta de API protegida debe llevar un Bearer token (JWT OIDC) y cada ruta protegida aplica un permiso por recurso y por acción — así se aplica la autorización basada en roles y en políticas.

Habilita Access Manager en producción.

curl -X GET https://tu-instancia-flowker/v1/workflows \
  -H "Authorization: Bearer <token>"

Cómo funciona:

• Access Manager habilitado — cada solicitud a una ruta de API protegida lleva un Bearer token y cada ruta protegida aplica un permiso por recurso y por acción.
• Access Manager deshabilitado — los endpoints no requieren autenticación. La identidad de un Bearer token, cuando está presente, se lee igualmente en la medida de lo posible, de modo que la solicitud se atribuye al sujeto declarado. Usa este modo solo para desarrollo local.
• Las credenciales inválidas o ausentes retornan 401 Unauthorized.

Excepción de sondas de salud:

Las sondas de liveness y readiness están excluidas de la autenticación. Están diseñadas para monitoreo de infraestructura (sondas de Kubernetes, balanceadores de carga) y no exponen datos sensibles.

​

Autenticación de providers

---

Cuando Flowker llama a un servicio externo, se autentica con las credenciales de la configuración de provider a través de la cual llama el node. Tus credenciales de plataforma y tus credenciales de provider se gestionan por separado.

Tipos de autenticación soportados:

Tipo	Descripción	Caso de uso
none	Sin autenticación	Servicios internos detrás de VPN o service mesh
api_key	API Key enviada como header o parámetro de query	APIs de terceros con acceso basado en clave
bearer	Bearer token en el header Authorization	Servicios que usan tokens estáticos o pregenerados
basic	Autenticación HTTP Basic (usuario:contraseña)	Sistemas legados o APIs internas
oidc_client_credentials	Flujo de credenciales de cliente OAuth 2.0	Integraciones máquina a máquina con providers de identidad
oidc_user	Flujo de token de usuario OAuth 2.0	Integraciones que actúan en nombre de un usuario específico
oauth2_token_endpoint	Client credentials OAuth 2.0 contra un token endpoint (sin discovery OIDC)	Providers estilo OAuth2 sin metadatos de discovery OIDC
hmac	Firma de solicitudes con un secreto HMAC compartido	Providers que verifican un header de firma de solicitud

El bloque config.auth de la configuración de provider contiene la autenticación que exige el servicio externo, como un par { type, config }. Flowker la aplica en cada llamada que un node hace por esa conexión.

Los campos secretos de config.auth — una API key, un token bearer, una contraseña, un client secret o un secreto HMAC — se envían al backend de secretos y se eliminan de la configuración persistida. Cuando está configurada la lectura de secretos, una lectura autorizada de la configuración de provider puede resolverlos para mostrarlos. Restringe ese permiso y trata su respuesta como sensible.

Cualquier otra cosa que pongas en el documento de configuración — un header, por ejemplo — se almacena junto con la configuración, y una lectura puede devolverla. Pon cada credencial en config.auth.

Para rotar un secreto, envía el nuevo valor en una actualización. Para conservar el actual, omite el campo o envíalo en blanco: esto funciona mientras auth.type no cambie. Una actualización que cambia auth.type debe llevar un valor para cada secreto que el nuevo tipo exige y el anterior no exigía; si falta, 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 otra vez.

{
  "config": {
    "auth": {
      "type": "bearer",
      "config": {
        "token": "eyJhbGciOiJSUzI1NiIs..."
      }
    }
  }
}

Para los flujos OIDC (oidc_client_credentials y oidc_user), Flowker gestiona la adquisición y renovación de tokens automáticamente. Para oidc_client_credentials, proporciona la URL del emisor, el client ID y el client secret. Para oidc_user, proporciona la URL del emisor, el client ID, el nombre de usuario y la contraseña; client_secret es opcional para clientes públicos.

​

Seguridad de red

---

TLS:

• Configura la terminación TLS para el tráfico de API de Flowker en tu despliegue.
• Usa URL base https:// para llamadas externas. Flowker acepta una URI para el base_url del provider HTTP genérico; no lo restringe a HTTPS.
• Transmite credenciales y payloads sensibles solo por enlaces cifrados.

Configuración de CORS:

Flowker soporta configuración de CORS personalizable:

• Los orígenes permitidos son configurables por despliegue
• Las credenciales no están permitidas en solicitudes de origen cruzado (AllowCredentials está deshabilitado)
• Las respuestas de preflight se cachean para rendimiento

​

Resiliencia

---

Flowker protege contra fallas en cascada de servicios externos mediante patrones de circuit breaker y reintentos.

Circuit breaker:

Cuando un servicio externo falla repetidamente, el circuit breaker se abre y deja de enviar solicitudes — evitando que tus workflows queden colgados por un servicio que no responde.

• Transita por los estados closed → open → half-open
• El circuito tiene alcance por configuración de provider y por tenant, así que las fallas contra una conexión no afectan a otra
• Los umbrales se configuran globalmente (fallas consecutivas antes de abrir)
• El estado half-open permite un número limitado de solicitudes de prueba antes de cerrarse completamente

Reintentos:

Flowker resuelve el presupuesto de reintentos de cada node con las dos primeras reglas. Luego la clase de falla decide si ese presupuesto se gasta:

1. Suscripción del node. Un retry.max_attempts mayor que 1 activa los reintentos sin importar 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 suscripción: fija un solo intento.
2. Método HTTP. Sin suscripción, POST y PATCH se tratan como no idempotentes y reciben un solo intento. GET, HEAD, OPTIONS, PUT, DELETE y cualquier otro verbo se reintentan, con 3 intentos totales por defecto.
3. Clase de falla. El presupuesto solo se gasta en una falla transitoria: un error de red, un timeout en el intento, cualquier estado 5xx, o el estado 408 o 429. Cualquier otro 4xx falla en el primer intento por alto que sea el presupuesto. Un circuito abierto, una ejecución cancelada, un cuerpo de solicitud por encima del límite de tamaño configurado y un cuerpo de respuesta por encima del mismo límite también detienen el bucle.

El backoff es exponencial con jitter completo. Cada espera es un valor aleatorio entre cero y un techo. El techo comienza en 1 segundo y se duplica en cada intento. retry.backoff_seconds define el primer techo, entre 1 y 60. La espera aleatoria impide que muchas ejecuciones reintenten el mismo servicio en el mismo momento.

​

Próximos pasos

---

Guía de integración

Aprende cómo crear configuraciones de provider y conectar servicios externos.

Observabilidad

Monitorea Flowker con trazas, métricas y logs estructurados.