Vault Auto-Unseal com AWS KMS — Instalação via Kubernetes (EKS) & Helm

Olá,

A ideia deste artigo e auxiliar profissionais de tecnologia que estão começando a trabalhar com a ferramenta Vault da HashiCorp.

Contextualização

O HashiCorp Vault é um sistema de gerenciamento de segredos e criptografia baseado em identidade. A segredo é qualquer coisa que você deseja controlar firmemente o acesso, como chaves de criptografia de API, senhas e certificados. Quando um servidor Vault é iniciado, ele começa no estado seal (selado), isso significa que ele está em um modo onde não pode acessar os dados criptografados que estão armazenados em seu sistema. Sendo assim, como conseguimos “abrir” nosso cofre?

Opção 1 — Chaves de desbloqueio (Unseal Keys)

Este processo é stateful, sendo a opção mais comum. O vault usa um algoritmo conhecido como Shamir’s Secret Sharing, onde divide uma chave em vários compartilhamentos (partes). Para fazer o processo de unseal, e necessário passar uma quantidade mínima de compartilhamentos, que e definido no momento em que se inicia o operador, exemplo:

kubectl exec vault-0 -- vault operator init \
    -key-shares=5 \
    -key-threshold=3 \
    -format=json > cluster-keys.json

Key 1: ABDH-9832-ASDF-1298
Key 2: XZCV-5643-QWER-7654
Key 3: PLMK-9876-UIOP-5432
Key 4: POIU-8765-ASDF-4321
Key 5: QWER-1234-ZXCV-5678

O comando acima informa a ferramenta que vai criar 5 compartilhamentos de chave, e será necessário no mínimo 3 para fazer o processo de unseal.

Bom, esta opção e bem interessante, demonstra segurança e facilidade. Contudo, a ferramenta tem um porém, que e o seguinte: Caso o vault passe por instabilidade (ex: reload) o selamento acontece de forma automática. Com esta informação, surgem as seguintes perguntas:

1° Caso aconteça fora do hórario, irei ter pessoas disponíveis para fazer o unseal?
2° Onde armazeno essas chaves? 
3° Quem serão as pessoas que podem acessar?
4° Essas pessoas, estão prontas caso aconteça alguma eventualidade?
5° Existe algum rollback? E se for em ambientes produtivos?

Enfim, muitas dúvidas. Porém, temos contornar isso, pois existem algumas outras maneiras de desbloquear o cofre, vamos explorar agora uma delas!!

Opção 2° Auto-Unseal

Esta opção permite que o Vault seja desbloqueado automaticamente sem depender da intervenção humana a cada re/inicialização. Você pode realizar esta ação, fazendo uma integração com serviços externos de segurança na nuvem, como AWS Key Management Service (KMS), Google Cloud KMS, Azure Key Vault ou um módulo de hardware de segurança (HSM). Esses serviços ou dispositivos são responsáveis por gerar e gerenciar as chaves de desbloqueio de forma segura.

Interessante né? Então vamos a prática!

Irei apresentar de uma maneira bem simples, como pode ser feito a configuração de auto-unsel, utilizando um cluster EKS e uma chave KMS na AWS.

Passo 0

Instale o Vault em seu cluster Kubernetes. Eu utilizei a ferramenta HELM para me auxiliar nesta instalação:

https://developer.hashicorp.com/vault/docs/platform/k8s/helm

Passo 1

Crie uma chave gerenciada por VOCÊ no serviço AWS — KMS:

NA TELA SEGUINTE, COLOQUE OS ADMINISTRADORES DA CHAVE, LEMBRANDO QUE ESSES USERS/ROLE TERÃO PERMISSÃO TOTAL

Na última etapa, você precisa colocar a role que está associada ao seus NODES do EKS.

Passo 2

De a permissão para seus Nodes verem esta chave (vá na role referente aos mesmos e adicione a seguinte policy):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Action": [
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:DescribeKey"
            ],
            "Resource": [
                "arn:aws:kms:us-east-1:1245678910:key/xxxxxxx-yyyy-zzzzzz-yyyyy-ooooooo" # ALTERE PARA SEU ARN
            ]
        }
    ]
}

Passo 3

Instale o Vault via Helm

helm install vault oci://XXXXXXXXXX.dkr.ecr.us-east-1.amazonaws.com/vault --version 0.25.0 -n vault --set='server.ha.enabled=true' --set='server.ha.raft.enabled=true'   --set='server.ha.replicas=3' --set='server.ui.enabled=true'

No meu caso, eu armazenei o projeto helm no ECR. E preste bastante atenção, pois a instalação do VAULT precisa do driver de EBS disponível, devido aos volumes persistentes que serão criados.

Passo 4

Após a instalação concluída com êxito, você vai perceber que seus Pods estão Running, porém não estão “disponíveis” (??). Isso acontece pois o vault se inicia selado, então o serviço não se considera íntegro para comunicação. Neste momento, seria onde você acessaria o container vault-0 para criar as chaves para desbloqueios manuais, porém não e nosso caso! Com todas as permissões certas, vá para o configmap criado na namespace do vault, normalmente chamado de vault-config.

Nele, você vai adicionar as seguintes linhas:

    seal "awskms"{
      kms_key_id = "xxxxxxx-yyyy-zzzzzz-yyyyy-ooooooo" #SUA KMS KEY-ID
      region = "us-east-1"
    }

Ficara semlhante a isso:

Passo 5

Agora sim, tudo pronto, pode iniciar o vault com o comando

vault operator init

e você vai ver seu cofre já como unseal 0/

Porém, mesmo assim será gerado algumas chaves para você, e servem para autorização no vault, então armazene com segurança.

Bônus

Caso você já tenha um servidor vault funcionando, e deseja migrar para o auto unseal, você também pode aproveitar este conteúdo. Para realizar esta ação, basta você PAUSAR seu servidor vault, crie sua chave KMS (passo 1) adicione as informações de KMS (passo 4) e inicie o servidor novamente, porém agora, execute também o comando:

vault operator unseal -migrate

E isso, boa sorte nesta incrível jornada!