Secretos de Kubernetes Sin Cifrar en Reposo
Los Secrets de Kubernetes se almacenan como texto plano codificado en base64 en etcd por defecto, lo que significa que cualquiera con acceso al datastore etcd o sus respaldos puede leer todos los secretos del cluster.
Cómo Funciona
Cuando creas un Secret de Kubernetes, los datos se codifican en base64 (no se cifran) y se almacenan en etcd, el almacen clave-valor del cluster. Base64 es una codificacion, no un cifrado -- decodificarlo es trivial. Si un atacante obtiene acceso a etcd (via un endpoint mal configurado, un respaldo de etcd o un nodo comprometido), puede leer cada contrasena de base de datos, API key y certificado TLS en el cluster. Kubernetes soporta cifrado en reposo a traves de un EncryptionConfiguration que cifra los datos del Secret antes de escribirlos en etcd, pero esto debe configurarse explicitamente. La mayoria de clusters auto-administrados e incluso algunos clusters administrados no habilitan esto por defecto.
# BAD: Secret stored as base64 only -- not encrypted at rest
apiVersion: v1
kind: Secret
metadata:
name: db-credentials
type: Opaque
data:
username: YWRtaW4= # echo -n 'admin' | base64
password: UEBzc3cwcmQxMjM= # echo -n 'P@ssw0rd123' | base64
# Without EncryptionConfiguration, this is stored as-is in etcd
# Anyone with etcd access can decode: echo 'UEBzc3cwcmQxMjM=' | base64 -d# GOOD: enable encryption at rest for Secrets in etcd
# /etc/kubernetes/encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources: ["secrets"]
providers:
- aescbc:
keys:
- name: key1
secret: <base64-encoded-32-byte-key>
- identity: {} # fallback for reading unencrypted secrets
# Pass to kube-apiserver: --encryption-provider-config=/etc/kubernetes/encryption-config.yaml
# Then re-encrypt existing secrets: kubectl get secrets --all-namespaces -o json | kubectl replace -f -Ejemplo Real
En 2022, investigadores de seguridad de Palo Alto Networks (Unit 42) demostraron que el 75% de los clusters de Kubernetes escaneados tenian etcd accesible sin autenticacion adecuada, y ninguno de los clusters expuestos tenia cifrado en reposo habilitado. Los atacantes podian leer todos los Secrets incluyendo credenciales de proveedores cloud, contrasenas de bases de datos y tokens de cuentas de servicio directamente desde etcd.
Cómo Prevenirlo
- Habilita el cifrado en reposo usando EncryptionConfiguration con proveedores AES-CBC o AES-GCM en el API server de Kubernetes
- Usa un plugin de proveedor KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault) para que las claves de cifrado se gestionen externamente y se roten automaticamente
- Restringe el acceso a etcd solo al kube-apiserver -- nunca expongas endpoints de etcd a la red ni a otros pods
- Usa gestion externa de secretos (HashiCorp Vault, external-secrets-operator) en lugar de Kubernetes Secrets nativos cuando sea posible
Tecnologías Afectadas
Data Hogo detecta esta vulnerabilidad automáticamente.
Escanea Tu Repo GratisVulnerabilidades Relacionadas
Estado de Terraform Expuesto
criticalTu archivo terraform.tfstate está commiteado en tu repositorio o almacenado en un lugar sin cifrar y públicamente accesible — contiene cada secreto e ID de recurso en tu infraestructura.
Credenciales de Proveedor Terraform Hardcodeadas
criticalLas credenciales de AWS, GCP o Azure están hardcodeadas en tus archivos .tf en lugar de usar variables de entorno o roles de instancia, commiteando claves de acceso cloud al control de versiones.
Contenedor Kubernetes Privilegiado
highTu pod de Kubernetes corre con securityContext.privileged: true, dándole al contenedor acceso completo al kernel del host y efectivamente evitando el aislamiento del contenedor.
Cuenta de Servicio Predeterminada en Kubernetes
mediumLos pods que corren con la cuenta de servicio predeterminada heredan permisos RBAC a nivel de cluster que generalmente son mucho mas amplios de lo que el workload necesita, permitiendo movimiento lateral si el pod es comprometido.