Pular para o conteúdo principal
O Flowker protege seus workflows, dados e integrações com autenticação pelo Access Manager e gestão de credenciais por conexão. A Lerian serve a API por TLS. Esta página cobre o modelo de segurança como implementado no release atual.

​
Autenticação da plataforma

O Flowker delega a autenticação da plataforma ao Access Manager. Cada requisição a uma rota de API protegida deve carregar um Bearer token (OIDC JWT), e cada rota protegida aplica uma permissão por recurso e por ação. É assim que funciona a autorização por papel e por política.
Credenciais inválidas ou ausentes retornam 401 Unauthorized.

​
Autenticação de provedor

Quando o Flowker chama um serviço externo, ele autentica com as credenciais da configuração de provedor pela qual o nó chama. Suas credenciais de plataforma e suas credenciais de provedor ficam separadas. Tipos de autenticação aceitos: O bloco config.auth na configuração de provedor guarda a autenticação que o serviço externo exige, como um par { type, config }. O Flowker aplica isso a cada chamada que um nó faz por essa conexão. Uma leitura nunca retorna a credencial que o tipo de autenticação declara. Guarde credenciais apenas nos campos que o tipo de autenticação declara. Para rotacionar um secret, envie o novo valor em uma atualização. Para manter o atual, omita o campo ou envie-o em branco. Isso funciona enquanto auth.type continua o mesmo. Uma atualização que muda auth.type deve carregar um valor para cada secret que o novo tipo exige e o anterior não exigia. Caso contrário, o Flowker a rejeita com FLK-0952. Uma mudança entre dois tipos que usam o mesmo secret, como oidc_user para oidc_client_credentials, não precisa desse valor de novo.
Para fluxos OIDC (oidc_client_credentials e oidc_user), o Flowker cuida da obtenção e da renovação de token automaticamente. Para oidc_client_credentials, informe a URL do issuer, o client ID e o client secret. Para oidc_user, informe a URL do issuer, o client ID, o username e a senha. client_secret é opcional para clients públicos.

​
Segurança de rede

TLS:
  • A Lerian faz a terminação TLS do tráfego de API do Flowker.
  • Use URLs base https:// para chamadas externas. O Flowker aceita uma URI no base_url do provedor HTTP genérico. Ele não a restringe a HTTPS.
  • Transmita credenciais e payloads sensíveis apenas por conexões criptografadas.
Configuração de CORS: O Flowker aplica estas regras de CORS:
  • Só origens permitidas chamam a API pelo navegador. Para incluir uma origem, entre em contato com o suporte da Lerian
  • Requisições cross-origin não podem carregar credenciais (AllowCredentials fica desligado)
  • As respostas de preflight dizem ao navegador para mantê-las em cache por uma hora

​
Resiliência

O Flowker protege contra falhas em cascata vindas de serviços externos com os padrões circuit breaker e nova tentativa. Circuit breaker: Quando um serviço externo falha repetidamente, o circuit breaker abre e para de enviar requisições. Isso evita que seus workflows travem em um provedor que não responde.
  • Passa pelos estados closed → open → half-open
  • Cada circuito se aplica a uma configuração de provedor e a um tenant, então falhas contra uma conexão não afetam outra
  • O estado half-open permite um número limitado de requisições de teste antes de fechar por completo
Novas tentativas: O Flowker resolve o orçamento de tentativas de cada nó com as duas primeiras regras. A classe da falha então decide se esse orçamento é gasto:
  1. Adesão no nó. Um retry.max_attempts maior que 1 liga as novas tentativas seja qual for o método. O valor é a contagem total de tentativas, e a plataforma limita isso a 5. Um retry.max_attempts de 1 não é uma adesão. Ele define uma única tentativa.
  2. Método HTTP. Sem adesão, o Flowker trata POST e PATCH como não idempotentes e dá a eles uma única tentativa. Cada outro verbo tenta de novo, com 3 tentativas no total por padrão. Isso inclui GET, HEAD, OPTIONS, PUT e DELETE.
  3. Classe da falha. O orçamento é gasto apenas em uma falha transitória: um erro de rede, um timeout na tentativa, qualquer status 5xx, ou status 408 ou 429. Cada outro 4xx falha na primeira tentativa por mais alto que seja o orçamento. Um circuito aberto e uma execução cancelada também param o laço. Um corpo de requisição acima do limite de tamanho configurado e um corpo de resposta acima do mesmo limite também o param.
O backoff é exponencial com full jitter. Cada espera é um valor aleatório entre zero e um teto. O teto começa em 1 segundo e dobra a cada tentativa. retry.backoff_seconds define o primeiro teto, entre 1 e 60. A espera aleatória evita que muitas execuções tentem de novo o mesmo serviço no mesmo momento.

​
O que vem a seguir

Guia de integração

Aprenda a criar configurações de provedor e conectar serviços externos.

Observabilidade

Acompanhe as execuções de workflow pelos registros de execução.