En esta entrada vamos a explorar qué propiedades tienen las API keys y cuáles pueden interesarnos para identificar las claves que deben ser rotadas.
API Keys rotation checker - III
- post
- Xavi Aznar
Photo by Mabel Amber
En esta entrada vamos a explorar qué propiedades tienen las API keys y cuáles pueden interesarnos para identificar las claves que deben ser rotadas.
En esta segunda entrada, el foco va a ser usar el paquete flag para que el usuario pueda proporcionar, por ejemplo, el projectId donde listar las API keys.
Haciendo limpieza de repositorios “viejos”, me encontré con GoogleCloudPlatform/professional-services. El servicio de IPAM (IP Address Management) que empezamos usando fue el proporcionado por los Servicios Profesionales de Google Cloud, pero antes de borrar el repositorio, me entretuve mirando qué otras soluciones se ofrecían…
En particular, GCP API key rotation checker me llamó la atención, pero tiene dos problemas fundamentales; el primero, que hace más de cinco años que no se ha actualizado 😔, y el segundo, que está en Python 😅. Afortunadamente, los dos pueden solucionarse re-escribiéndo la solución en Go 😜.
En ésta entrada, explico qué pasos he seguido…
Tenemos varios procesos que se basan en parsear datos proporcionados por los usuarios en un fichero CSV, validarlos y “hacer algo con ellos”.
Los scripts que se encargan de estos procesos se pueden dividir en dos categorías: sencillos pero “delicados” y robustos pero complicados.
Uno de nuestros scripts de validación ha crecido y crecido para incorporar todo tipo de transformaciones y validaciones… Pero como suele pasar en estos casos, la evolución ha sido orgánica, es decir, sin planificación… Y aunque es perfecto para la tarea que realiza, es difícil aprovechar todo lo que hemos desarrollado para poder reutilizarlo en cualquiera de los otros procesos y así, mejorarlos.
El problema no son las funciones que implementan una u otra función de validación; el problema es que hay que hay una relación invisible entre los datos en el CSV y las funciones que deben aplicarse a cada campo… Al no estar documentada esa relación, mantener los scripts resulta complicado si no se está familiarizado con la tarea para la que fueron diseñados.
En vez de seguir ampliando el problema, he desarrollado una aplicación que espero que pueda aplicarse de forma “universal” en todos los procesos y acabar con el problema de una vez por todas.
Y la solución que se me ocurrió fue la de definir un schema para el CSV.
Me gustaría poder generar aplicaciones en Bash en las que pudiera añadir el flag --help (o -h) y que me mostraran la ayuda o documentación para la función. Es decir, me gustaría que mis scripts de Bash se comportaran como otras aplicaciones, p.ej. git, terraform, kubectl, etc.
git --help proporciona una descripción de lo que hace git, qué comandos tiene, etc… Si quiero obtener ayuda de alguno de los comandos de git, como git add, sólo tengo que ejecutar git add --help para obtener ayuda específica sobre el comando en cuestión.
En esta entrada muestro cómo he logrado lo mismo en Bash.
El otro día uno de nuestros clientes nos solicitó crear Service Account Keys para poder automatizar unas tareas en Google Cloud. El cliente tenía experiencia anterior en AWS, donde es necesario crear Access Keys para que, durante el desarrollo de la aplicación, pudieran probarla como si se ejecutara en el cloud.
Sin embargo, en Google Cloud, las cosas funcionan de otra forma, y usar Service Account Keys es la última opción, por ser la menos segura. Personalmente, soy muy fan del diagrama de esta página Choose the right authentication method for your use case. Parte de la magia que hace innecesario generar Service Account Keys el cómo funcionan las Application Default Credentials (How Application Default Credentials works).
A continuación, un ejemplo de la magia de usar ADC y así no tener que generar Service Account Keys.
Uno de los pilares de Linux es que es un sistema compuesto por pequeñas utilizadades que hacen una cosa, pero la hacen extremadamente bien.
Podemos combinar la salida de un comando y enviarla, como input, a otro comando usando la pipe (|).
Por ejemplo, podemos usar cat $filename | grep 'hello' para filtrar el contenido del fichero $filename y quedarnos únicamente con las líneas que contengan hello.
¿Cómo podemos conseguir lo mismo en nuestras scripts en Bash?
Desde que descubrí los devcontainers se han convertido en una parte esencial tanto de mi trabajo como de mi hobby tecnológico. Y sin embargo, no había escrito nunca al respecto en el blog. Así que ha llegado el momento de solucionarlo.
He estado pensando en algunas mejoras con respecto al uso de NATS para montar un sistema de pipelines basado en las ideas de la entrada anterior PubSub con NATS y Bash.
Bash es increiblemente permisivo, por lo que se ha convertido en mi lenguaje de prototipado por defecto. Combinado con SQLite y Jq, me faltaba una última pieza para completar los diseños: un sistema pubsub. Ahora he encontrado una manera sencilla de integrar NATS (corriendo en Docker) con Bash.