Gestión de Secrets en Kubernetes 2026: External Secrets, Vault y Preguntas de Entrevista

La gestión de secrets en Kubernetes sigue siendo uno de los desafíos de seguridad más críticos en la orquestación de contenedores. Los Secrets nativos de Kubernetes almacenan datos sensibles como valores codificados en base64, lo que no proporciona cifrado en reposo por defecto y crea riesgos de seguridad frecuentemente explorados durante los procesos de contratación DevOps.

Por Qué los Secrets Nativos de Kubernetes Son Insuficientes

El recurso Secret incorporado almacena datos en etcd con codificación base64. Esta codificación es reversible con un simple comando:

# decoding-secret.sh
# Decodificar cualquier valor de secret de Kubernetes instantáneamente
kubectl get secret db-credentials -o jsonpath='{.data.password}' | base64 -d

Base64 no es cifrado. Cualquier persona con acceso al cluster puede leer los valores de los secrets. La documentación de Kubernetes advierte explícitamente que los Secrets "no están cifrados por defecto" y recomienda habilitar el cifrado en reposo.

Tres limitaciones principales afectan los despliegues en producción:

1. Sin rastro de auditoría: Los Secrets nativos no registran quién accedió a qué valor y cuándo
2. Sin mecanismo de rotación: Cambiar un secret requiere intervención manual y reinicio de pods
3. Incompatibilidad con GitOps: Almacenar secrets cifrados en Git aún expone el problema de gestión de claves de cifrado

Arquitectura de External Secrets Operator

External Secrets Operator (ESO) conecta Kubernetes con sistemas externos de gestión de secrets. Lanzado como proyecto CNCF Sandbox en 2023 y alcanzando la versión 0.10 en 2026, ESO soporta AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, Azure Key Vault y 15 backends adicionales.

La arquitectura involucra tres recursos personalizados:

# secret-store.yaml
# ClusterSecretStore define la conexión a Vault
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: vault-backend
spec:
  provider:
    vault:
      server: "https://vault.internal:8200"
      path: "secret"
      version: "v2"
      auth:
        kubernetes:
          mountPath: "kubernetes"
          role: "external-secrets"
          serviceAccountRef:
            name: "external-secrets"
            namespace: "external-secrets"

Este ClusterSecretStore configura ESO para autenticarse con Vault usando tokens de cuenta de servicio de Kubernetes. El método de autenticación kubernetes valida el JWT de la cuenta de servicio contra la API TokenReview del cluster.

# external-secret.yaml
# ExternalSecret obtiene y sincroniza los datos reales del secret
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: db-secret
    creationPolicy: Owner
  data:
    - secretKey: username
      remoteRef:
        key: secret/data/production/database
        property: username
    - secretKey: password
      remoteRef:
        key: secret/data/production/database
        property: password

ESO consulta Vault cada hora (refreshInterval: 1h) y actualiza el Secret de Kubernetes automáticamente. La política creationPolicy: Owner asegura que el Secret se elimine cuando el ExternalSecret sea removido.

Patrones de Integración con HashiCorp Vault

Vault proporciona secrets dinámicos, rotación automática y registro de auditoría completo. El método de autenticación de Kubernetes, documentado en la documentación de Vault Kubernetes Auth, permite que los pods se autentiquen sin distribuir credenciales de larga duración.

Configurar la autenticación de Vault requiere tres pasos:

# vault-k8s-auth.sh
# Habilitar el método de autenticación Kubernetes en Vault
vault auth enable kubernetes

# Configurar Vault para validar tokens contra la API de Kubernetes
vault write auth/kubernetes/config \
  kubernetes_host="https://kubernetes.default.svc:443" \
  kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

# Crear un rol que vincule cuentas de servicio a políticas
vault write auth/kubernetes/role/external-secrets \
  bound_service_account_names=external-secrets \
  bound_service_account_namespaces=external-secrets \
  policies=readonly-secrets \
  ttl=1h

Esta configuración vincula la cuenta de servicio external-secrets a una política de Vault. El TTL limita la validez del token, forzando la re-autenticación y reduciendo el radio de impacto de tokens comprometidos.

Para despliegues en producción, la política debe seguir los principios de mínimo privilegio:

# readonly-secrets.hcl
# Política de Vault otorgando acceso de solo lectura a rutas específicas
path "secret/data/production/*" {
  capabilities = ["read"]
}

path "secret/metadata/production/*" {
  capabilities = ["list"]
}

Esta política otorga acceso de lectura únicamente a la ruta de secrets de producción. Los equipos que gestionan diferentes ambientes reciben políticas separadas con restricciones de ruta correspondientes.

Rotación de Secrets Sin Tiempo de Inactividad

La rotación automática previene que los secrets se conviertan en vectores de ataque obsoletos. ESO maneja el lado de Kubernetes, pero la aplicación debe recargar los secrets sin reiniciarse.

Existen dos enfoques para la rotación sin interrupción:

Secrets montados en volumen con monitoreo de archivos:

# deployment-volume-secrets.yaml
# Montar secrets como archivos que se actualizan automáticamente
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  template:
    spec:
      containers:
        - name: api
          image: api:v2.1.0
          volumeMounts:
            - name: secrets
              mountPath: /etc/secrets
              readOnly: true
      volumes:
        - name: secrets
          secret:
            secretName: db-secret

Kubernetes actualiza los archivos de secrets montados dentro del período de sincronización del kubelet (1 minuto por defecto). La aplicación lee las credenciales desde /etc/secrets/password en cada conexión a la base de datos, obteniendo los nuevos valores sin reinicio.

Reloader para secrets en variables de entorno:

Las aplicaciones que usan variables de entorno requieren reinicios de pods. Stakater Reloader automatiza este proceso:

# deployment-with-reloader.yaml
# La anotación activa un reinicio gradual cuando el secret cambia
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  annotations:
    reloader.stakater.com/auto: "true"
spec:
  template:
    spec:
      containers:
        - name: api
          envFrom:
            - secretRef:
                name: db-secret

Reloader monitorea las actualizaciones de Secrets y realiza reinicios graduales, manteniendo la disponibilidad durante toda la rotación.

Preguntas de Entrevista sobre Secrets en Kubernetes

Las entrevistas DevOps prueban consistentemente la comprensión de la gestión de secrets. Estas preguntas aparecen desde niveles junior hasta senior:

P: ¿Qué codificación usan los Secrets de Kubernetes, y por qué es insuficiente para la seguridad?

Los Secrets usan codificación base64, que es una transformación reversible, no cifrado. Cualquier usuario con permisos get sobre Secrets puede decodificar los valores. La seguridad requiere cifrado en reposo (habilitando cifrado de etcd) y restringiendo permisos RBAC.

P: ¿Cómo se evita que los secrets aparezcan en repositorios Git al usar GitOps?

External Secrets Operator almacena solo referencias a secrets en Git, no los valores en sí. El manifiesto ExternalSecret contiene la ruta al secret en Vault o AWS Secrets Manager, mientras que el secret real nunca toca el repositorio. Sealed Secrets de Bitnami ofrece un enfoque alternativo usando cifrado asimétrico.

P: Explique la diferencia entre SecretStore y ClusterSecretStore.

SecretStore tiene alcance de namespace: los ExternalSecrets en el mismo namespace pueden referenciarlo. ClusterSecretStore tiene alcance de cluster: cualquier namespace puede referenciarlo. Se usa ClusterSecretStore cuando múltiples equipos comparten una única instancia de Vault, y SecretStore cuando cada namespace tiene backends de secrets aislados.

P: ¿Cómo funciona la autenticación de Kubernetes en Vault?

Cuando un pod se autentica con Vault, envía su token JWT de cuenta de servicio. Vault valida este token contactando la API TokenReview de Kubernetes. Si el token es válido y la cuenta de servicio coincide con un rol configurado, Vault emite un token de Vault con las políticas asociadas.

P: ¿Cuál es la estrategia recomendada para la rotación de secrets en un ambiente de producción?

Configurar refreshInterval en ExternalSecret por debajo del TTL de las credenciales. Para aplicaciones que usan variables de entorno, desplegar Reloader para automatizar los reinicios graduales. Para secrets montados en volumen, asegurarse de que la aplicación relea los archivos en lugar de cachear los valores al inicio.

Integración Multi-Cloud con AWS y GCP

Las organizaciones que usan múltiples proveedores de nube requieren configuraciones de ESO específicas para cada proveedor. AWS utiliza IRSA (IAM Roles for Service Accounts):

# aws-secret-store.yaml
# ClusterSecretStore para AWS Secrets Manager con IRSA
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: aws-secrets
spec:
  provider:
    aws:
      service: SecretsManager
      region: eu-west-1
      auth:
        jwt:
          serviceAccountRef:
            name: external-secrets-sa
            namespace: external-secrets

La cuenta de servicio se anota para vincular el rol IAM:

# service-account-irsa.yaml
# Cuenta de servicio con anotación de rol IAM
apiVersion: v1
kind: ServiceAccount
metadata:
  name: external-secrets-sa
  namespace: external-secrets
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/external-secrets

AWS realiza automáticamente la rotación de secrets creados mediante Secrets Manager con una función Lambda. Combinado con el intervalo de actualización de ESO, los secrets se propagan a Kubernetes dentro del período de polling configurado.

Sincronización de Secrets Multi-Cluster

Las organizaciones que ejecutan múltiples clusters necesitan distribución de secrets consistente. Dos patrones abordan este requisito:

Hub-and-spoke con ClusterSecretStore:

Todos los clusters se conectan a una instancia central de Vault. La instalación de ESO de cada cluster referencia los mismos secrets, y Vault maneja el control de acceso a través de políticas basadas en namespaces.

Replicación con Vault Enterprise:

Vault Enterprise soporta replicación de rendimiento entre regiones. Cada cluster se conecta a su réplica local de Vault, reduciendo la latencia mientras mantiene la consistencia. La documentación de replicación de Vault cubre los modos de recuperación ante desastres y replicación de rendimiento.

Endurecimiento de RBAC para Acceso a Secrets

Los roles de cluster por defecto otorgan acceso excesivo a secrets. Endurecer RBAC creando roles mínimos:

# restricted-role.yaml
# Rol que permite acceso a secrets solo en un namespace específico
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-reader
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get"]
    resourceNames: ["db-secret", "api-key"]

El campo resourceNames restringe el acceso a los secrets explícitamente listados. Sin este campo, el rol otorga acceso a todos los secrets en el namespace.

El registro de auditoría captura los intentos de acceso a secrets:

# audit-policy.yaml
# Política de auditoría de Kubernetes para operaciones de secrets
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]
    verbs: ["get", "list", "watch"]

Esta política registra la solicitud y respuesta completas para operaciones de secrets, permitiendo a los equipos de seguridad detectar patrones de acceso no autorizados.

Lista de Verificación de Producción para Secrets en Kubernetes

• Habilitar cifrado de etcd en reposo usando el recurso API EncryptionConfiguration
• Desplegar External Secrets Operator v0.10+ con ClusterSecretStore apuntando a Vault o proveedor de nube
• Configurar refreshInterval por debajo del TTL de credenciales para asegurar que los secrets se actualicen antes de expirar
• Usar IRSA (AWS), Workload Identity (GCP) o autenticación Kubernetes (Vault) en lugar de credenciales estáticas
• Restringir RBAC con resourceNames para limitar el acceso a secrets a secrets nombrados específicos
• Habilitar registro de auditoría de Kubernetes para operaciones de secrets con nivel RequestResponse
• Desplegar Reloader para aplicaciones que usan variables de entorno para manejar actualizaciones de secrets
• Probar la rotación de secrets en staging antes del despliegue en producción
• Documentar procedimientos de recuperación para interrupciones del backend de secrets que afecten la programación de pods