SOPS 3.13 en pymes: secretos, age y auditoría
Guía técnica para guardar secretos cifrados en Git con SOPS y age: roles, archivos, rotación, backup y prueba de salida.
Un archivo cifrado en Git guarda valores sensibles sin mostrar la clave que los abre. En soporte, infraestructura y desarrollo, esa diferencia corta el reenvio de contrasenas por chat y deja rastro de quien cambio cada variable. SOPS 3.13.1, publicado el 16 de mayo, puede cifrar YAML, JSON y env con age. Esta guía explica donde vive el secreto, quién lo lee y cómo se recupera.
Dónde aparece la clave copiada fuera del repositorio
El problema operativo empieza cuando una variable de base, API o SMTP queda pegada en un ticket. La cifra que corrige el hábito esta en el release: SOPS 3.13.1 tiene binarios para varios sistemas y fecha fija de publicación, lo qué permite bloquear versión antes de usarlo en despliegues.
Una clave sin dueño dura mas que el proveedor que la escribio.
La escala global ordena la comparación. GitHub Octoverse 2025 informo más de 180 millones de desarrolladores y 630 millones de repositorios. Una municipalidad chica del Gran Mendoza no opera ese volumen, pero sus variables de correo, base y almacenamiento también necesitan versión, permiso y salida.
Qué guarda SOPS y qué guarda age
El antagonista es el archivo .env reenviado por mensajeria y renombrado con la palabra final. En un área de sistemas municipal, una zapatilla electrica con etiquetas viejas debajo del rack dice bastante: las conexiones siguen andando, pero cuesta saber quién puede cambiarlas.
La documentación de SOPS describe cifrado selectivo de valores dentro de archivos estructurados. El repositorio de SOPS muestra soporte para age, PGP y servicios de claves. age 1.3.1 aporta pares de claves simples para cifrar y descifrar. Git conserva historial, y git log permite revisar autor, fecha y cambio aprobado.
El archivo cifrado también ordena proveedores. Si una empresa externa necesita tocar un servicio, recibe permiso sobre una carpeta y una clave acotada. Cuando termina el contrato, sistemas retira ese destinatario, vuelve a cifrar y deja un commit con fecha. La prueba queda en el repositorio y en la bitacora de despliegue, no en una promesa escrita tarde.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, sistemas crea claves age por rol o persona autorizada. Segundo, el repositorio define reglas .sops.yaml para cada carpeta. Tercero, el operador edita un archivo de variables con sops. Cuarto, SOPS cifra valores sensibles y deja visibles nombres de campos. Quinto, Git guarda commit, autor, fecha y revisión. Sexto, el despliegue descifra solo en el entorno autorizado. Septimo, el backup copia repositorio, claves publicas, bitacora y procedimiento de recuperacion.
SOPS recibe un archivo estructurado y entrega el mismo archivo con valores cifrados. age recibe destinatarios y entrega material cifrado para quienes tienen clave privada. Git recibe cambios y entrega historial. PostgreSQL puede guardar auditoría de despliegues, entornos, aprobadores y estados. Si falla SOPS, el archivo no se abre. Si falla Git, se pierde historial. Si se pierde la clave privada, hace falta rotación y recuperacion documentada.
Qué se instala o configura primero
La pila inicial usa SOPS 3.13.1, age 1.3.1, Git, repositorio privado, regla .sops.yaml, grupos de lectura, pipeline de despliegue, PostgreSQL 18 para auditoría y backup probado. El piloto cuesta entre USD 700 y USD 2.100, entre ARS 1,00 y ARS 3,00 millones al dólar vendedor oficial de $1.429 informado por Bluelytics. Incluye tres servicios, cinco secretos, rotación y recuperacion.
El plazo va de una a tres semanas. UMSA suele pedir un entregable verificable: secreto cifrado, usuario autorizado que descifra, usuario lector que ve solo ciphertext, commit revisado, despliegue exitoso, clave revocada y restauración en otro equipo. El costo no incluye cambio de plataforma, gestión de incidentes historicos ni limpieza de secretos ya filtrados.
La primera prueba toma una credencial SMTP. Sistemas la cifra, soporte revisa el commit sin ver el valor, el despliegue la lee y una cuenta sin permiso intenta descifrar. El resultado esperado es rechazo. La segunda prueba rota una clave age. El secreto debe quedar accesible para el nuevo destinatario y cerrado para el anterior.
La tercera prueba mira auditoría. El responsable pide historial del secreto, cambio de destinatarios y último despliegue que lo uso. Git entrega commits, PostgreSQL entrega eventos y el pipeline entrega estado. Si esas tres vistas no coinciden, la organización detecta el corte antes de exponer credenciales.
Dónde se rompe y cómo probarlo
Primer riesgo: clave privada guardada en la misma carpeta que los secretos. La señal aparece cuando backup y secreto viajan juntos. La prueba restaura repositorio sin claves privadas y confirma que los valores siguen cerrados. Segundo riesgo: commits con secretos previos en texto plano. La señal surge al buscar patrones de token. La prueba recorre historial y obliga rotación.
Tercer riesgo: pipeline que imprime variables en logs. La señal aparece cuando una ejecución muestra valores completos. La prueba corre despliegue con salida capturada y busca cadenas sensibles. Cuarto riesgo: backup que copia repositorio y olvida procedimiento. La señal es una restauración que depende de una persona. La prueba recupera un servicio en otro host usando documento firmado y fecha.