Mejores Prácticas para Gestionar Secretos y Datos Sensibles en Clústeres de Kubernetes

Los Secretos de Kubernetes son convenientes, pero no son automáticamente seguros solo porque el objeto se llame Secret. Si tu RBAC es demasiado amplio o etcd no está cifrado, un token filtrado puede exponer contraseñas de bases de datos, claves de API y certificados privados en todo tu clúster.

Usa los Secretos de Kubernetes como una capa, luego agrega cifrado, control de acceso, patrones de inyección más seguros y almacenes externos de secretos donde el riesgo lo justifique.

Entendiendo los Secretos de Kubernetes: El Mecanismo Predeterminado

Kubernetes introduce el objeto Secret diseñado específicamente para contener información sensible. Aunque es útil, es crucial entender sus limitaciones y comportamiento predeterminado en cuanto a seguridad.

Comportamiento Predeterminado y Advertencias

Por defecto, los Secretos de Kubernetes no están cifrados en reposo dentro de etcd, el almacén de respaldo del clúster para todos los datos de configuración. Simplemente están codificados en Base64, lo que ofrece ningún cifrado real. Cualquier persona con acceso al almacén de datos de etcd (por ejemplo, administradores del clúster, nodos comprometidos) puede decodificar fácilmente estos valores.

Advertencia: Nunca confíes únicamente en el objeto Secret predeterminado de Kubernetes para datos altamente sensibles sin aplicar medidas de cifrado.

Codificación Base64 vs. Cifrado

Es un error común pensar que la codificación Base64 proporciona seguridad. Base64 es un esquema de codificación, no un esquema de cifrado. Es fácilmente reversible:

# Ejemplo de decodificación de un valor de Secret de Kubernetes
echo 'c3VwZXItc2VjcmV0Cg==' | base64 -d
# Salida: super-secret

Capa 1: Asegurando Secretos en Reposo (Cifrado de etcd)

El paso más fundamental para asegurar los Secretos es garantizar que estén cifrados en la capa de almacenamiento (etcd). Esto protege los datos incluso si se accede directamente a la base de datos subyacente.

Habilitando el Cifrado en Reposo

El cifrado en reposo se configura a través del servidor API de Kubernetes usando un objeto EncryptionConfiguration. Esta configuración especifica qué proveedores deben usarse para cifrar varios tipos de datos almacenados en etcd, incluyendo secrets.

Componentes Clave de la Configuración de Cifrado:

1. kind: EncryptionConfiguration: Declara el tipo de recurso.
2. resources: Especifica qué recursos de la API deben cifrarse.
3. providers: Define el mecanismo de cifrado. Los proveedores comunes incluyen aescbc, aesgcm y proveedores KMS (como AWS KMS o GCP KMS).

Mejor Práctica: Usa un proveedor KMS cuando tu plataforma lo soporte. Si usas claves locales, gestiona la rotación de claves cuidadosamente y mantén las claves antiguas disponibles hasta que los datos existentes hayan sido recifrados.

Capa 2: Asegurando Secretos en Tránsito y en Uso

Mientras que el cifrado de etcd resuelve el problema 'en reposo', los Secretos aún son descifrados por el Kubelet cuando se montan en un Pod. Debemos controlar cómo y dónde aparecen estos secretos.

Estrategia 1: Montaje de Secretos como Volumen

La forma estándar de inyectar datos de Secret en un contenedor es montándolos como un volumen (a menudo resultando en un archivo en el sistema de archivos del contenedor).

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  containers:
  - name: my-container
    image: nginx
    volumeMounts:
    - name: secret-volume
      mountPath: "/etc/config/db"
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: my-sensitive-secret

Consideración de Seguridad: Los volúmenes de Secret montados suelen estar respaldados por tmpfs en nodos Linux, pero los valores siguen siendo visibles para el proceso del contenedor y para cualquiera con suficiente acceso al nodo o Pod. Usa readOnly: true, evita volcar variables de entorno o archivos de configuración en registros, y restringe el acceso al shell en Pods de producción.

Estrategia 2: Variables de Entorno (Desaconsejado para Alta Sensibilidad)

Aunque conveniente, usar variables de entorno obtenidas de Secretos generalmente se desaconseja para secretos de alto valor. Las variables de entorno pueden filtrarse fácilmente a través de:

• Registros de contenedores generados por aplicaciones mal configuradas.
• Lectura de /proc/1/environ desde dentro del contenedor u otros contenedores privilegiados.
• Herramientas de inspección de contenedores.

Usa variables de entorno solo para datos de configuración de baja sensibilidad si es necesario.

Capa 3: Gestión Avanzada con Almacenes Externos de Secretos

El patrón más seguro implica mantener los datos sensibles completamente fuera del plano de control de Kubernetes (etcd) y recuperarlos dinámicamente en tiempo de ejecución usando herramientas especializadas.

Usando Operadores de Secretos Externos

Los Operadores de Secretos Externos cierran la brecha entre un secreto almacenado de forma segura en un vault dedicado (como HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) y el objeto Secret nativo de Kubernetes.

1. Almacenamiento: El secreto real vive solo en el vault externo.
2. Sincronización/Inyección: Un operador observa un recurso personalizado (como ExternalSecret) y obtiene los datos del vault.
3. Creación: El operador luego crea un objeto Secret estándar de Kubernetes localmente, que puede montarse en los Pods.

Beneficio: La fuente de verdad permanece fuera del clúster, lo que mejora la rotación y la auditabilidad. Sin embargo, el Secret sincronizado de Kubernetes aún existe en el clúster, por lo que aún necesitas RBAC, cifrado de etcd y aislamiento de namespaces.

Usando el Controlador CSI de Almacén de Secretos

Para aplicaciones que necesitan acceso directo y efímero sin almacenar el secreto localmente en etcd en absoluto, el Controlador CSI de Almacén de Secretos es la opción superior.

• El controlador aprovecha un proveedor (por ejemplo, proveedor de Vault, proveedor de Azure).
• Monta el secreto directamente desde el almacén externo en el sistema de archivos del Pod como un volumen temporal, evitando la necesidad de escribir los datos del secreto en etcd.

Esto ofrece el más alto nivel de seguridad al eliminar el secreto de la base de datos etcd por completo.

Mejores Prácticas Operativas para la Gestión de Secretos

Más allá de los mecanismos técnicos de almacenamiento, la higiene operativa es crucial para mantener una postura segura.

1. Principio de Mínimo Privilegio (PoLP)

Asegúrate de que la Cuenta de Servicio asociada con un Pod solo tenga permisos para leer el Secreto específico que necesita, y ningún otro. Usa Control de Acceso Basado en Roles (RBAC) para delimitar estrictamente los permisos.

2. Rotar Secretos Frecuentemente

Implementa horarios de rotación automatizados para todas las credenciales. Los secretos de larga duración aumentan la ventana de oportunidad para un compromiso. Las herramientas integradas con vaults externos a menudo manejan esta rotación automáticamente.

3. Auditar y Monitorear el Acceso

Configura el registro de auditoría para rastrear quién lee o modifica objetos Secret. Las herramientas que se integran con vaults externos (como Agentes de Vault o controladores CSI) también deben registrar los intentos de acceso al almacén externo.

4. Nunca Comprometer Secretos en Git

Esta es una regla fundamental. Nunca almacenes secretos en texto plano o incluso codificados en Base64 en repositorios de Git, incluso en privados. Usa herramientas como git-secrets o herramientas de plantillas de gestión de configuración (como Helm o Kustomize) combinadas con mecanismos externos de inyección de secretos para gestionar los manifiestos de despliegue.

Ejemplo usando Kustomize (Referencia Externa):

Al usar plantillas, podrías usar marcadores de posición en tus archivos de manifiesto y depender de un paso de compilación o un pipeline de CI/CD para inyectar los valores reales de los secretos recuperados de forma segura desde un vault antes de aplicar el YAML al clúster.

Comparación de Estrategias de Gestión

Estrategia	Nivel de Seguridad	Exposición de etcd?	Complejidad	Mejor Para
Secret K8s Predeterminado (Sin cifrado de etcd)	Muy Bajo	Sí (Texto Plano)	Baja	Solo pruebas temporales
Secret K8s con Cifrado de etcd	Medio	Sí (Cifrado)	Media	Datos de configuración general
Operador de Secretos Externos	Alto	Sí (Secret gestionado por operador)	Alta	Estandarizar la gestión de secretos
Controlador CSI de Almacén de Secretos	Más Alto	No (Montaje Directo)	Alta	Credenciales y tokens altamente sensibles

Comienza habilitando el cifrado de etcd y ajustando RBAC. Luego decide si cada carga de trabajo puede usar Secretos sincronizados, montajes CSI directos o credenciales dinámicas de un vault externo. La mejor configuración es la que limita quién puede leer el secreto, dónde se almacena y cuánto tiempo sigue siendo útil después de la exposición.