Photo by Mabel Amber
En la solución original de Google Professional Services, API Key Rotation Checker mostraba las API keys que deben rotarse y las que no en dos grupos diferentes.
Al mostrar por pantalla los resultados, ya incluimos un icono para diferenciar las API keys. Ahora vamos a introducir un flag para filtrar las API keys encontradas, no sólo cuando las mostramos por pantalla, sino también cuando las exportamos a cualquiera de los formatos soportados.
Hasta ahora hemos estado examinando las API keys en un solo proyecto. Ahora vamos a obtener la lista de proyectos a los que el usuario tiene acceso, para poder examinar API keys en todos ellos.
En esta entrada voy a mostrar cómo, gracias a una buena organización del código previa, podemos añadir nuevas maneras de mostrar las API keys sin tener que realizar modificaciones importantes.
Ahora que somos capaces de mostrar cuántos dias hace que se creó una API key, ha llegado el momento de comparar ése dato con el periodo de rotación y así indicar si la API key debe ser rotada o no.
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…
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.
Cloud Workstations nos permite tener la misma máquina a todos los miembros del equipo, independientemente de si usamos un Mac o un equipo con Windows. Partiendo de una imagen de contenedor, podemos desplegar una máquina virtual y usar Code OSS (la versión open source de Visual Studio Code) con las mismas extensiones pre-instaladas, la misma configuración, etc…
Quiero presentar el script a mis compañeros antes de subirlo a Github, así que en la entrada de hoy me voy a centrar en explicar cómo he simplificado el número de parámetros requeridos para gestionar (crear/arrancar/detener/eliminar) una workstation sin tener que recordar (o conocer) el nombre del clúster, de la configuración usada, etc…
