Pular para o conteúdo principal
O Flowker protege seus workflows, dados e integrações por meio de autenticação por API Key, gestão de credenciais por executor e aplicação de HTTPS. Esta página cobre o modelo de segurança conforme implementado na versão atual.

​
Autenticação da plataforma

Todos os endpoints da API do Flowker são protegidos por um middleware unificado de API Key. Cada requisição deve incluir uma API Key válida no header X-API-Key. 
curl -X GET https://sua-instancia-flowker/v1/workflows \
  -H "X-API-Key: sua-api-key"
Como funciona:
  • O middleware valida a API Key em cada requisição antes de processá-la
  • A autorização é binária — uma API Key válida concede acesso completo a todos os endpoints
  • As API Keys são configuradas via variáveis de ambiente ou configuração de bootstrap
  • Keys inválidas ou ausentes retornam 401 Unauthorized
Exceção de health check: Os endpoints /health, /health/live e /health/ready são excluídos da autenticação. Eles são projetados para monitoramento de infraestrutura (probes do Kubernetes, balanceadores de carga) e não expõem dados sensíveis.
A versão atual utiliza uma única API Key para todos os endpoints. Controle de acesso baseado em roles e autorização baseada em políticas (via Access Manager) estão planejados para versões futuras.

​
Autenticação de executors

Quando o Flowker chama serviços externos por meio de executors, cada configuração de executor especifica seu próprio método de autenticação. Isso significa que suas credenciais de plataforma e suas credenciais de provedor são gerenciadas separadamente. Tipos de autenticação suportados:
TipoDescriçãoCaso de uso
noneSem autenticaçãoServiços internos atrás de VPN ou service mesh
api_keyAPI Key enviada como header ou parâmetro de queryAPIs de terceiros com acesso baseado em chave
bearerBearer token no header AuthorizationServiços que usam tokens estáticos ou pré-gerados
basicAutenticação HTTP Basic (usuário:senha)Sistemas legados ou APIs internas
oidc_client_credentialsFluxo de credenciais de cliente OAuth 2.0Integrações máquina a máquina com provedores de identidade
oidc_userFluxo de token de usuário OAuth 2.0Integrações que agem em nome de um usuário específico
As credenciais de autenticação são armazenadas na configuração do executor e utilizadas automaticamente quando o executor é chamado durante a execução do workflow. 
{
  "name": "fraud-check",
  "description": "Scoring de fraude via Tracer",
  "baseUrl": "https://tracer.example.com",
  "endpoints": [
    {
      "name": "analyze",
      "path": "/v1/transactions/analyze",
      "method": "POST",
      "timeout": 30
    }
  ],
  "authentication": {
    "type": "bearer",
    "config": {
      "token": "eyJhbGciOiJSUzI1NiIs..."
    }
  }
}
Para os fluxos OIDC (oidc_client_credentials e oidc_user), o Flowker gerencia a aquisição e renovação de tokens automaticamente. Você só precisa fornecer a URL do emissor, o client ID e o client secret na configuração do executor.

​
Segurança de rede

Aplicação de HTTPS:
  • Todos os endpoints da API exigem HTTPS em produção
  • Chamadas de executors a provedores externos utilizam HTTPS
  • Dados sensíveis (credenciais, payloads de requisição/resposta) são sempre transmitidos por canais criptografados
Configuração de CORS: O Flowker suporta configuração de CORS personalizável:
  • As origens permitidas são configuráveis por implantação
  • Credenciais não são permitidas em requisições cross-origin (AllowCredentials está desabilitado)
  • Respostas de preflight são cacheadas para performance

​
Resiliência

O Flowker protege contra falhas em cascata de serviços externos usando padrões de circuit breaker e retentativas. Circuit breaker: Quando o serviço externo de um executor falha repetidamente, o circuit breaker abre e para de enviar requisições — evitando que seus workflows fiquem travados em um provedor que não responde.
  • Transita pelos estados closed → open → half-open
  • Os limiares são configurados globalmente (falhas consecutivas antes de abrir)
  • O estado half-open permite um número limitado de requisições de teste antes de fechar completamente
Retentativas: Chamadas falhas a executors são retentadas com backoff exponencial:
  • Contagem fixa de 5 tentativas com backoff exponencial (1s, 2s, 4s, 8s)
  • Backoff exponencial entre tentativas
  • Apenas falhas transitórias acionam retentativas (erros de rede, respostas 5xx)

​
Trilha de auditoria

Cada ação no Flowker é registrada no log de auditoria — alterações em workflows, eventos de execução, chamadas a executors e atualizações de configuração. Isso fornece uma cadeia completa de evidências para conformidade e visibilidade operacional.
  • Os eventos de auditoria são consultáveis via o endpoint /v1/audit-events com filtros por tipo de evento, ação, resultado, recurso e intervalo de datas
  • Cada entrada inclui um hash criptográfico que a vincula à entrada anterior, formando uma cadeia à prova de adulterações
  • A integridade da cadeia de hash é verificável via o endpoint /v1/audit-events/{id}/verify
  • Os logs incluem timestamps, identificação do ator (com endereço IP), tipo de ação e recursos afetados
Para detalhes sobre consulta de dados de auditoria, veja a referência da API de eventos de auditoria.

​
Próximos passos

Guia de integração

Aprenda como configurar executors e conectar serviços externos.

Observabilidade

Monitore o Flowker com traces, métricas e logs estruturados.