Conceito e mecanismo
Consul usa vários canais com responsabilidades diferentes. Gossip mantém membership e eventos; RPC, API e comunicação do mesh precisam dos respetivos controlos. Uma chave gossip não converte um listener HTTP em HTTPS, e TLS não limita sozinho as operações autorizadas. Confirma configuração efetiva em vez de assumir defaults universais entre versões. Para TLS, verifica cadeia, CA confiada e identidade esperada; uma falha após renovação não justifica desligar verificação permanentemente. Para gossip, a rotação deve instalar a chave nova, confirmar distribuição, promovê-la e só depois remover a anterior. A maioria Raft não é critério suficiente para concluir distribuição de uma chave aos participantes.
Aplicação guiada
ACL tokens ligam o chamador às permissões concedidas por policies e identidades. SecretID é a credencial apresentada; AccessorID permite identificar o token em operações de gestão. Não confundas descrição com privilégio: chamar reader a um token management não o limita. Uma automação que atualiza apps/funds/ deve receber o âmbito necessário e ser testada fora dele. O token de bootstrap não deve tornar-se a identidade partilhada de todas as integrações. Protege também ficheiros de configuração e dados no sistema operativo. Se a API aceita registo remoto de scripts executáveis, existe uma superfície de execução no host que requer controlo próprio. Na passagem a RUN, documenta rotação, revogação e recuperação sem colocar segredos nos logs.
Chave nova em seis de sete agentes: falta concluir distribuição antes da promoção.
Armadilhas comuns
TLS como autorização; gossip como HTTPS; AccessorID como credencial; nome da policy como controlo.
Tópicos relacionados: Descoberta, arquitetura e quorum · Deployment e bootstrap · Registo, health checks e DNS
Verifica cada canal e concede apenas operações necessárias por integração.
Referência: Consul security layers · Historical Consul Associate (003), retired 2026-07-15; technical references inspected 2026-09-30