Gestión centralizada de dominios y certificados en Google Cloud Platform

La discusión comienza con la importancia de gestionar certificados, particularmente en relación con las registraciones de dominios. Anteriormente, los dominios se gestionaban dentro de los entornos de producción de cada servicio, pero ahora, con la implementación de la plataforma, todos los dominios y sus respectivos certificados, incluidos los subdominios, están registrados en un lugar centralizado. Esto incluye dominios para entornos de desarrollo, staging y producción, señalando específicamente los dominios .cl y .com, así como Betaflux. El orador enfatiza que para cualquier nueva registración de dominio, es crucial crear el registro aquí y apuntarlo a la IP del certificado creado en el respectivo proyecto de GCP.

La conversación se centra en el proceso de implementación utilizando Terraform para la infraestructura de GCP. Se señala que César había incluido anteriormente Workload Identity en GCP dentro del proyecto SRSCO. Este proyecto cuenta con una Federación de Workload Identity, que es esencial para GitHub Actions. El hablante explica que la integración de cada proyecto de GCP en esta federación de identidades se automatiza a través de un script que se encuentra en el repositorio Better Scripts. Este script configura el proyecto de GCP, requiriendo que GCloud esté instalado localmente, y establece el proyecto con parámetros necesarios como el ID del Proyecto y el Entorno. El script también habilita la API de IAM, crea una Cuenta de Servicio con una convención de nombres estándar y asigna permisos específicos, incluidos los roles de Editor y Administrador de Seguridad, mientras se asegura de que se eliminen los permisos de Propietario innecesarios.

El proceso comienza con la federación a través de una carga de trabajo que coincide con GitHub Actions, que posteriormente crea un bucket para almacenar el estado de Terraform. Esta configuración es crucial para gestionar permisos basados en el entorno, permitiendo la publicación y suscripción a temas en diferentes proyectos, específicamente aquellos en Bubsub.

En el proyecto Platforms Pro, que integra múltiples dominios bajo un solo balanceador de carga, hay un total de 159 temas definidos. Cada dominio puede suscribirse a temas creados por otros dominios, facilitando la comunicación entre dominios. Por ejemplo, el dominio de Juegos puede suscribirse a un tema del proyecto Plataforma, lo que permite la recepción de mensajes de otros dominios.

Los equipos establecieron un estándar para la nomenclatura de temas, donde el entorno se antepone al nombre del tema. Actualmente, hay 330 temas, incluidos los de Stacking, que permiten a las cuentas de servicio crear o suscribirse a temas basados en el entorno, ya sea Dapp, Stacking o Producción.

Un aspecto significativo de la conexión de infraestructura entre GitHub y GCP implica un script para verificar el acceso IAM. Este script automatiza la extracción de registros de acceso recientes, que fue solicitado por el equipo de seguridad. Se integra con el módulo AuditLogs vinculado a la infraestructura de GCP, lo que permite la extracción de datos en un formato CSV basado en la activación del módulo AuditLogs.

El script está diseñado para extraer datos de proyectos, filtrando aquellos que comienzan con 'SIS', que probablemente son proyectos automatizados creados por otros servicios. Esto asegura que solo se incluyan proyectos relevantes en el proceso de extracción de datos, lo cual es crucial para mantener la claridad y el enfoque en la gestión de proyectos.

Se generó una discusión sobre la comparación entre los Registros de Auditoría en GCP y CloudTrail de AWS. Se aclaró que los Registros de Auditoría deben ser habilitados manualmente y pueden generar costos relacionados con el aumento de registros. Por defecto, GCP no activa los registros de acceso y lectura, que son esenciales para rastrear cambios y accesos dentro de la organización.

La discusión comienza con una referencia a la función de Bloqueos de Auditoría de GCP, destacando específicamente la Configuración Predeterminada. El orador señala que, aunque se registra 'DataWrite', faltan otras entradas relacionadas con las lecturas de Admin y DataWrite, lo que indica una posible omisión en las configuraciones de registro.

Se realizó una solicitud de seguridad para extraer todos los certificados de varios entornos en la nube. El hablante menciona un tercer script que puede facilitar esta extracción, que también proporciona resultados relacionados con la operación.

El cuarto script se presenta como una herramienta para actualizar permisos para Cuentas de Servicio en proyectos de IGCP. Este script se dirige específicamente a Cuentas de Servicio del tipo Terraform que se conectan con GitHub, permitiendo modificaciones masivas de permisos.

En respuesta a las preocupaciones de seguridad, se hizo una solicitud para aumentar la retención de registros. El orador explica que el bucket predeterminado creado por IGCP tendrá su período de retención extendido a un año. Sugieren considerar una estrategia separada para retener los registros de computación en un bucket de mayor duración, mientras que otros registros se mantendrán en el bucket predeterminado durante 30 días, enfatizando la necesidad de un enfoque de retención de registros más organizado.

El ponente presenta un proyecto de DevOps en GitHub que utiliza JavaScript para la automatización con Slack y GitHub. Este proyecto incluye varias Funciones en la Nube que agilizan las operaciones diarias, como notificar a los usuarios cuando alguien es agregado a la organización y automatizar la creación de repositorios con reglas predeterminadas y análisis de Sonar.

El orador desaconseja el uso de un comando específico para crear proyectos en Sonar, ya que no rastrea el tiempo automáticamente. En su lugar, recomienda agregar manualmente el repositorio a Sonar después de crearlo en GitHub para asegurar un análisis adecuado. También discuten la importancia de establecer reglas para las solicitudes de extracción y los permisos del equipo de manera eficiente.

Se describe una función que analiza la actividad de los usuarios dentro de la organización, particularmente para el grupo Copa Vida. El hablante menciona un sistema de notificación que alerta cuando los usuarios han estado inactivos durante un número específico de días, lo que puede ayudar a reducir costos al identificar y potencialmente eliminar usuarios inactivos.

El orador enfatiza las medidas de seguridad integradas en la automatización de Cloud Functions. Por ejemplo, al crear un repositorio, el sistema verifica si el usuario pertenece a un equipo válido y comprueba su dominio en el entorno de Slack de Betaflight, asegurando que solo los usuarios autorizados puedan realizar cambios a través del bot.

La discusión destaca un proyecto de JavaScript que crea un programador para respaldar bases de datos de Firestore cada 24 horas. Este programador está integrado con un sistema PubSub y una Función en la Nube, asegurando que las copias de seguridad se almacenen en un intervalo definido. Los usuarios pueden implementar este script utilizando el comando gcloud, asegurando sus copias de seguridad diarias sin esfuerzo.

Se plantean preocupaciones sobre la documentación README desactualizada de un repositorio, que data del lanzamiento de BTC. Aunque el código se ha actualizado, la documentación no refleja las prácticas actuales. Se sugiere que actualizar el README sería beneficioso para capturar el conocimiento legado y garantizar que los usuarios tengan acceso a pautas de uso precisas.

El aspecto más crítico discutido es el script que conecta los repositorios con Google Cloud Platform (GCP). Este script incorpora lógica para la gestión de múltiples proyectos utilizando PubSub y Federación de Identidad, enfatizando su importancia para las operaciones diarias de infraestructura.

Surge una pregunta respecto al proceso de restaurar copias de seguridad de Firestore. Se confirma que las copias de seguridad se han restaurado en el pasado, mencionando específicamente un caso con Check. El proceso de restauración implica seleccionar el archivo de copia de seguridad apropiado de la sección de importación/exportación de Firestore, donde los usuarios pueden elegir la fecha correcta y asegurarse de que el archivo de metadatos esté incluido para restaurar todos los datos con precisión.

La conversación aborda la disponibilidad de opciones de recuperación ante desastres para Firestore, que no estaban presentes al principio de su implementación. Sin embargo, las implicaciones de costo de habilitar esta función no están claras. Se señala que las funcionalidades anteriores requerían cambios en el código para cambiar a una base de datos de respaldo, lo que indica que el proceso actual de recuperación ante desastres puede no ser fácil de usar.

La discusión comienza con la configuración predeterminada de la base de datos en Firebase al crear un proyecto en Google Cloud Platform (GCP). Se señala que, por defecto, se crea una base de datos sin necesidad de hacer referencia a ella en el código. El orador enfatiza la importancia de acceder a la consola de Firebase para crear un nuevo proyecto, que puede estar vinculado a un proyecto GCP existente, lo que permite la funcionalidad de la base de datos sin configuración adicional.

Se plantea un problema de cumplimiento con respecto al uso de 'default' en un ID de base de datos, que no es aceptado debido a las normas ISO. El hablante aconseja que, si surge tal situación, los equipos deben consultar el inventario de activos para encontrar un ID común para la base de datos, asegurando el cumplimiento de las regulaciones.

El ponente comparte un repositorio para temas utilizados en proyectos de GCP, lo que facilita la creación y suscripción a temas en diferentes proyectos, mencionando específicamente el proyecto de Plataforma. Este módulo, cuando se configura con Terraform, permite a los equipos gestionar temas de manera efectiva dentro de sus respectivos entornos.

La conversación se desplaza hacia el pipeline de GCP, que utiliza una carga de trabajo del proyecto de desarrollo para federar permisos. Se ha creado un nuevo proyecto de datos, manteniendo una estructura similar pero organizando el código de infraestructura en una carpeta separada. El hablante destaca la importancia de entender estos detalles a través de la experiencia práctica.

Se solicita una lista de elementos que los equipos suelen pedir, como permisos para GitHub y revisiones de informes, para prepararse para futuros desafíos. Además, el hablante pregunta sobre algún proyecto que esté cerca de los límites de cuota o almacenamiento, lo que indica la necesidad de priorización y monitoreo de recursos.

La discusión concluye con una sugerencia de llevar a cabo una sesión de seguimiento para abordar cualquier incertidumbre respecto a las solicitudes del equipo. El orador planea crear un nuevo repositorio para documentar scripts y detalles importantes, invitando a la participación de los colegas para asegurar una cobertura completa de la información necesaria.