Cómo cifrar ETCD de Kubernetes con OVHcloud KMS

Ver como Markdown

Descubra cómo configurar Kubernetes para cifrar el almacenamiento ETCD con la interfaz KMIP de OVHcloud KMS

Objetivo

Esta guía explica cómo configurar el proveedor de cifrado del kube-apiserver, que permite a los clústeres de Kubernetes cifrar y descifrar los datos en reposo utilizando OVHcloud KMS a través del protocolo KMIP.

Requisitos

Procedimiento

Instalación del binario

El binario puede instalarse directamente a partir de los paquetes de Go.

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

O bien puede compilarlo a partir de las fuentes.

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

Configuración de OVHcloud KMS (OKMS)

Para utilizar OVHcloud KMS como proveedor de cifrado para Kubernetes, necesitará los siguientes elementos:

  • Un usuario de OVHcloud y permisos para gestionar las claves KMIP de OKMS.
  • Un certificado de acceso para su dominio OKMS.
  • Una clave KMIP AES en su OKMS.

Creación del usuario y de los permisos de acceso

Cree un usuario local IAM con permisos de acceso sobre su dominio.

Si utiliza políticas IAM en su lugar, el usuario debe tener al menos los siguientes permisos sobre el dominio OKMS:

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

De lo contrario, el usuario debe pertenecer a un grupo que tenga el rol ADMIN.

Por otro lado, es posible crear un usuario utilizando la CLI OVHcloud:

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

Creación del certificado de acceso

Cree un certificado de acceso OKMS y vincule el usuario creado anteriormente.

Guarde el certificado cert.pem y la clave privada key.pem generados, ya que serán necesarios para la configuración del proveedor de cifrado.

Creación de la clave KMIP AES

Para crear una clave KMIP AES, puede utilizar la CLI OKMS:

Comience descargando el binario de la última versión o compilándolo a partir de las fuentes.

A continuación, puede crear una clave utilizando:

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

Conserve el ID de la clave generada. Para el resto de la guía, utilizaremos el ID 70001308-5674-43fe-93dd-6270ecac0710 como ejemplo.

Para más información sobre el uso de okms-cli, consulte el repositorio de GitHub.

Configuración del proveedor de cifrado

El proveedor de cifrado puede ejecutarse directamente en los hosts kube-apiserver con el siguiente 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"

El proveedor de cifrado admite las siguientes opciones:

OpciónDescripciónPor defecto
--client-certRuta al archivo del certificado de cliente para la autenticación en OVHcloud KMS."" (obligatorio)
--client-keyRuta al archivo de la clave privada asociada al certificado de cliente."" (obligatorio)
--kmip-addrDirección del servidor KMIP. Disponible en el . (por ejemplo: eu-west-rbx.okms.ovh.net:5696)."" (obligatorio)
--kmip-key-idIdentificador de la clave de cifrado que se utilizará en el servidor KMIP."" (obligatorio)
--sockRuta al socket Unix en el que escuchará el proveedor. Debe montarse dentro del apiserver de Kubernetes./var/run/okms_etcd_plugin.sock
--timeoutTiempo de espera para las operaciones del servidor gRPC.10s
--debugActivar las trazas de depuración.false

Configuración de Kubernetes

Basándose en la guía oficial de Kubernetes para cifrar los datos con un proveedor KMS, añada las siguientes opciones a su kube-apiserver:

  --encryption-provider-config=<path/to>/encryption-config.yaml
  # Opcional: recargar el archivo si se actualiza
  --encryption-provider-config-automatic-reload=true

Asegúrese de montar en el kube-apiserver el directorio que contiene el socket Unix en el que escucha el servidor KMS.

Un ejemplo 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: {}

Validación de la configuración

Cree un secret con kubectl create secret generic okms-test-secret -n default --from-literal=mykey=mydata y, a continuación, compruebe el contenido del secret en el almacenamiento ETCD ejecutando el siguiente 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

El resultado debería ser ilegible:

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

Implementación de la rotación de claves

Para rotar su clave, deberá ejecutar dos proveedores de cifrado, cada uno escuchando en un socket Unix diferente.

A continuación se muestra un ejemplo de archivo de configuración de cifrado para todos los servidores API antes de utilizar la nueva clave:

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

Una vez que todos los servidores API se hayan reiniciado y sean capaces de descifrar utilizando la nueva clave, coloque el proveedor con la nueva clave en primer lugar.

Una vez que todos los secrets se hayan vuelto a cifrar con la nueva clave, puede eliminar el antiguo proveedor de cifrado.

Más información

Interactúe con nuestra comunidad de usuarios.

Descubra cómo utilizar Kubernetes External Secrets Operator con Secret Manager.

¿Le ha resultado útil esta página?