Documentation Index
Fetch the complete documentation index at: https://docs.crewai.com/llms.txt
Use this file to discover all available pages before exploring further.
Visão Geral
Este guia mostra como verificar que um segredo rotacionado no seu provedor de nuvem é pego no próprio kickoff de automação seguinte — sem novo deploy, sem reinício de worker. É relevante apenas quando você configurou uma credencial baseada em Workload Identity (AWS, GCP, Azure). Deployments com credenciais estáticas exigem um novo deploy após a rotação; nada a verificar aqui. A receita abaixo usa um crew minúsculo e autocontido com uma ferramenta, um agente, uma tarefa. O prompt do crew nunca referencia o valor do segredo — em vez disso, uma ferramenta o lê deos.environ e reporta um fingerprint SHA-256 do que ela vê. Rotacione o segredo no seu provedor de nuvem, dispare novamente e o fingerprint muda.
Por que um fingerprint, não o valor bruto? Colocar segredos brutos na saída do LLM e em trace logs é um vetor de vazamento. O fingerprint é suficiente para confirmar “o valor mudou” sem escrever o valor real em nenhum lugar observável.
Pré-requisitos
Antes de executar esta verificação:- Uma Secret Provider Credential baseada em WI está configurada (AWS, GCP, Azure).
- Uma variável de ambiente no seu deployment com
Secret = true, chaveAPI_KEY(ou qualquer nome que preferir — ajuste a ferramenta abaixo para corresponder), referenciando um segredo no seu provedor de nuvem. - Uma forma de atualizar o valor do segredo no seu provedor de nuvem (acesso à CLI ou ao console da nuvem).
- Uma forma de disparar o deployment via HTTP (curl, Postman ou a aba Run na CrewAI Platform).
Passo 1 — Estruturar um Crew de Verificação
Crie um novo projeto de crew. O CrewAI CLI estrutura tudo:Passo 2 — Adicionar a Ferramenta de Echo de Credencial
Substituasrc/rotation_verifier/tools/custom_tool.py por uma ferramenta que lê a env var apoiada pelo segredo e retorna um fingerprint:
src/rotation_verifier/tools/credential_echo_tool.py
Passo 3 — Substituir as Configs Padrão de Agente e Task
O crew tem um agente e uma tarefa — ambos com descrições que nunca mencionam o valor do segredo, para que as chaves de tarefa permaneçam estáveis entre rotações.src/rotation_verifier/config/agents.yaml
src/rotation_verifier/config/tasks.yaml
Passo 4 — Conectar a Classe do Crew
src/rotation_verifier/crew.py
Passo 5 — Fazer Deploy e Configurar a Env Var do Segredo
Faça deploy deste crew na CrewAI Platform exatamente como você faria com qualquer outro crew. Em seguida, na página Environment Variables do deployment:- Key:
API_KEY(deve corresponder aENV_VAR_NAMEna ferramenta) - Value Source: a credencial baseada em WI que você configurou em AWS WI ou GCP WI
- Secret Name: o nome do segredo no Secret Manager do seu provedor de nuvem
Passo 6 — Executar o Primeiro Kickoff
Substitua<DEPLOYMENT_AUTH_TOKEN> e <DEPLOYMENT_HOST> por valores da aba Run do seu deployment.
Passo 7 — Rotacionar o Segredo no Seu Provedor de Nuvem
- AWS
- GCP
- Azure
Passo 8 — Executar um Segundo Kickoff e Comparar
O que Isso Verifica — e o que Não Verifica
Verifica:- A emissão de tokens OIDC do WI a partir da CrewAI Platform funciona.
- A confiança do lado da nuvem (provedor IAM OIDC para AWS, Workload Identity Pool para GCP, Federated Identity Credential para Azure) aceita o token.
- A identidade do lado da nuvem (IAM Role / GCP service account / Entra App Registration) tem acesso para ler o segredo.
- O valor do segredo chega ao
os.environdo processo worker no momento do kickoff. - Rotações subsequentes se propagam para o próximo kickoff.
- Que seus crews de produção reais lidam com a rotação graciosamente — ex., tarefas de longa duração que leem a env var uma vez na inicialização continuarão usando o valor antigo até que a tarefa termine. Planeje conforme: leia segredos no ponto de uso, não no momento do import do módulo.
Por que Não Referenciar o Segredo Diretamente no Prompt?
Uma demonstração de aparência mais simples colocaria o valor do segredo diretamente em uma descrição de tarefa (ex.: “Research about{api_key}”) e inspecionaria o prompt. Não faça isso. Duas razões:
- Isso vaza o segredo para traces de chamadas LLM e logs do lado do provedor. Qualquer um com acesso a traces pode lê-lo.
- Isso muda a descrição da tarefa a cada kickoff. A CrewAI Platform identifica tarefas por um hash MD5 da descrição; um valor rotativo significa que o hash muda por kickoff, o que quebra o mapeamento deploy-time → runtime das tarefas. Sintoma: os registros de tarefa aparecem como
pending_runindefinidamente, ou apenas algumas das tarefas de um crew multi-task se registram.
Próximos Passos
- Voltar à visão geral do Secrets Manager
- Uma vez verificado, descarte o crew de verificação. Crews reais devem seguir o mesmo padrão: segredos acessados via
os.environdentro de uma ferramenta, nunca substituídos em prompts.
