Mes: enero 2024

Manejo de información sensible con git-secret

Es habitual cuando hacemos aplicaciones tener que lidiar con información sensible como ser contraseñas y tokens de acceso. A esta información sensible se le suele llamar secretos. En la actualidad la práctica habitual es almacenar estos secrets en herramientas creadas específicamente para ello y que suelen llamarse Administradores de Secretos (Secret Managers) o Bóvedas.

Algunas nubes proveen soluciones propietarias para esta cuestión como es el caso de AWS Secret Manager y Azure Key Vault pero también existen soluciones open source como Vault que pueden instalarse on-prem. Usando estas herramientas uno puede guardar en ellas su información sensible (secretos) y luego conectar al administrador de secretos con los ambientes donde quiere usar dicha información.

Pero también existen un conjunto de herramientas que posibilitan guardar secretos en repositorios Git, una práctica no muy recomendada. Estas soluciones son extensiones y/o complementos de Git y lejos están de compararse funcionalmente con los administradores de secretos, pero para proyectos personales, chicos o no críticos, son una opción completamente válida. Básicamente estas soluciones toman los archivos con la información sensible y le aplican algún tipo de encriptación de forma tal que quedan almacenados en Git pero estando encriptados. Soluciones de este tipo son git-crypt y git-secret. Es precisamente esta última herramienta la que vengo usando. A continuación voy a compartir de forma resumida como funciona.

La herramienta funciona como una extensión de Git y en conjunto con GPG, o sea: necesitamos instalar GPG (dependiendo del sistema operativo puede que ya venga instalado) y git-secret (las instrucción de instalación de git-secret son muy simples y están publicadas en su página oficial).

Una vez que tenemos la herramienta instalada podemos ir al repositorio git donde queremos agregar información sensible y lo primero que debemos hacer correr el comando git secret init para indicarle a git-secret que queremos guardar información sensible en el repositorio en cuestión. Este comando va a crear un directorio .gitsecret que será utilizado por git-secret.

A continuación vamos a indicarle a git-secret nuestro mail (asociado a nuestra clave pública gpg) para que podamos tener acceso a la información sensible que guardemos en el repositorio. Esto lo hacemos con el comando git secret tell nicopaez@mimail.com.

A esta altura ya estamos en condiciones de comenzar a agregar información sensible. Supongamos entonces que tenemos un archivo con información sensible llamado secretos.txt y entonces queremos indicarle a git-secret que queremos que maneje este archivo para lo cual ejecutamos git secret add secretos.txt. Un efecto de este comando es que el archivo secretos.txt, que tiene la información sensible sin encriptar ha sido agregado al gitignore porque precisamente no queremos que git lo versione.

El siguiente paso es «ocultar» (encriptar) la información sensible ejecutando git secret hide. Este comando generará un archivo encriptado por cada uno de los archivos que hayamos agregado previamente como secretos. En este caso, se habrá generado un archivo secretos.txt.secret que contendrá la información encriptada del archivo secretos.txt. y que podrá ser agregado sin problemas al repositorio git (es seguro hacerlo porque su contenido está encriptado). El último paso es hacer git add y commit con el archivo secretos.txt.secret.

Resumiendo como queda la historieta:

  • el archivo secretos.txt.secret contiene nuestra información sensible encritada y está versionado en nuestro repositorio git. Toda persona con acceso al repositorio podrá acceder al archivo, pero al estar este encriptado, no podrán ver si contenido.
  • el archivo secretos.txt, no está versionado por git y solo existe localmente en mi máquina para poder ser utilizado por mi aplicación.
  • Si yo me clonara otra vez el repositorio, no tendría el archivo secretos.txt (pues no está versionado en el repositorio) sino que tendría que generarlo a partir de ejecutar git secret reveal. Este comando toma los archivos encriptados (en este caso secretos.txt.secret) y los desencripta. Obviamente para poder hacer esto, el usuario en cuestión tiene que tener permisos para acceder a la información sensible (esto se hace con el comando git secret tell que ya ejecutamos previamente y que a continuación explicaré con mayor detalle.

Hasta aquí tenemos la configuración inicial, con esto de ahora en más cada nuevo archivo con información sensible (o cada modificación) deberemos ejecutar git secret add y git secret hide y a continuación el usual git add y git commit.

Una última cuestión es cómo compartir esta información sensible con otros miembros del equipo. Para esto vamos a necesitar la clave pública gpg de la persona a quien querramos dar acceso (esa persona deberá exportar su clave haciendo gpg –armor –export your.email@address.com > clave_publica_de_un_colega.gpg). Dicha clave será típicamente un archivo que en primer lugar tendremos que importar con gpg haciendo gpg —import clave_publica_de_un_colega.gpg. Teniendo la clave importada podremos dar acceso a la persona en cuestión ejecutando git secret tell colega@email.com. Finalmente el último paso, que es fundamental, es reencriptar todos los secrets, para esto primero haremos un git secret reveal y a continuación un git secret hide -d.

Bien, esto es todo. Si deciden utilizar la herramienta para algún proyecto (más allá de probar lo que describí en este artículo) les recomiendo ver la documentación oficial de la herramienta.

4 confusiones habituales sobre TDD

Recientemente hablaba con un cliente sobre TDD y su poco uso en la industria a pesar de sus probados beneficios. Durante la charla me encontré, sin haberlo meditado previamente, hablando sobre confusiones habituales respecto de TDD que a mi parecer le juegan en contra.

La primer confusión, y posiblemente la más común, es confundir TDD con una técnica de testing. TDD no es una técnica de testing, como su nombre lo indica es un técnica de desarrollo. Al creer que es una técnica de testing, hay desarrolladores que directamente la dejan de lado (sin siquiera probarla) pensando que no es para uso de los desarrolladores sino para el uso de los testers :-(. Algo que aporta a esta confusión es que en algunas instituciones TDD es estudiado en materias de testing/calidad en lugar de materias de diseño/desarrollo. A favor de los confundidos admito que el nombre (Test-Driven Development) a pesar de ser preciso, puede resultar confuso.

Otra confusión que he visto reiteradamente en quienes comienzan/intentan utilizar TDD es ir directo al código sin absolutamente ningún ejercicio de diseño preliminar . La técnica es muy explícita en cuanto a comenzar por los tests y trabajar en pequeños incrementos. Pero ello no significa que no pueda (¿o deba?) hacer un poco de diseño preliminar, haciendo incluso algún diagrama y pensando en el diseño «final» (o diseño a mediano/largo plazo). En una época (allá por los ’90) había gente que hacía diseños muy detallados y luego pasaba de una a intentar implementar esos diseños en código. Luego de esa experiencia poco feliz, algunos se fueron al otro extremo sin siquiera pensar un poco antes de saltar al código. En lo personal siempre me gusta comenzar haciendo un diagrama del dominio del problema antes de saltar al código. Al mismo tiempo, cuando salto al código no es para implementar de una el dominio completo, sino que la implementación del dominio la hago incrementalmente generando incluso versiones reducidas/incompletas pero entregables al usuario. De esta forma puedo llegar a generar varias versiones de cara al usuario antes de tener materializar la visión inicial del dominio (que por cierto, es una visión que va evolucionando a medida que voy aprendiendo más del dominio).

Omitir premisas de la técnica es también una error habitual. TDD no es solamente comenzar por la prueba, hay varias cuestiones más y entre ellas una fundamental es trabajar en pequeños incrementos. Al no trabajar en pequeños incrementos, las pruebas que escribimos pueden ser más grandes/complejas y requerir mayor esfuerzo para hacerlas pasar. Al mismo tiempo podemos estar complicando el diseño (y la implementación) innecesariamente.

Finalmente, algunos creen que al hacer TDD no es necesario un esfuerzo de testing posterior y entonces no es necesario contar con la colaboración de testers en el proceso de desarrollo. Dado que TDD no es una técnica de testing, necesitamos testear nuestro software más allá de que hallamos hecho TDD. Obviamente que las características de ese testing van a ser distintas dependiendo de si el software fue desarrollado haciendo TDD o no. De entrada, si hicimos TDD el esfuerzo de testing posterior va a ser mucho menor pues varios casos ya van a estar testeados. También debemos tener presente que los tests generados en el ciclo de TDD son distintos a los tests que un tester realiza a posteriori, esto es así porque el objetivo de unos y otros tests es distinto. Más aún, TDD es una técnica surgida en un contexto Agile donde el rol de tester es radicalmente distinto a rol del tester en un contexto «tradicional» (no Agile) pero esto es material de otro artículo.

Libre recomendado: Wild West to Agile

Hace unos días terminé de leer este libro. Simplemente excelente. Su autor es Jim Highsmith, uno de los autores del Manifiesto Ágil. Jim ha escrito más de un libro y muchos artículos que nunca leí. Esa fue una de mis motivaciones para leer este libro.

El libro es en gran medida un repaso histórico, desde la perspectiva personal del autor, de la evolución de las metodologías y procesos de desarrollo. A lo largo del libro Jim va contando sus experiencias (que comienzan allá por los años 60) y que llegan hasta la actualidad. Creo que para quienes trabajamos en cuestiones de metodología y procesos es una excelente referencia para entender la evolución de la forma de trabajo y como una cosa llevó a la otra. Por otro lado creo que para aquellos «amantes de agile» es un lectura obligada para entender cómo fue gestándose Agile. El libro está plagado de anécdotas que van ejemplificando las distintas corrientes a lo largo del tiempo.

Una cosa que me gustó mucho del libro es la cuidada terminología. Jim dice explícitamente que prefiere hablar de Desarrollo de Software en lugar de Ingeniería de Software, reavivando esa eterna polémica. También habla explícitamente sobre «métodos estructurados», «metodologías monumentales», «métodos ágiles», «agile» y «agility». También hace una clara diferenciación entre método, metodología y mindset, términos que muchas veces se confunden (sobre todos los dos primeros).

Cuando habla de Agile hace explícita mención a prácticas técnicas y también a prácticas de gestión, resaltando las importancia de estas últimas.

En la parte final del libro se mete en temas de transformación digital y escalamiento. Aquí no habla de SAFe ni LeSS sino de EDGE y unFIX.

En fin, el libro me gusto mucho y lo super recomiendo.

Invitación & Iniciativa: Desarrollo con NicoPaez

El próximo lunes 15 de enero comenzaré esta nueva iniciativa. La idea es que voy a desarrollar una aplicación de forma iterativa e incremental, dedicando tan solo 15 minutos por día y aplicando las prácticas «modernas» desarrollo (BDD/TDD, CI, Test automation, etc) y gestión (slicing, estimación, planificación). En cierto modo voy a estar poniendo en práctica gran de los temas que vemos en MeMo2.

Estaré trabajando en Ruby casi puro, voy a intentar evitar utilizar complementos mágicos como Rails de forma que sea fácil seguirme y que incluso, quienes gusten, puedan trabajar a la par utilizando algún otro lenguaje.

Creo que mantener las sesiones acotadas a 15 minutos puede ser un gran desafío, pero en principio es la intención. Dicho esto, los interesados en participar me pueden mandar un mensaje aquí y los agrego a la cita para que les quede en el calendar y puedan acceder el meet.

¡Nos vemos el lunes 15 de enero a las 12:00 (hora Argentina, o sea: GMT-3)!

Actualización: comparto aquí el video de la primera sesión donde explico varios detalles de la iniciativa (alcance, grabación, etc)

Idea para trabajo final de carrera: SLR Assistant

La revisión sistemática de literatura (SLR) es un método de investigación muy comúnmente utilizado en medicina pero que desde hace un tiempo también se ha empezado a utilizar en investigaciones de Ingeniería de Software. Como su nombre lo indica, una SLR es una revisión sistemática, o sea, se revisa literatura siguiendo un proceso bien definido y que ha sido extensamente documentado por diversos autores entre los que cabe destacar a Barbara Kitchenham, posiblemente la máxima referente del tema en el área de Ingeniería de Software.

En cierto modo, siempre que hacemos investigación, revisamos investigaciones anteriores mínimamente para poder establecer un estado del arte y asegurarnos no estamos reinventando la rueda con nuestro trabajo. Pero la cuestión con las revisiones SLR es que se hacen con un proceso claramente definido que le da cierta rigurosidad y profundidad. Esto hace que una SLR pueda constituir una publicación en sí misma. En línea con esto yo mismo publiqué una revisión sistemática sobre la enseñanza de métodos ágiles cuando estaba haciendo mi trabajo final de especialización.

Típicamente cuando se trabaja en un revisión hay una primera fase de diseño y luego una de ejecución. Justamente la ejecución implica revisar artículos, extraer información, procesarla y finalmente sacar conclusiones. Esto es un proceso no trivial, bastante trabajoso que bien amerita tener una herramienta de soporte. Existen algunas herramientas para ayudar en el proceso de una SLR, pero a mi parecer tienen varias limitaciones (y poca adopción). También es habitual que la gente utilice herramientas genéricas como ser hojas de cálculo.

Dicho todo esto, mi idea de trabajo final de carrera es una hacer una herramienta de soporte para hacer revisiones sistemáticas: SLR Assistant. El trabajo incluiría hacer la herramienta y (al menos) una revisión sistemática para entender el proceso y probar la utilidad de la herramienta desarrollada. Interesados contactarme aquí.

La hora del Scrum Master técnico

Una publicación reciente de la Scrum Alliance sobre las habilidades en mayor demanda en la actualidad dice textualmente, entre otras cosas, «Delivery-facing agile roles, such as Scrum Masters, are being expected to be technical experts in addition to their agile responsibilities.» Esto está muy en línea con lo que yo mismo he observado en algunos de mis clientes.

Ocurre que en muchas organizaciones se toma el rol de Scrum Master como «exclusivo», o sea: se contrata una persona con habilidades de Scrum Master (y tal vez algunas otras habilidades «blandas») pero sin habilidades técnicas. Esto no está mal, pero tampoco pidamos peras al olmo: una persona sin habilidades técnicas será poco lo que podrá aportar en cuestiones técnicas de desarrollo/delivery. Creo que justamente en línea con este fenómeno (personas que solo saben de Scrum trabajando como Scrum Master) la última versión de la guía de Scrum no habla del Scrum Master como un rol sino como un conjunto de responsabilidades. Esto, a mi parecer, explicita el hecho de que las responsabilidades de «Scrum Mastering» puede ser tomadas por un Developer o algún otro rol (siempre que no haya conflicto de intereses).

Situación recurrente: una persona en el rol de Scrum Master con formación de Scrum Master pero sin formación en sistemas. La organización que lo contrata quiere «delivery» y en parte por ello espera que la persona en el rol de Scrum Master haga más que Scrum dicta del Scrum Master. Pedir que programe puede sonar mucho, pero pedirle habilidades de gestión suena bastante más razonable y aquí está muchas veces la cuestión. La gente que estudio sistemas estudio algo de gestión de proyectos pues es tema presente en todas las carreras de sistemas y hoy en día es muy posible que también haya estudiado Agile en general y Scrum en particular.

En parte fue esta situación la que me llevó a armar el Taller de Prácticas Técnicas para Scrum Masters que tan buena aceptación viene teniendo. En este taller vemos algunas cuestiones técnicas y también algunas cuestiones básicas de gestión de proyectos.

Siguiendo en esta línea de trabajo, estoy empezando a armar un Taller de Técnicas de Facilitación & Gestión para Tech Leads. el cual estará destinado a gente técnica que quiera tomar responsabilidades de facilitador de equipo, Scrum Master, etc. Obviamente tendrá algunos puntos de contacto con los del otro taller pero será un taller diferente y orientado a una audiencia diferente.

Si alguien está interesado en este taller puede contactarme por este formulario y le compartiré más información.