> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # 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. export const GDSL = ({children}) => {children} ; 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. ```bash theme={null} curl -X GET https://tu-instancia-flowker/v1/workflows \ -H "Authorization: Bearer " ``` **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. ```json theme={null} { "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 *** Aprende cómo crear configuraciones de provider y conectar servicios externos. Monitorea Flowker con trazas, métricas y logs estructurados.