> ## 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 los workflows, los datos y las integraciones de Flowker con autenticación de Access Manager, credenciales por conexión y TLS gestionado por el despliegue.

export const GDSL = ({children}) => <Tooltip headline="DSL (Domain-Specific Language)" tip="Un lenguaje simplificado diseñado para un propósito específico. En el caso de Flowker, se usa para definir los pasos y las reglas de un workflow sin escribir código de propósito general." cta="Ver glosario" href="/es/start-here/glossary">
    {children}
  </Tooltip>;

Flowker protege tus workflows, datos e integraciones mediante la autenticación de Access Manager y la gestión de credenciales por conexión. Tu despliegue gestiona TLS para el tráfico de la API. 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**, que se habilita con `PLUGIN_AUTH_ENABLED`. Cuando está habilitado, 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.

Habilita Access Manager en producción.

```bash theme={null}
curl -X GET https://your-flowker-instance/v1/workflows \
  -H "Authorization: Bearer <token>"
```

**Cómo funciona:**

* **Access Manager habilitado**: cada solicitud a una ruta protegida de la API lleva un token Bearer, y cada ruta protegida aplica un permiso por recurso y por acción.
* **Access Manager deshabilitado**: los endpoints no requieren autenticación. Cuando hay un token Bearer presente, Flowker igual lee la identidad de él en la medida de lo posible. Flowker atribuye la solicitud al sujeto declarado. Usa este modo solo para desarrollo local.
* Las credenciales inválidas o ausentes devuelven `401 Unauthorized`.

**Excepción de las sondas de salud:**

Las sondas de liveness y readiness no requieren autenticación. Sirven al monitoreo de infraestructura (sondas de Kubernetes, balanceadores de carga) y no exponen datos sensibles.

## 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:**

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

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.

Flowker envía las hojas secretas de `config.auth` (una API key, un token bearer, una contraseña, un client secret o un secreto HMAC) al backend de secretos. Luego las quita de la configuración persistida. Con la lectura de secretos configurada, una lectura autorizada de la configuración de proveedor puede resolverlas para mostrarlas. Restringe ese permiso y trata su respuesta como sensible.

Cualquier otra cosa que coloques en el documento de configuración (un header, por ejemplo) permanece con la configuración, y una lectura puede devolverla. Coloca 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 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.

```json theme={null}
{
  "config": {
    "auth": {
      "type": "bearer",
      "config": {
        "token": "eyJhbGciOiJSUzI1NiIs..."
      }
    }
  }
}
```

<Note>
  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.
</Note>

## Seguridad de red

***

**TLS:**

* Configura la terminación TLS para el tráfico de la API de Flowker en tu despliegue.
* 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 admite ajustes de CORS configurables:

* Los orígenes permitidos se configuran por despliegue
* Las solicitudes de origen cruzado no pueden llevar credenciales (`AllowCredentials` permanece desactivado)
* Flowker cachea las respuestas de preflight por rendimiento

## 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
* Configuras los umbrales de forma global (fallas consecutivas antes de abrir)
* 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

***

<CardGroup cols={2}>
  <Card title="Guía de integración" icon="plug" href="/es/products/flowker/integration-guide">
    Aprende a crear configuraciones de proveedor y a conectar servicios externos.
  </Card>

  <Card title="Observabilidad" icon="chart-line" href="/es/products/flowker/flowker-observability-guide">
    Monitorea Flowker con trazas, métricas y logs estructurados.
  </Card>
</CardGroup>
