Por qué los Secrets no deben estar en values.yaml

El archivo values.yaml de un chart es texto normal sin cifrar. Todo lo que escriba allí, incluidas las contraseñas, puede leerlo cualquiera que abra el archivo.

Los charts suelen vivir en Git. Un secreto confirmado una vez permanece en el historial incluso después de eliminarlo, por lo que una filtración es permanente. 🔒

Puede resultar tentador poner una contraseña real directamente en values.yaml para que todo funcione. Resístase, porque ese valor se propaga por todas partes.

Al instalar, Helm guarda los valores combinados en un secreto de release en el clúster. Su contraseña en texto plano también queda allí.

Cualquiera con acceso a la release puede ejecutar helm get values y leer exactamente lo que pasó, incluida la contraseña en texto plano.

Pasar secretos mediante --set en una canalización suele imprimirlos en los registros de compilación, donde quedan a la vista de todo el equipo.

La regla es sencilla: los secretos nunca deben permanecer en texto plano dentro de un chart, en Git ni en la línea de comandos. Manténgalos fuera.

El patrón seguro consiste en referenciar un secreto en lugar de incrustarlo. Las plantillas apuntan a un recurso Secret que el clúster ya contiene.

Cuando los valores secretos realmente deban vivir en Git, almacénelos cifrados, de modo que el archivo confirmado no sirva de nada sin la clave de descifrado.

Hay tres opciones: cifrar los valores con herramientas, obtener los secretos de un almacén externo o crear plantillas de objetos Secret a partir de datos inyectados.

Base64 en Kubernetes Secrets solo es codificación, no cifrado. No oculta nada, por lo que nunca trate un valor codificado como protegido.

Ha visto por qué los secretos en texto plano dentro de values.yaml se filtran a través de Git, los datos de la release y los registros de CI, y por qué debe referenciarlos o cifrarlos en su lugar. 🎉