El despliegue con GitOps

En GitOps la rama que sigue un entorno es, en la práctica, su botón de despliegue. La protección de la rama pide revisión, pero una configuración que deja a los administradores saltársela no impide el push directo: solo el historial dice si ocurrió. Un cambio anterior a una fecha de corte no entra en la cuenta; el historial es la evidencia, no la política.

Un proyecto del primer controlador es una frontera: dice desde qué repositorios se puede desplegar y hacia qué clústeres y espacios. Si el origen y el destino aceptan comodines, el proyecto no limita nada y cualquier aplicación que lo use puede apuntar a producción. Basta un proyecto así para anular los límites de los demás.

Verificar la firma al sincronizar es un control por fuente: cada una lo declara o no. Una fuente sin verificación en un clúster de pruebas es un riesgo menor; la misma configuración en una fuente que llega a producción permite que lo que no está firmado se aplique, aunque no sea la fuente de las aplicaciones. Hay que mirar dos cosas a la vez: si verifica y a qué clúster llega.

Un Secret de Kubernetes guarda sus valores en base64, que es una forma de escribirlos y no de protegerlos. En un repositorio de entorno todos deben ir cifrados antes de subirse (con una herramienta como SOPS) o ser solo una referencia a un gestor. Basta uno sin cifrar para que el valor esté al alcance de quien lea el repositorio, y de su historial.

Un archivo cifrado con SOPS lleva la lista de destinatarios que pueden descifrarlo. Si una persona se va y su clave sigue en la lista, conserva la capacidad de descifrar todo lo que ya tenga en su copia del repositorio, aunque se le retire el acceso. Para contar los archivos afectados hay que averiguar a qué identificador de cifrado corresponde la persona dada de baja.