Estou procurando uma forma de determinar dinamicamente qual credencial armazenada um nó usa em tempo de execução, com base em dados do workflow (por exemplo, um campo recebido como “cluster” ou “environment”), em vez de ter a credencial fixa por nó.
Para deixar claro, não estou falando sobre passar uma chave de API/segredo bruto como um valor de expressão dentro do workflow. Especificamente, quero referenciar e alternar entre diferentes credenciais n8n armazenadas dependendo da execução, para que o segredo real permaneça gerenciado no armazenamento de credenciais em vez de ser exposto no workflow em si.
Meu caso de uso: temos um workflow que triagem alertas provenientes de vários clusters Elastic, cada um com sua própria credencial armazenada. Gostaríamos que um único nó selecionasse a credencial correta por execução, dependendo de qual cluster os dados vieram, em vez de duplicar nós ou workflows por cluster.
Isso é atualmente possível em n8n de alguma forma (através de uma expressão no campo de credencial, algum tipo de lógica de seletor de credencial ou outro mecanismo), ou isso não é suportado hoje?
Não há uma opção dinâmica para selecionar uma credencial. No entanto, você pode criar um sub fluxo de trabalho que acionará um nó com uma credencial predefinida com base nos critérios que você escolher.
Por exemplo, tenho múltiplos nós HTTP com suas próprias credenciais que manipulam operações automaticamente com base na entrada
Oi @ntoll01
A parte selecionável pode ser o sub-workflow em vez da credencial. Um workflow por cluster, cada um contendo um único nó com a credencial desse cluster, chamado do workflow de triagem com Execute Sub-workflow definido como Source: Database e uma expressão no campo Workflow ID que mapeia o nome do cluster recebido para seu ID. Adicionar um cluster é então um novo workflow mais uma linha nesse mapa, sem nada crescendo no lado da triagem.
Cada um desses sub-workflows precisa que sua configuração “This workflow can be called by” permita o chamador, caso contrário a chamada falha em tempo de execução.
A versão nativa do que você pediu é uma solicitação de recurso aberta, que vale um voto:
Não há suporte nativo. Você não pode colocar uma expressão no seletor de credencial, e a solicitação de recurso para isso está aberta desde 2021. Os nós nativos bloqueiam a credencial no tempo de design.
O que você pode fazer em vez disso:
Se você estiver no Enterprise, procure por Dynamic Credentials e External Secrets. Essa é a versão apropriada do que você está descrevendo, credenciais resolvidas em tempo de execução em vez de fixadas no nó.
Para o Elastic especificamente, há uma opção mais simples. Use um nó HTTP Request em vez do nó Elastic, armazene o endpoint e a chave de cada cluster em uma busca e defina o cabeçalho de autenticação por expressão. Você perde a conveniência do nó, mas obtém um nó lidando com todos os clusters. A compensação é que a chave fica nos dados de execução em vez do armazenamento de credenciais, o que pode não ser aceitável dado o que você disse sobre manter os segredos gerenciados.
Você está no Enterprise? Isso decide qual dessas opções está realmente disponível para você.
@barn4k Pensei em múltiplos nós HTTP, mas na nossa situação temos 5 nós HTTP para criar o caso, adicionar alertas, definir o status, etc. Para 4 clusters já são 20 nós HTTP.
@Lopez estamos com uma licença comercial, então infelizmente não há possibilidade de usar External Secrets. Olhei para a solução alternativa e parece promissora, vou investigar isso.
@Anshul_Namdev essa provavelmente será nossa primeira solução alternativa, usando um fluxo de roteador com sub-fluxos por cliente.
@n8n há atualmente um desafio técnico em colocar uma expressão no seletor de credencial? Todas essas soluções alternativas parecem muito mais complexas do que um problema que poderia ser tratado com uma expressão, e a escalabilidade das nossas chamadas de API seria muito melhor com isso.
