> ## 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 por API Key, credenciales por ejecutor y endpoints forzados a HTTPS. export const GDSL = ({children}) => {children} ; Flowker protege tus workflows, datos e integraciones mediante autenticación por API Key, gestión de credenciales por executor y cumplimiento de HTTPS. Esta página cubre el modelo de seguridad tal como está implementado en la versión actual. ## Autenticación de la plataforma *** Flowker admite dos modos de autenticación de plataforma, seleccionados por configuración: * **API Key** — una clave estática enviada en el header `X-API-Key`, habilitada con `API_KEY_ENABLED`. * **Access Manager** — autenticación basada en tokens, habilitada con `PLUGIN_AUTH_ENABLED`. Cuando ambos modos están habilitados, Access Manager tiene prioridad. Habilita al menos un modo en producción. ```bash theme={null} curl -X GET https://tu-instancia-flowker/v1/workflows \ -H "X-API-Key: tu-api-key" ``` **Cómo funciona:** * **Modo API Key** — el middleware valida la clave en cada solicitud; una clave válida otorga acceso a todos los endpoints. Configura la clave mediante variables de entorno o configuración de arranque. * **Modo Access Manager** — cada solicitud lleva un Bearer token y cada ruta aplica un permiso por recurso y por acción. Así se aplica la autorización basada en roles y en políticas. * 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. Además de la API Key estática, Flowker puede delegar la autenticación y la autorización por recurso y por acción a Access Manager. Habilítalo mediante configuración; cuando está habilitado, las solicitudes llevan un Bearer token y cada ruta aplica su propio permiso de recurso/acción. ## Autenticación de executors *** Cuando Flowker llama a servicios externos a través de executors, cada configuración de executor especifica su propio método de autenticación. Esto significa que tus credenciales de plataforma y tus credenciales de proveedor 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 proveedores 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) | Proveedores estilo OAuth2 sin metadatos de discovery OIDC | Las credenciales de autenticación se almacenan en la configuración del executor y se utilizan automáticamente cuando el executor es invocado durante la ejecución del workflow. ```json theme={null} { "name": "fraud-check", "description": "Scoring de fraude vía Tracer", "baseUrl": "https://tracer.example.com", "endpoints": [ { "name": "analyze", "path": "/v1/transactions/analyze", "method": "POST", "timeout": 30 } ], "authentication": { "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. Solo necesitas proporcionar la URL del emisor, el client ID y el client secret en la configuración del executor. ## Seguridad de red *** **Cumplimiento de HTTPS:** * Todos los endpoints de la API requieren HTTPS en producción * Las llamadas de executors a proveedores externos utilizan HTTPS * Los datos sensibles (credenciales, payloads de solicitud/respuesta) siempre se transmiten por canales 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 el servicio externo de un executor falla repetidamente, el circuit breaker se abre y deja de enviar solicitudes — evitando que tus workflows queden colgados por un proveedor que no responde. * Transita por los estados `closed` → `open` → `half-open` * 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:** Las llamadas fallidas a executors se reintentan con backoff exponencial: * Cantidad fija de 5 reintentos con backoff exponencial (1s, 2s, 4s, 8s) * Backoff exponencial entre intentos * Solo las fallas transitorias activan reintentos (errores de red, respuestas 5xx) ## Registro de auditoría *** Cada acción en Flowker se registra en el log de auditoría — cambios en workflows, eventos de ejecución, llamadas a executors y actualizaciones de configuración. Esto proporciona una cadena completa de evidencia para cumplimiento y visibilidad operacional. * Los eventos de auditoría son consultables vía el endpoint [`/v1/audit-events`](/es/reference/flowker/search-audit-events) con filtros por tipo de evento, acción, resultado, recurso y rango de fechas * Cada entrada incluye un hash criptográfico que la vincula con la entrada anterior, formando una cadena a prueba de manipulaciones * La integridad de la cadena de hashes es verificable vía el endpoint [`/v1/audit-events/{id}/verify`](/es/reference/flowker/verify-audit-hash-chain) * Los logs incluyen timestamps, identificación del actor (con dirección IP), tipo de acción y recursos afectados Para detalles sobre consulta de datos de auditoría, consulta la [referencia de la API de eventos de auditoría](/es/reference/flowker/search-audit-events). ## Próximos pasos *** Aprende cómo configurar executors y conectar servicios externos. Monitorea Flowker con trazas, métricas y logs estructurados.