Entrevista de diseño de sistemas: ¿Cómo migrar Kubernetes a KMS v2 y demostrar que los Secrets están cifrados?

Planteamiento y alcance

El equipo de plataforma debe proteger los Secrets en etcd. El clúster cuenta con varios kube-apiservers, un plugin de KMS externo y muchos objetos históricos, pero los lanzamientos no pueden detenerse durante la migración. Diseñe la configuración, rotación, reescrituras, verificación, monitoreo y reversión (rollback).

Qué está evaluando el entrevistador

• Comprensión del límite de cifrado tipo sobre de KMS v2 y la relación entre DEK y KEK.
• Distinción entre nuevas escrituras cifradas y objetos históricos reescritos.
• Manejo de múltiples apiservers, caídas de KMS, rotación y actualizaciones concurrentes.
• Demostración del resultado con evidencia en etcd y lecturas de API en lugar de una simple diferencia de configuración (config diff).

Preguntas de clarificación

1. ¿Qué versiones de Kubernetes y del plugin, y qué topología de alta disponibilidad están desplegadas?
2. ¿Qué recursos están protegidos, incluidos recursos personalizados y registros de auditoría?
3. ¿Qué garantías de disponibilidad, latencia, rotación y recuperación ante desastres proporciona el KMS externo?
4. ¿Qué ventana para el plano de control, plazo de reversión y formato de evidencia de cumplimiento se requieren?

Una respuesta de 30 segundos

Valide el plugin KMS v2 y los permisos en un clúster que no sea de producción. Coloque KMS como el primer proveedor, mantenga el proveedor anterior como respaldo de lectura y reinicie progresivamente cada kube-apiserver uno a la vez. Las nuevas escrituras se cifrarán, pero los objetos históricos requieren actualizaciones no-op o migración de versión de almacenamiento (storage-version migration). Verifique lecturas de API, prefijos de etcd, métricas de KMS, simulacros de fallos y registros de auditoría. Elimine el proveedor antiguo solo después de que todos los objetos hayan sido reescritos y la ventana de reversión haya expirado.

Diseño paso a paso

1. Definir el modelo de cifrado

Kubernetes utiliza cifrado tipo sobre: una clave de cifrado de datos (DEK) protege un recurso, mientras que una clave de cifrado de claves (KEK) está protegida por el KMS externo. KMS v2 reduce la sobrecarga de solicitudes con almacenamiento en caché del lado del servidor y un diseño de DEK por apiserver, pero no reescribe automáticamente cada valor antiguo en etcd.

2. Validar primero el plugin y los permisos

En un clúster aislado, pruebe el socket, la identidad, los tiempos de espera, los reinicios y el comportamiento ante KMS no disponible. Confirme que el kube-apiserver pueda descifrar objetos escritos por el proveedor anterior y escribir un nuevo Secret a través del nuevo proveedor. Registre la latencia, los errores, los aciertos en caché y el volumen de llamadas a KMS.

providers:
  - kms:
      apiVersion: v2
      name: external-kms
      endpoint: unix:///var/run/kms/plugin.sock
  - aescbc:
      keys:
        - name: old-key
          secret: <base64-secret>

3. Realizar el despliegue progresivo en el plano de control de alta disponibilidad

Coloque KMS en primer lugar, conserve el proveedor antiguo para lecturas y reinicie los kube-apiservers uno a la vez. Después de cada cambio, verifique lecturas y escrituras de API, solicitudes concurrentes y salidas de auditoría. Nunca reinicie todo el plano de control al mismo tiempo. Gestione versiones de la configuración y del plugin para permitir reversiones.

4. Reescribir objetos históricos

Cambiar el orden de los proveedores afecta únicamente a las futuras escrituras. Ejecute actualizaciones no-op por lotes para Secrets y otros recursos protegidos, o utilice la migración de versión de almacenamiento para desencadenar reescrituras; reintente en caso de conflictos. Fragmente por namespace, limite la tasa de trabajo y registre las versiones de los objetos para no sobrecargar el servidor de API, etcd y KMS.

5. Recopilar evidencia de cifrado

Cree un nuevo Secret, lea sus bytes sin procesar desde etcd y verifique el prefijo de cifrado de KMS v2; luego léalo a través de la API y compare el texto plano. Muestree objetos antiguos y cada tipo de recurso protegido, contabilizando aquellos que aún no han sido reescritos. Una lectura exitosa de la API por sí sola no demuestra que el valor en disco esté cifrado.

6. Rotar, probar fallos y revertir

Tras la rotación de la KEK, mantenga la KEK antigua disponible para descifrado, reescriba en lotes y monitoree los fallos. Realice simulacros de tiempos de espera de KMS, pérdida de sockets, reversión de un solo apiserver y actualizaciones de plugins. Si las tasas de error superan un umbral, pause las reescrituras y restaure la configuración de lectura anterior. Elimine el proveedor antiguo solo después de que la nueva ruta y la cobertura histórica estén demostradas.

Respuesta modelo de alta calidad

Validaría el plugin KMS v2, los permisos, la latencia y el comportamiento ante fallos de forma aislada. En producción colocaría KMS v2 en primer lugar, conservaría brevemente el proveedor antiguo para lecturas y reiniciaría los kube-apiservers individualmente. Una vez que las nuevas escrituras estén cifradas, reescribiría los objetos en lotes delimitados por recurso y namespace, registrando el progreso, los conflictos y los reintentos. La evidencia incluiría lecturas de API, prefijos de etcd y muestras de objetos históricos. Solo después de completar la cobertura eliminaría el proveedor antiguo. La rotación y los fallos de KMS requieren simulacros, umbrales y una reversión delimitada.

Errores comunes

• Cambiar la configuración sin reescribir los objetos antiguos → el texto plano histórico permanece → realizar actualizaciones por lotes y contar las finalizaciones.
• Reiniciar todos los apiservers al mismo tiempo → caída del plano de control → desplegar uno a la vez y observar el estado de salud.
• Observar solo las lecturas de API → el cifrado en almacenamiento no queda demostrado → inspeccionar los bytes sin procesar de etcd.
• Eliminar el proveedor antiguo inmediatamente → los datos antiguos no se pueden descifrar → esperar a la migración y mantener una ventana de reversión.
• Ignorar la latencia de KMS y el almacenamiento en caché → las solicitudes pico de la API sobrecargan KMS → realizar pruebas de carga, limitar tasas y monitorear llamadas.

Preguntas de seguimiento y respuestas

¿Están seguros todos los nuevos Secrets después de configurar KMS v2?

Las nuevas escrituras utilizan el primer proveedor, pero los objetos antiguos no cambian automáticamente. Reescríbalos y verifíquelos con evidencia en etcd.

¿Pueden continuar las escrituras mientras KMS no está disponible?

Depende del almacenamiento en caché del plugin y de la configuración; nunca asuma disponibilidad. Defina el tiempo de espera, el rechazo de escrituras, las alertas y el comportamiento de reintento tras la recuperación, y luego póngalo a prueba mediante simulacros.

¿Por qué mantener el proveedor antiguo es un riesgo en lugar de una solución permanente?

Conserva la capacidad de descifrado durante la migración y la reversión, pero amplía el alcance de claves y configuración. Elimínelo después de demostrar la cobertura, conservando la evidencia de rotación y recuperación.