Migración de secretos de Kubernetes a KMS v2

Descubra cómo volver a cifrar los objetos secretos de Kubernetes existentes mediante la versión 2 del proveedor de Key Management Service (KMS) en un cluster que haya creado con Kubernetes Engine (OKE).

El plano de control de cluster de Kubernetes almacena datos de configuración confidenciales (como tokens de autenticación, certificados y credenciales) como objetos secretos de Kubernetes en etcd. Al crear un cluster con Kubernetes Engine, puede especificar una clave de cifrado maestra en el servicio Oracle Cloud Infrastructure Vault para cifrar las claves de cifrado de datos que protegen los secretos estáticos de Kubernetes. Para obtener más información, consulte Cifrado de secretos estáticos de Kubernetes en etcd.

Kubernetes utiliza un proveedor de KMS para comunicarse entre el servidor de API de Kubernetes y el plugin de KMS de Kubernetes Engine. La versión del proveedor de KMS es independiente de la versión de la clave de cifrado maestra en Vault. La migración de la versión 1 del proveedor de KMS a la versión 2 del proveedor de KMS no requiere que cree una nueva clave de cifrado maestra ni que cambie la clave asociada al cluster. Para obtener más información sobre los proveedores de KMS de Kubernetes, consulte Uso de un proveedor de KMS para el cifrado de datos en la documentación de Kubernetes.

La versión del proveedor de KMS utilizada para cifrar objetos secretos de Kubernetes depende de la versión de Kubernetes que se ejecuta en el plano de control de cluster:

Los clusters que utilizan una clave de cifrado maestra que gestiona y ejecuta versiones de Kubernetes anteriores a la 1.36.1 utilizan la versión 1 del proveedor de KMS para cifrar objetos secretos de Kubernetes.
Los nuevos clusters creados con la versión 1.36.1 o posterior de Kubernetes y una clave de cifrado maestra que gestione utilizan la versión 2 del proveedor de KMS desde el momento en que se crea el cluster.
Al actualizar un cluster existente a la versión 1.36.1 o posterior de Kubernetes, Kubernetes Engine comienza a utilizar la versión 2 del proveedor de KMS. Los nuevos objetos secretos de Kubernetes utilizan la versión 2 del proveedor de KMS, al igual que los objetos secretos existentes que se actualizan posteriormente.

La actualización del plano de control de cluster no reescribe automáticamente todos los objetos secretos de Kubernetes existentes. Los objetos secretos que se cifraron con la versión 1 del proveedor de KMS antes de la actualización pueden permanecer cifrados con la versión 1 del proveedor de KMS hasta que Kubernetes los vuelva a escribir.

Kubernetes Engine conserva la versión 1 del proveedor de KMS como reserva de lectura, por lo que los objetos secretos existentes permanecen legibles después de la actualización del plano de control y durante la migración. No tiene que migrar los objetos secretos existentes inmediatamente para mantener las aplicaciones en ejecución.

Utilice el procedimiento de este tema para reescribir todos los objetos secretos de Kubernetes existentes en una sola operación. Cuando Kubernetes reescribe cada objeto secreto, el servidor de API de Kubernetes lo cifra mediante la versión 2 del proveedor de KMS. Una vez que la migración se realiza correctamente, los objetos secretos que se cifraron previamente con la versión 1 del proveedor de KMS se vuelven a cifrar con la versión 2 del proveedor de KMS.

Tenga en cuenta lo siguiente:

Normalmente, no es necesario realizar esta migración para un nuevo cluster creado con la versión 1.36.1 o posterior de Kubernetes, porque el cluster utiliza la versión 2 del proveedor de KMS desde el momento en que se crea el cluster.
No puede realizar la migración mientras el plano de control de cluster ejecuta una versión de Kubernetes anterior a la versión 1.36.1.
Kubernetes Engine no inicia automáticamente una migración masiva al actualizar el plano de control de cluster. Usted decide cuándo iniciar la migración.
Solo es necesaria una migración manual cuando desea volver a cifrar todos los objetos secretos de Kubernetes existentes sin cambios en una sola operación.

Nota

Este procedimiento solo se aplica a los clusters que utilizan una clave de cifrado maestra que gestiona para cifrar objetos secretos de Kubernetes estáticos en etcd. No se aplica a los clusters que solo utilizan el cifrado por defecto de los volúmenes de almacenamiento de bloques que contienen etcd.

Antes de empezar

Antes de migrar objetos secretos de Kubernetes a la versión 2 del proveedor de KMS:

Confirme que el cluster utiliza una clave de cifrado maestra en el servicio Oracle Cloud Infrastructure Vault que puede gestionar para cifrar secretos de Kubernetes estáticos. Consulte Cifrado de datos estáticos de Kubernetes en etc..
Actualice el plano de control del cluster a la versión 1.36.1 o posterior de Kubernetes. Consulte Actualización de la Versión de Kubernetes en Nodos de Plano de Control de un Cluster.
Configure kubectl para acceder al cluster. Consulte Configuración del acceso a los clusters.
Asegúrese de que la identidad de Kubernetes tenga permiso para crear, obtener, observar y suprimir el recurso storageversionmigrations.storagemigration.k8s.io de ámbito de cluster. Un administrador de cluster suele tener estos permisos.
Si utiliza una solución de copia de seguridad como Velero, realice una copia de seguridad actual que incluya todos los objetos secretos de Kubernetes y confirme que la copia de seguridad se ha realizado correctamente. Proteja la copia de seguridad según los requisitos de seguridad de su organización porque contiene datos confidenciales.
Planifique supervisar la migración hasta que se realice correctamente. La migración lee y reescribe cada objeto secreto de Kubernetes en el cluster y puede generar actividad de API de Kubernetes adicional. Los clusters más grandes pueden tardar más en migrar.

Confirmación de que el cluster está listo

No puede ver la configuración interna del proveedor de KMS del motor de Kubernetes. En su lugar, utilice la versión del plano de control de Kubernetes y la detección de API de Kubernetes para confirmar que el cluster está listo para la migración:

Compruebe las versiones de cliente y servidor de Kubernetes introduciendo:
```
kubectl version
```
Confirme que Server Version es v1.36.1 o posterior.

La versión del servidor es la versión de Kubernetes que se ejecuta en el plano de control de cluster. Las versiones de Kubernetes que se ejecutan en nodos de trabajador no determinan si la migración de la versión 2 del proveedor de KMS está disponible.

Compruebe que la API de migración de versión de almacenamiento esté disponible. Para ello, introduzca:

kubectl api-resources --api-group=storagemigration.k8s.io

Verifique que la salida incluya el recurso storageversionmigrations, de forma similar a la siguiente:


NAME                         SHORTNAMES   APIVERSION                         NAMESPACED   KIND
storageversionmigrations                  storagemigration.k8s.io/v1beta1    false        StorageVersionMigration

Confirme que su identidad de Kubernetes puede crear, supervisar y suprimir una migración introduciendo:

kubectl auth can-i create storageversionmigrations.storagemigration.k8s.io

kubectl auth can-i get storageversionmigrations.storagemigration.k8s.io

kubectl auth can-i watch storageversionmigrations.storagemigration.k8s.io

kubectl auth can-i delete storageversionmigrations.storagemigration.k8s.io

Cada comando debe devolver yes.

Si un comando devuelve no, solicite a un administrador de cluster que realice la migración u otorgue los permisos de RBAC de Kubernetes necesarios.

Puede iniciar la migración cuando se cumplan todas las siguientes condiciones:

El cluster utiliza una clave de cifrado maestra que puede gestionar para cifrar objetos secretos de Kubernetes.
El plano de control de cluster ejecuta Kubernetes versión 1.36.1 o posterior.
La API de migración de versión de almacenamiento está disponible.
Su identidad de Kubernetes tiene los permisos necesarios.

Si la API de migración de versión de almacenamiento no está disponible, no intente utilizar un procedimiento de reescritura en bloque diferente. Confirme que kubectl esté conectado al cluster deseado y que la actualización del plano de control haya finalizado. Si la API no está disponible, póngase en contacto con los Servicios de Soporte Oracle.

Migración de objetos secretos de Kubernetes existentes

Para obtener más información sobre el uso de la API de migración de versión de almacenamiento de Kubernetes para migrar objetos almacenados, consulte Migración de objetos de Kubernetes mediante la migración de versión de almacenamiento en la documentación de Kubernetes.

Para volver a cifrar todos los objetos secretos de Kubernetes existentes con la versión 2 del proveedor de KMS:

Cree un archivo denominado migrate-secrets-to-kms-v2.yaml con el siguiente contenido:
```
apiVersion: storagemigration.k8s.io/v1beta1
kind: StorageVersionMigration
metadata:
  name: migrate-secrets-to-kms-v2
spec:
  resource:
    group: ""
    resource: secrets
```
El valor group vacío identifica el grupo de API del núcleo central de Kubernetes. El valor resource: secrets limita la migración a objetos secretos de Kubernetes.

Un recurso StorageVersionMigration tiene un ámbito de cluster. Por lo tanto, la migración incluye objetos secretos de Kubernetes en todos los espacios de nombres.
Cree la migración:
```
kubectl create -f migrate-secrets-to-kms-v2.yaml
```
La creación del recurso indica al migrador de la versión de almacenamiento de Kubernetes que lea y reescriba los objetos secretos de Kubernetes. La operación no cambia intencionalmente los valores secretos. Cuando se escribe cada objeto, el servidor de API de Kubernetes lo cifra mediante la configuración activa de la versión 2 del proveedor de KMS.
Supervise la migración y espere a que se realice correctamente:
```
kubectl wait \
  --for=condition=Succeeded \
  storageversionmigration.storagemigration.k8s.io/migrate-secrets-to-kms-v2 \
  --timeout=24h
```
Un comando correcto devuelve una salida similar a la siguiente:
```
storageversionmigration.storagemigration.k8s.io/migrate-secrets-to-kms-v2 condition met
```
El timeout controla cuánto tiempo espera kubectl para la condición. Al alcanzar el timeout, no se cancela una migración que aún se está ejecutando.

Verificación de la Migración

Para confirmar que la migración se completó correctamente:

Obtener el estado de migración:

kubectl get \
  storageversionmigration.storagemigration.k8s.io/migrate-secrets-to-kms-v2 \
  -o yaml

En la lista status.conditions, confirme que la condición Succeeded tiene un valor de True, similar al siguiente:
```
status:
  conditions:
  - type: Succeeded
    status: "True"
    reason: StorageVersionMigrationSucceeded
```

El estado correcto confirma que Kubernetes ha reescrito los objetos secretos. Para un cluster que utiliza una clave de cifrado maestra que gestiona y ejecuta Kubernetes versión 1.36.1 o posterior, los objetos reescritos se cifran mediante la versión 2 del proveedor de KMS.

Después de confirmar que la migración se realizó correctamente, puede suprimir el recurso de migración completado:

kubectl delete \
  storageversionmigration.storagemigration.k8s.io/migrate-secrets-to-kms-v2

También puede suprimir el archivo migrate-secrets-to-kms-v2.yaml local.

La supresión del recurso StorageVersionMigration no deshace la migración y no suprime ningún objeto secreto de Kubernetes.

Resolución de problemas de migración de KMS v2

La API de migración de la versión de almacenamiento no se muestra

Si el comando kubectl api-resources no muestra el recurso storageversionmigrations, confirme que:

kubectl está utilizando el contexto para el cluster deseado.
El Server Version informado por kubectl version es v1.36.1 o posterior.
La actualización del plano de control se ha realizado correctamente.

Las versiones de Kubernetes que se ejecutan en nodos de trabajador no determinan si la API de migración está disponible.

Si se cumplen todas estas condiciones y la API no está disponible, póngase en contacto con los Servicios de Soporte Oracle. No intente utilizar un procedimiento de reescritura en bloque diferente.

No se puede crear la migración

Si el comando kubectl create devuelve un error Forbidden, confirme que la identidad de Kubernetes puede crear el recurso de migración:

kubectl auth can-i create storageversionmigrations.storagemigration.k8s.io

Si el comando devuelve no, solicite a un administrador de cluster que realice la migración o otorgue los permisos de RBAC de Kubernetes necesarios.

Si el comando kubectl create devuelve un error AlreadyExists, inspeccione la migración existente:

kubectl get \
  storageversionmigration.storagemigration.k8s.io/migrate-secrets-to-kms-v2 \
  -o yaml

Si la migración existente se ha realizado correctamente y desea ejecutar una nueva migración, suprima el recurso StorageVersionMigration completado antes de volver a crearlo.

La migración no se realiza correctamente

Inspeccione el estado de migración y los eventos asociados:

kubectl describe \
  storageversionmigration.storagemigration.k8s.io/migrate-secrets-to-kms-v2

Si la condición Failed es True o si la migración permanece incompleta, conserve la salida del comando y póngase en contacto con los Servicios de Soporte Oracle.

Los objetos secretos de Kubernetes que no se han reescrito siguen siendo legibles mediante la reserva de la versión 1 del proveedor de KMS. Los nuevos objetos secretos y los objetos secretos existentes actualizados mediante operaciones normales de Kubernetes siguen cifrados mediante la versión 2 del proveedor de KMS.

Documentación de Oracle Cloud Infrastructure