Como encriptar o ETCD do Kubernetes com o OVHcloud KMS

Ver como Markdown

Descubra como configurar o Kubernetes para encriptar o armazenamento ETCD com a interface KMIP do OVHcloud KMS

Objetivo

Este guia explica como configurar o fornecedor de encriptação do kube-apiserver que permite aos clusters Kubernetes encriptar e desencriptar os dados em repouso utilizando o OVHcloud KMS através do protocolo KMIP.

Requisitos

Instruções

Instalação do binário

O binário pode ser instalado diretamente a partir dos pacotes Go.

go install github.com/ovh/okms-k8s-encryption-provider@latest

Em alternativa, pode compilá-lo a partir das fontes.

git clone https://github.com/ovh/okms-k8s-encryption-provider.git
cd okms-k8s-encryption-provider
go build -o okms-k8s-encryption-provider

Configuração do OVHcloud KMS (OKMS)

Para utilizar o OVHcloud KMS como fornecedor de encriptação para o Kubernetes, irá precisar dos seguintes elementos:

  • Um utilizador OVHcloud e permissões para gerir as chaves KMIP do OKMS.
  • Um certificado de acesso para o seu domínio OKMS.
  • Uma chave KMIP AES no seu OKMS.

Criação do utilizador e das permissões de acesso

Crie um utilizador local IAM com permissões de acesso ao seu domínio.

Se, em alternativa, utilizar políticas IAM, o utilizador deve ter, pelo menos, as seguintes permissões no domínio OKMS:

  • okms:kmip:encrypt
  • okms:kmip:decrypt
  • okms:kmip:locate

Caso contrário, o utilizador deve pertencer a um grupo com a função ADMIN.

Também é possível criar um utilizador utilizando a CLI OVHcloud:

ovhcloud iam user create --login "etcd-encryption" --group ADMIN --description "A user created for ETCD encryption" --password "xxxxxxxxx" --email "xxxxx@mycompany.com"

Criação do certificado de acesso

Crie um certificado de acesso OKMS e associe o utilizador criado anteriormente.

Guarde o certificado cert.pem e a chave privada key.pem gerados, pois serão necessários para a configuração do fornecedor de encriptação.

Criação da chave KMIP AES

Para criar uma chave KMIP AES, pode utilizar a CLI OKMS:

Comece por descarregar o binário da versão mais recente ou compile-o a partir das fontes.

Em seguida, pode criar uma chave utilizando:

okms-cli kmip create symmetric --alg aes --size 256

Guarde o ID da chave gerada. Para o resto do guia, iremos utilizar o ID 70001308-5674-43fe-93dd-6270ecac0710 como exemplo.

Para mais informações sobre a utilização do okms-cli, consulte o repositório GitHub.

Configuração do fornecedor de encriptação

O fornecedor de encriptação pode ser executado diretamente nos hosts kube-apiserver com o seguinte comando:

./okms-k8s-encryption-provider \
  --client-cert "~/.ovh-kms/cert.pem" \
  --client-key "~/.ovh-kms/key.pem" \
  --kmip-addr "eu-west-par.okms.ovh.net:5696" \
  --kmip-key-id "70001308-5674-43fe-93dd-6270ecac0710"

O fornecedor de encriptação suporta as seguintes opções:

OpçãoDescriçãoPor defeito
--client-certCaminho para o ficheiro do certificado de cliente para a autenticação no OVHcloud KMS."" (obrigatório)
--client-keyCaminho para o ficheiro da chave privada associada ao certificado de cliente."" (obrigatório)
--kmip-addrEndereço do servidor KMIP. Disponível no . (por exemplo: eu-west-rbx.okms.ovh.net:5696)."" (obrigatório)
--kmip-key-idIdentificador da chave de encriptação a utilizar no servidor KMIP."" (obrigatório)
--sockCaminho para o socket Unix no qual o fornecedor irá escutar. Deve ser montado dentro do apiserver do Kubernetes./var/run/okms_etcd_plugin.sock
--timeoutTempo limite para as operações do servidor gRPC.10s
--debugAtivar os registos de depuração.false

Configuração do Kubernetes

Com base no guia oficial do Kubernetes para encriptar dados com um fornecedor KMS, adicione as seguintes opções ao seu kube-apiserver:

  --encryption-provider-config=<path/to>/encryption-config.yaml
  # Opcional: recarregar o ficheiro se for atualizado
  --encryption-provider-config-automatic-reload=true

Certifique-se de que monta no kube-apiserver o diretório que contém o socket Unix no qual o servidor KMS está a escutar.

Um exemplo de encryption-config.yaml:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
    - secrets
    providers:
    - kms:
        name: okms-encryption-provider
        endpoint: unix:///var/run/okms_etcd_plugin.sock
        cachesize: 1000
        timeout: 3s
    - identity: {}

Validação da configuração

Crie um secret com kubectl create secret generic okms-test-secret -n default --from-literal=mykey=mydata e, em seguida, verifique o conteúdo do secret no armazenamento ETCD executando o seguinte comando:

ETCDCTL_API=3 etcdctl \
    --key /rootfs/etc/kubernetes/pki/kube-apiserver/etcd-client.key \
    --cert  /rootfs/etc/kubernetes/pki/kube-apiserver/etcd-client.crt \
    --cacert /rootfs/etc/kubernetes/pki/kube-apiserver/etcd-ca.crt  \
    --endpoints "https://etcd-a.internal.${CLUSTER}:4001" get /registry/secrets/default/okms-test-secret

O resultado deverá ser ilegível:

0m`�He.0�cryption-provider:�1x��%�B���#JP��J���*ȝ���΂@\n�96�^��ۦ�~0| *�H��
                    `q�*�J�.P��;&~��o#�O�8m��->8L��0�C3���A7�����~���f�V�ܬ���X��_��`�H#�D��z)+�81��qW��y��`�q��}1<LF, ��N��p����i*�aC#E�߸�s������s��l�?�a
�AźR������.��8H�4�O

Implementação da rotação de chaves

Para rodar a sua chave, terá de executar dois fornecedores de encriptação, cada um a escutar num socket Unix diferente.

Segue-se um exemplo de ficheiro de configuração de encriptação para todos os servidores API antes de utilizar a nova chave:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
    - secrets
    providers:
    # fornecedor que utiliza a chave antiga
    - kms:
        name: okms-encryption-provider
        endpoint: unix:///var/run/kmsplugin/socket.sock
        cachesize: 1000
        timeout: 3s
    # fornecedor que utiliza a chave nova
    - kms:
        name: okms-encryption-provider-2
        endpoint: unix:///var/run/kmsplugin/socket2.sock
        cachesize: 1000
        timeout: 3s
    - identity: {}

Assim que todos os servidores API tiverem sido reiniciados e forem capazes de desencriptar com a nova chave, coloque o fornecedor com a nova chave no topo.

Assim que todos os secrets tiverem sido novamente encriptados com a nova chave, pode eliminar o antigo fornecedor de encriptação.

Quer saber mais?

Fale com a nossa comunidade de utilizadores.

Descubra como utilizar o Kubernetes External Secrets Operator com o Secret Manager.

Esta página foi útil?