Saltar al contenido principal
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

Todos los endpoints de la API de Flowker están protegidos por un middleware unificado de API Key. Cada solicitud debe incluir una API Key válida en el header X-API-Key. 
curl -X GET https://tu-instancia-flowker/v1/workflows \
  -H "X-API-Key: tu-api-key"
Cómo funciona:
  • El middleware valida la API Key en cada solicitud antes de procesarla
  • La autorización es binaria — una API Key válida otorga acceso completo a todos los endpoints
  • Las API Keys se configuran mediante variables de entorno o configuración de arranque
  • Keys inválidas o ausentes retornan 401 Unauthorized
Excepción de health check: Los endpoints /health, /health/live y /health/ready están excluidos de la autenticación. Están diseñados para monitoreo de infraestructura (probes de Kubernetes, balanceadores de carga) y no exponen datos sensibles.
La versión actual utiliza una única API Key para todos los endpoints. El control de acceso basado en roles y la autorización basada en políticas (vía Access Manager) están planificados para versiones futuras.

​
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:
TipoDescripciónCaso de uso
noneSin autenticaciónServicios internos detrás de VPN o service mesh
api_keyAPI Key enviada como header o parámetro de queryAPIs de terceros con acceso basado en clave
bearerBearer token en el header AuthorizationServicios que usan tokens estáticos o pregenerados
basicAutenticación HTTP Basic (usuario:contraseña)Sistemas legados o APIs internas
oidc_client_credentialsFlujo de credenciales de cliente OAuth 2.0Integraciones máquina a máquina con proveedores de identidad
oidc_userFlujo de token de usuario OAuth 2.0Integraciones que actúan en nombre de un usuario específico
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. 
{
  "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 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
  • 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.

​
Próximos pasos

Guía de integración

Aprende cómo configurar executors y conectar servicios externos.

Observabilidad

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