Autor: Sandro Savelli, Herospark
A gestão de segredos é um dos maiores desafios em ambientes modernos de desenvolvimento e operações. Deixar senhas hardcoded em repositórios, compartilhar tokens em chats ou até configurar manualmente acessos sensíveis pode abrir brechas de segurança sérias.
Neste cenário, ferramentas como o HashiCorp Vault surgem como solução robusta para armazenar, acessar e controlar segredos de forma segura, auditável e automatizada. Neste artigo, vamos entender como funciona o Vault, como configurá-lo em um cluster Kubernetes provisionado na Magalu Cloud, e como integrá-lo com ferramentas como o ArgoCD.
O Vault é uma ferramenta para gerenciamento seguro de segredos, certificados, tokens e outros dados sensíveis. Ele permite controlar acesso a segredos com controle baseado em políticas e autenticação pluggable.
Dependências Necessárias
Acesso ao Cluster MGC
Para interagir com um cluster Kubernetes provisionado na Magalu Cloud (MGC), é necessário utilizar o arquivo de configuração de acesso (kubeconfig). Esse arquivo contém as credenciais, o endpoint da API e as definições de contexto que permitem executar comandos com ferramentas como kubectl ou kubie.
O primeiro passo é acessar o console da MGC. No painel de Kubernetes, localize o cluster desejado e utilize a opção “Download Config” disponível no menu lateral.
Com o arquivo .yaml salvo localmente, o acesso ao cluster pode ser configurado no terminal com o seguinte comando:
kubie ctx -f /caminho/para/config.yaml
Esse comando define o contexto correto, garantindo que todas as operações subsequentes sejam executadas diretamente no cluster selecionado. Caso o kubie ainda não esteja instalado, consulte a seção de dependências para realizar a instalação.
Instalação via Helm como aplicação do ArgoCD
A instalação do Vault em um cluster Kubernetes pode ser feita utilizando Helm, com gerenciamento via ArgoCD. Para isso, é necessário salvar o arquivo values.yaml disponível no repositório oficial do Vault Helm Chart (link direto) em um diretório que já contenha outras aplicações gerenciadas pelo ArgoCD.
Após realizar os ajustes necessários no arquivo values.yaml, uma aplicação deve ser criada referenciando esse arquivo no Helm chart. O manifesto dessa aplicação deve seguir a estrutura padrão do ArgoCD, definindo nome, namespace de destino, fontes de repositório (tanto do repositório Git da infraestrutura quanto do Helm chart), e a configuração de sincronização automática. Dessa maneira:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: vault
namespace: argocd
spec:
destination:
namespace: ns-vault
name: in-cluster
project: default
sources:
- repoURL: git@github.com:Edools/mgc-infra.git
targetRevision: main
ref: values
- repoURL: https://helm.releases.hashicorp.com
chart: vault
targetRevision: 0.29.1(versão do chart aqui)
helm:
valueFiles:
- $values/caminho/para/values.yaml
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
- ApplyOutOfSyncOnly=true
- ServerSideApply=true
Com o manifesto pronto, a aplicação pode ser instalada executando o comando:
kubectl apply -f caminho/para/application.yaml
É importante lembrar que o arquivo application.yaml deve estar versionado no repositório monitorado pelo ArgoCD, para que a sincronização ocorra corretamente.
Acesso à interface web
Caso você deseje utilizar a interface web do Vault para gerenciar segredos ou realizar a configuração inicial, será necessário expor o serviço localmente, já que a instalação via ArgoCD com Helm não configura um recurso de Ingress por padrão.
Para isso, execute um redirecionamento de porta com o seguinte comando, substituindo pelo namespace e nome do serviço correspondente:
kubectl port-forward -n <namespace> svc/<servico-do-vault> 8200:8200
Com o túnel criado, o acesso ficará disponível em http://localhost:8200. No primeiro acesso, o Vault solicitará o processo de inicialização, durante o qual serão geradas as Unseal Keys e o Root Token. Certifique-se de salvar essas informações com segurança, pois serão necessárias para desbloquear e administrar a instância.
Seal, Unseal e Root Token
O Vault opera em estado seguro por padrão, utilizando um mecanismo chamado Seal, que impede qualquer leitura ou escrita de dados até que o serviço seja desbloqueado.
Seal
O Vault entra em modo selado automaticamente nas seguintes situações:
- Após a inicialização;
- Após reinício do serviço;
- Após comando manual (vault operator seal);
- Após falhas críticas ou perda de quorum em modo HA.
Unseal
Para desbloquear o Vault, é necessário realizar o processo de Unseal. Durante a inicialização, o Vault gera várias Unseal Keys. Um número mínimo delas (chamado de quorum) precisa ser fornecido para o Vault entrar em modo operacional. Essas chaves podem ser inseridas tanto pela interface web quanto pela CLI:
- Web UI
Ao acessar a interface web as chaves de unseal serão solicitadas.!
- CLI
Forneça as chaves geradas uma a uma:
vault operator unseal <Unseal-Key-1>
vault operator unseal <Unseal-Key-2>
vault operator unseal <Unseal-Key-3>
Após atingir o quorum de keys necessário, o Vault será desbloqueado.
Root Token
Junto das chaves de Unseal, o Vault também gera um Root Token, que concede acesso administrativo completo. Esse token deve ser guardado com extremo cuidado.
Com o Vault inicializado e desbloqueado, podemos agora armazenar e recuperar segredos de forma segura.
Como armazenar e recuperar segredos?
O Vault utiliza engines de armazenamento para guardar informações de forma segura. A engine mais comum é a KV (Key/Value), que permite registrar segredos simples no formato de pares chave:valor. Esses segredos podem ser escritos tanto pela interface web quanto pela CLI.
- Web UI
Na interface web do Vault, acesse a engine KV configurada (normalmente no caminho secret/) e clique em "Create secret".
Uma nova tela será exibida para preenchimento dos dados. Você pode inserir os pares chave:valor diretamente ou colar um objeto JSON.
- CLI
O armazenamento pela linha de comando é feito com o comando vault kv put, seguido do caminho e dos pares de dados. Por exemplo:
vault kv put secret/db password=supersecret
Neste exemplo:
- vault é o binário da CLI do Vault.
- kv indica que estamos utilizando a engine KV.
- put é a operação para gravar dados.
- secret/db é o caminho onde o segredo será armazenado.
- password=supersecret define a chave password com o valor supersecret.
Esse comando criará (ou sobrescreverá) um segredo no caminho especificado, criptografando automaticamente os dados.
Agora, se você quiser visualizar um segredo já armazenado, também é possível fazer isso tanto pela interface web quanto pela CLI.
- Web UI
Na Web UI, basta navegar até o caminho desejado dentro da engine e clicar sobre o item correspondente. Os valores armazenados serão exibidos em tela, junto com metadados como a versão e a data de modificação.
- CLI
Pela CLI, a leitura é feita com o comando:
vault kv get secret/db
Esse comando retorna os dados do segredo, incluindo todas as chaves e seus respectivos valores. O acesso será permitido apenas se a identidade ou token em uso tiver as permissões adequadas configuradas por meio de políticas.
Como habilitar um engine de segredos?
O Vault é modular e permite habilitar diferentes tipos de engines de segredo conforme a necessidade do seu ambiente. A engine KV (Key/Value), usada nos exemplos anteriores, é apenas uma entre várias disponíveis. Você pode, por exemplo, habilitar engines para geração dinâmica de credenciais de banco de dados, certificados TLS via PKI, ou integração com provedores de nuvem.
A habilitação de um engine define o caminho (prefixo) onde os segredos serão armazenados ou gerados, e pode ser feita tanto via Web UI quanto pela linha de comando.
- Web UI
Na interface web, acesse a seção “Secrets Engines” e clique em “Enable new engine”. Será exibido um painel para escolha do tipo de engine, onde você pode selecionar “Key/Value” (caso ainda não tenha sido habilitada) e definir o caminho onde os segredos serão armazenados, como secret/.
- CLI
O comando abaixo habilita uma engine KV no caminho secret/:
vault secrets enable -path=secret kv
Neste comando:
- secrets enable ativa uma nova engine.
- -path=secret define o prefixo pelo qual a engine será acessada.
- kv especifica o tipo da engine.
Com a engine habilitada e configurada, já é possível definir políticas de acesso que controlam quem pode visualizar, escrever ou gerenciar os segredos armazenados.
Como criar políticas de acesso?
O controle de acesso no Vault é feito por meio de políticas que definem, de forma precisa, quais ações um usuário ou aplicação pode realizar em determinados caminhos. Essas políticas são escritas em HCL (HashiCorp Configuration Language) e podem ser aplicadas via CLI ou criadas diretamente pela interface web.
- Web UI
Na Web UI, o processo começa acessando a seção “Policies” no menu lateral. Lá, clique em “Create ACL Policy” para abrir o editor de políticas.
Você poderá dar um nome à política e inserir as regras em HCL. Por exemplo, uma política que permite leitura em um segredo específico pode ser definida da seguinte forma:
- CLI
Esse mesmo resultado pode ser alcançado pela CLI. Primeiro, crie um arquivo chamado policy.hcl com o conteúdo desejado:
path "secret/data/db" {
capabilities = ["read"]
}
Depois, aplique a política no Vault com o seguinte comando:
vault policy write read-db policy.hcl
Isso registrará a política no Vault com o nome read-db. Posteriormente, essa política poderá ser associada a tokens, usuários, grupos ou entidades autenticadas, garantindo que apenas quem possui a permissão adequada possa acessar os segredos.
Com as políticas criadas e aplicadas, já é possível avançar para a integração com outras ferramentas do ecossistema, como o ArgoCD, usando o ArgoCD Vault Plugin.
Integração com ArgoCD (via AVP)
Para integrar o Vault com aplicações gerenciadas via ArgoCD, é possível utilizar o ArgoCD Vault Plugin (AVP). Esse plugin permite que os manifests sejam declarados com referências a segredos armazenados no Vault, evitando que informações sensíveis fiquem versionadas em repositórios Git.
A configuração do AVP no ArgoCD exige a instalação do plugin na imagem usada pelo repositório do ArgoCD. Após isso, o plugin fica responsável por interceptar os manifests antes de serem aplicados, substituindo as expressões com valores reais extraídos do Vault.
Uma vez que o plugin esteja configurado, o uso nos manifests é bastante simples. Em vez de declarar diretamente um valor sensível, você pode referenciar o segredo armazenado no Vault utilizando a seguinte sintaxe:
apiVersion: v1
kind: Secret
metadata:
name: exemplo-secret
stringData:
PASSWORD: <path:secret/data/db#password>
Nesse exemplo, o valor da chave PASSWORD será extraído do caminho secret/data/db, buscando especificamente o campo password.
Alterei um segredo, e agora?
Após qualquer alteração nos segredos, é necessário realizar um Hard Refresh da aplicação no ArgoCD para que os valores sejam reaplicados corretamente no cluster. Essa abordagem torna o processo mais seguro e dinâmico, eliminando a necessidade de manter cópias locais de senhas ou tokens sensíveis.
Top comments (0)