# Gestión de Secrets en Kubernetes 2026: External Secrets, Vault y Preguntas de Entrevista > Guía completa sobre gestión de secrets en Kubernetes con External Secrets Operator y HashiCorp Vault. Patrones de rotación automática, integración multi-cloud y preguntas de entrevista DevOps. - Published: 2026-09-02 - Updated: 2026-09-02 - Author: Anthony Fillion-Maillet - Tags: kubernetes, secrets, vault, external-secrets, security, devops - Reading time: 12 min --- 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. > **Respuesta Rápida para Entrevista** > > Cuando se pregunta sobre la seguridad de secrets en Kubernetes: los Secrets nativos están codificados en base64, no cifrados. Los ambientes de producción requieren gestores de secrets externos como HashiCorp Vault o AWS Secrets Manager, sincronizados mediante External Secrets Operator (ESO). Esta separación garantiza que los secrets nunca existan en repositorios Git. ## 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: ```bash # 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](https://kubernetes.io/docs/concepts/configuration/secret/) 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: ```yaml # 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. ```yaml # 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](https://developer.hashicorp.com/vault/docs/auth/kubernetes), permite que los pods se autentiquen sin distribuir credenciales de larga duración. Configurar la autenticación de Vault requiere tres pasos: ```bash # 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: ```hcl # 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:** ```yaml # 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](https://github.com/stakater/Reloader) automatiza este proceso: ```yaml # 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): ```yaml # 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: ```yaml # 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](https://developer.hashicorp.com/vault/docs/enterprise/replication) 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: ```yaml # 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: ```yaml # 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 --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/es/blog/devops/kubernetes-secrets-management-2026-external-secrets-vault-interview