¿Están cifrados por defecto los Secrets de Kubernetes?
Respuesta breve
No. La documentación de Kubernetes indica que los Secrets se almacenan, por defecto, sin cifrar en el almacén de datos del servidor de API (etcd), y que cualquiera con acceso a la API o a etcd puede leerlos. El base64 de un manifiesto es solo codificación. Los pasos recomendados: activar el cifrado en reposo, RBAC de mínimo privilegio para los Secrets, restringir qué contenedores acceden a ellos y considerar un almacén de secretos externo.
La palabra «Secret» y el bloque base64 opaco de un manifiesto dan una falsa sensación de seguridad. Esta pregunta comprueba que sabes qué hace realmente Kubernetes por defecto.
Qué dice la documentación
Los Secrets de Kubernetes se almacenan, por defecto, sin cifrar en el almacén de datos subyacente del servidor de API, etcd. Cualquiera con acceso a la API puede recuperar o modificar un Secret, y también cualquiera con acceso a etcd. Además, cualquiera autorizado a crear un Pod en un namespace puede usar ese acceso para leer cualquier Secret del namespace, incluso indirectamente mediante un Deployment.
Base64 no es cifrado
Los valores del campo data de un Secret están codificados en base64 para que los datos binarios quepan en YAML/JSON. Cualquiera puede revertirlo con un comando; no aporta confidencialidad.
Qué hacer
La documentación enumera como mínimo: activar el cifrado en reposo de los Secrets, configurar RBAC con mínimo privilegio sobre los Secrets, restringir el acceso a Secrets a contenedores concretos y considerar proveedores de almacenes de secretos externos (por ejemplo, mediante el Secrets Store CSI Driver).
Por qué fallan los distractores
- «Base64 cifra» confunde codificación con cifrado.
- «Clave por namespace» es inventado; no existe tal valor por defecto.
- «Los namespaces aíslan por completo» — ayudan a acotar el RBAC, pero el acceso lo deciden los permisos concedidos, incluida la creación de Pods.
Qué quieren los entrevistadores
«No por defecto: activar el cifrado en reposo, cerrar el RBAC (incluido quién puede crear Pods) y considerar un almacén externo.»
Posibles preguntas de seguimiento
- ¿Cómo se activa el cifrado en reposo de los Secrets y contra qué sigue sin proteger?
- ¿Por qué cualquiera autorizado a crear un Pod en un namespace puede, en la práctica, leer sus Secrets?
- ¿Cuándo usarías un almacén de secretos externo en lugar de los Secrets nativos?