Guía

Aplicar medidas preventivas en toda una organización, como restringir las ubicaciones de los recursos o deshabilitar la creación de claves de cuentas de servicio.

→Aplicar restricciones de políticas de la organización (por ejemplo, `constraints/gcp.resourceLocations`, `constraints/iam.disableServiceAccountKeyCreation`) a nivel de organización o carpeta.

Por qué: Las políticas de la organización se heredan y aplican a nivel de API, previniendo acciones no conformes antes de que ocurran. Esto es más efectivo que la detección y remediación reactiva.

Referencia↗

Estructurar una organización multi-departamental y multi-entorno para gestionar políticas y control de acceso de manera efectiva.

→Diseñar una jerarquía de carpetas, típicamente: Organización > Unidad de Negocio (Carpeta) > Entorno (por ejemplo, prod, staging) (Subcarpeta) > Proyectos.

Por qué: Esta estructura permite una herencia granular de políticas. Las políticas comunes se establecen a nivel de unidad de negocio, mientras que las políticas específicas del entorno (por ejemplo, más restrictivas para `prod`) se establecen a nivel de entorno.

Consolidar registros de todos los proyectos para cumplimiento, análisis de seguridad y resolución de problemas operativos con optimización de costos.

→Crear un sumidero de registros agregado a nivel de organización. Enviar los registros a múltiples destinos según sea necesario: BigQuery para análisis, Cloud Storage (Coldline/Archive) para archivo a largo plazo/bajo costo, y Pub/Sub para streaming en tiempo real a un SIEM.

Por qué: Este enfoque por niveles optimiza tanto el costo como la capacidad. BigQuery proporciona potentes capacidades de consulta, mientras que Cloud Storage ofrece archivo económico. Usar un solo destino es demasiado costoso o no lo suficientemente performante para todos los casos de uso.

Referencia↗

Prevenir la exfiltración de datos de servicios gestionados como BigQuery y Cloud Storage, permitiendo el acceso solo desde redes o identidades autorizadas.

→Crear un perímetro de VPC Service Controls alrededor de los proyectos que contienen datos sensibles. Definir niveles de acceso para permitir el acceso desde rangos IP específicos (red corporativa) o dispositivos.

Por qué: VPC Service Controls crea un perímetro virtual alrededor de los servicios basados en API, mitigando los riesgos de credenciales robadas o políticas de IAM mal configuradas al bloquear el acceso desde fuera del perímetro.

Establecer medidas de seguridad que no puedan ser anuladas por los propietarios de proyectos, como evitar que se otorgue un rol específico.

→Implementar políticas de denegación de IAM a nivel de organización o carpeta. Estas políticas deniegan explícitamente los permisos y siempre anulan cualquier política de `permitir`.

Por qué: Las políticas de denegación proporcionan una forma potente de aplicar controles de seguridad a nivel de organización que no pueden ser eludidos en niveles inferiores de la jerarquía de recursos, asegurando una postura de seguridad consistente.

Asegurar que todos los nuevos proyectos se aprovisionen con una configuración base estándar (redes, IAM, logging, etc.).

→Utilizar Infrastructure as Code (por ejemplo, Terraform con Cloud Build) para crear una "zona de aterrizaje". Automatizar la creación y configuración de proyectos a través de una pipeline.

Por qué: La automatización asegura la consistencia, reduce errores manuales y acelera el aprovisionamiento de proyectos. Codifica las mejores prácticas, haciendo que la gobernanza sea auditable y repetible.

Permitir que sistemas externos (como GitHub Actions o CI/CD on-premise) accedan a recursos de GCP sin usar claves de cuentas de servicio de larga duración.

→Configurar Workload Identity Federation. Crear un proveedor que confíe en el IdP externo (por ejemplo, GitHub OIDC) y mapear identidades externas a una cuenta de servicio de GCP. Utilizar condiciones de atributos para restringir el acceso a repositorios/ramas específicos.

Por qué: Esto elimina la necesidad de gestionar y rotar claves de cuentas de servicio, lo cual es un riesgo de seguridad importante. Proporciona credenciales de corta duración basadas en la identidad.

Centralizar la administración de red (VPCs, subredes, firewalls) permitiendo que equipos separados gestionen sus propios recursos de proyecto.

→Implementar Shared VPC. Crear un "proyecto host" para recursos de red y "proyectos de servicio" para cargas de trabajo de aplicaciones. Otorgar `roles/compute.networkUser` a las identidades de los proyectos de servicio.

Por qué: Shared VPC desacopla la administración de red de la administración de proyectos, proporcionando control centralizado y seguridad mientras otorga autonomía a los equipos. Escala mejor y es más seguro que el emparejamiento de VPC para este caso de uso.

Gestionar las configuraciones y aplicaciones de los clústeres de GKE de forma declarativa desde un repositorio Git.

→Utilizar un repositorio Git como la única fuente de verdad para los manifiestos. Instalar Config Sync en los clústeres de GKE para reconciliar continuamente el estado del clúster con la configuración del repositorio.

Por qué: GitOps proporciona una forma auditable, controlada por versiones y automatizada de gestionar Kubernetes. Separa CI (construcción de artefactos) de CD (sincronización de estado).

Prevenir el despliegue de imágenes de contenedores con vulnerabilidades críticas.

→Habilitar el escaneo automático de vulnerabilidades en Artifact Registry. En la pipeline de Cloud Build, añadir un paso que use la API de Container Analysis para buscar vulnerabilidades y falle la compilación si se encuentran problemas críticos.

Por qué: Esto crea una puerta de calidad automatizada en la pipeline de CI, evitando que los artefactos vulnerables lleguen a un estado desplegable. Adelanta la seguridad.

Aplicar en tiempo de ejecución que solo las imágenes de contenedor de confianza y firmadas puedan ser desplegadas en GKE o Cloud Run.

→Implementar Binary Authorization. Crear atestadores (por ejemplo, para pasar escaneos de vulnerabilidades, aprobación de QA). Configurar la pipeline de CI para crear atestaciones. Aplicar una política en GKE/Cloud Run que requiera atestaciones específicas para el despliegue.

Por qué: Binary Authorization proporciona una fuerte aplicación basada en políticas en el momento del despliegue. Protege contra el despliegue de imágenes comprometidas o no verificadas, incluso si llegan al registro.

Referencia↗

Acceder a información sensible como claves API o contraseñas durante una ejecución de Cloud Build sin exponerlas en registros o código fuente.

→Almacenar secretos en Secret Manager. En el `cloudbuild.yaml`, usar el campo `availableSecrets` para montar el secreto como una variable de entorno o un archivo.

Por qué: Esta es la integración nativa y segura. Cloud Build maneja la autenticación y automáticamente redacta los valores secretos de los registros, evitando la exposición accidental.

Establecer una cadena de custodia verificable para los artefactos de software para asegurar que fueron construidos por un sistema de confianza a partir de código fuente de confianza.

→Usar Cloud Build para generar atestaciones de procedencia compatibles con SLSA. Almacenar estas atestaciones en Artifact Registry junto con las imágenes. Usar Binary Authorization para verificar la procedencia antes del despliegue.

Por qué: SLSA proporciona un marco para fortalecer la cadena de suministro de software. Esta combinación de herramientas proporciona una cadena de confianza verificable de extremo a extremo, desde la fuente hasta la producción.

Ejecutar trabajos de CI/CD que necesitan acceder a recursos en una VPC privada, como un Artifact Registry privado o una base de datos Cloud SQL.

→Crear un pool privado de Cloud Build y configurar el emparejamiento de VPC entre la red del pool y su VPC objetivo. Configurar las compilaciones para que se ejecuten en este pool.

Por qué: Los pools privados proporcionan aislamiento de red y permiten que las compilaciones accedan de forma segura a los recursos en una red privada sin exponerlos a internet.

Eliminar automáticamente imágenes de contenedor antiguas o no utilizadas para gestionar los costos de almacenamiento mientras se retienen imágenes importantes.

→Configurar políticas de limpieza de Artifact Registry. Usar una política de `keep` para etiquetas como `production` y `latest`. Usar políticas de `delete` basadas en la antigüedad, patrones de etiquetas y recuentos de versiones para otras imágenes.

Por qué: Las políticas de limpieza proporcionan una forma declarativa y automatizada de gestionar el ciclo de vida de las imágenes, equilibrando el ahorro de costos con la necesidad de retener artefactos de producción y de desarrollo reciente.

Automatizar un despliegue multi-etapa desde dev a staging y a producción con aprobaciones y diferentes estrategias por entorno.

→Definir una única pipeline de entrega de Cloud Deploy con una progresión de objetivos (dev, staging, prod). Configurar `requireApproval: true` para el objetivo de producción y especificar diferentes estrategias de despliegue (por ejemplo, canary) para cada objetivo.

Por qué: Cloud Deploy proporciona un servicio de entrega continua gestionado y auditable. Simplifica los patrones de entrega progresiva como despliegues canary y blue-green con aprobaciones y reversiones integradas.

Definir métricas para medir la fiabilidad de un servicio desde la perspectiva del usuario.

→Definir indicadores de nivel de servicio (SLIs) basados en preocupaciones del usuario: disponibilidad (porcentaje de solicitudes exitosas), latencia (porcentaje de solicitudes más rápidas que un umbral) y corrección/frescura (porcentaje de datos procesados correctamente o que están actualizados).

Por qué: Los SLIs deben medir la satisfacción del usuario, no la salud interna del servidor. Métricas como la utilización de CPU son causas, mientras que la alta latencia es un síntoma. SRE se enfoca en monitorear y gestionar los síntomas.

Recibir notificaciones de violaciones de SLO con la suficiente antelación para reaccionar, sin ser inundado por alertas de problemas menores y transitorios.

→Configurar alertas basadas en la tasa de consumo del SLO (la velocidad a la que se consume el presupuesto de error). Utilizar alertas de múltiples ventanas: una tasa de consumo alta en una ventana corta para páginas críticas, y una tasa de consumo baja en una ventana larga para tickets no urgentes.

Por qué: Las alertas de tasa de consumo son predictivas. Alertan sobre la *tasa* de fallo, lo que indica un problema real, en lugar de una única solicitud fallida, reduciendo la fatiga por alertas y centrándose en lo que importa.

Referencia↗

Diagnosticar problemas de latencia en una arquitectura de microservicios comprendiendo el ciclo de vida completo de una solicitud.

→Instrumentar servicios con SDKs de OpenTelemetry y exportar trazas a Cloud Trace. Asegurar que el contexto de la traza se propague a través de las llamadas al servicio (incluyendo a través de colas de mensajes como Pub/Sub).

Por qué: OpenTelemetry proporciona un estándar neutral de proveedor para la instrumentación. Cloud Trace visualiza el flujo de solicitudes de extremo a extremo, facilitando la identificación del servicio u operación que es el cuello de botella.

Asegurar que los registros de aplicaciones en GKE sean correctamente analizados, buscables y tengan el nivel de gravedad adecuado en Cloud Logging.

→Configurar las aplicaciones para que escriban registros en `stdout`/`stderr` en formato JSON. Incluir un campo `severity` que coincida con los valores esperados de Google Cloud (por ejemplo, "INFO", "ERROR").

Por qué: El agente de registro predeterminado de GKE recoge y analiza automáticamente los registros JSON de stdout, haciéndolos estructurados y consultables en Cloud Logging sin necesidad de un sidecar o un agente personalizado.

Rastrear, visualizar y alertar sobre el cumplimiento de SLO y el consumo del presupuesto de errores para un servicio.

→Usar la función de Service Monitoring de Cloud Monitoring. Definir un servicio, crear SLIs (por ejemplo, disponibilidad desde un balanceador de carga), establecer objetivos de SLO y configurar políticas de alerta de tasa de consumo.

Por qué: Esta función nativa automatiza los cálculos complejos de cumplimiento de SLO y presupuestos de errores, proporciona paneles predeterminados y se integra con el sistema de alertas.

Encontrar rápidamente la causa raíz de un problema vinculando métricas, trazas y registros.

→Asegurarse de que los IDs de traza se incluyan en los registros estructurados. Utilizar las funciones de Cloud Monitoring, como los ejemplares de traza en los gráficos de métricas para saltar a una traza específica durante una anomalía de métrica, y luego desde esa traza, saltar a los registros correlacionados.

Por qué: La capacidad de pivotar sin problemas entre los tres pilares de la observabilidad (métricas, registros, trazas) es clave para reducir el Tiempo Medio de Resolución (MTTR).

Crear métricas y alertas personalizadas para eventos específicos de la aplicación que solo están disponibles en los datos de registro, como registros de usuarios o fallos de pago.

→En Cloud Logging, crear una métrica basada en registros. Definir un filtro para que coincida con las entradas de registro relevantes y configurar el tipo de métrica (contador o distribución). Usar esta métrica personalizada en paneles y políticas de alerta.

Por qué: Las métricas basadas en registros permiten convertir datos de registro no estructurados o semiestructurados en datos de series temporales estructurados, lo que facilita la supervisión y la alerta sobre los KPI a nivel de negocio sin cambiar el código de la aplicación.

Diagnosticar problemas de rendimiento de la base de datos, como consultas lentas, sin añadir carga a la base de datos.

→Habilitar Cloud SQL Insights y Query Insights en la instancia de Cloud SQL. Usar el panel para identificar consultas de alta carga, analizar planes de ejecución y ver tendencias de rendimiento.

Por qué: Query Insights proporciona una monitorización ligera y sin agentes del rendimiento de las consultas. Ayuda a los administradores de bases de datos y a los desarrolladores a identificar consultas ineficientes sin la sobrecarga de las herramientas de perfilado tradicionales.

Monitorizar proactivamente los recorridos críticos de los usuarios o la disponibilidad de la API desde una perspectiva externa.

→Utilizar las comprobaciones de tiempo de actividad de Cloud Monitoring para simples comprobaciones HTTP/TCP. Para flujos de usuarios de varios pasos (por ejemplo, inicio de sesión, añadir al carrito, pagar), usar monitores sintéticos, que ejecutan scripts personalizados (por ejemplo, Puppeteer) en un entorno gestionado.

Por qué: La monitorización sintética simula interacciones reales del usuario, lo que permite detectar problemas antes de que lo hagan los usuarios. Prueba toda la pila de afuera hacia adentro.

Equilibrar la necesidad de fiabilidad del servicio con la necesidad de lanzar nuevas características.

→Definir un objetivo de nivel de servicio (SLO) (por ejemplo, 99.9% de disponibilidad). El 0.1% restante es el presupuesto de error. Si el presupuesto está mayormente intacto, lanzar características. Si el presupuesto se agota, detener los lanzamientos de características y centrarse en mejoras de fiabilidad.

Por qué: El presupuesto de error proporciona un marco basado en datos para tomar decisiones de riesgo, alineando a los equipos de ingeniería, producto y negocio en un objetivo común.

Aprender de los incidentes para evitar que se repitan, al tiempo que se fomenta una cultura de seguridad psicológica.

→Realizar postmortems sin culpa después de los incidentes. Centrar la investigación en factores sistémicos, lagunas en los procesos y fallos de herramientas, no en atribuir culpas a individuos. El resultado debe ser una lista de elementos de mejora accionables.

Por qué: Una cultura sin culpa fomenta la comunicación honesta y abierta, lo que lleva a una comprensión más precisa de las causas raíz de un incidente y a acciones preventivas más efectivas.

Coordinar la respuesta a un incidente mayor de manera efectiva, evitando confusiones y duplicación de esfuerzos.

→Implementar un sistema de comando de incidentes (ICS) con roles claramente definidos: Comandante de Incidentes (coordinación general), Líder de Operaciones (investigación/corrección técnica) y Líder de Comunicaciones (actualizaciones a las partes interesadas).

Por qué: ICS proporciona una estructura estandarizada y escalable para la respuesta a incidentes, asegurando líneas claras de autoridad y comunicación, lo cual es crucial para resolver problemas complejos rápidamente.

Medir el rendimiento de una organización de entrega de software.

→Rastrear las cuatro métricas clave de DORA: Frecuencia de Despliegue (con qué frecuencia), Tiempo de Espera para Cambios (cuánto tiempo desde el commit hasta el despliegue), Tasa de Fallo de Cambios (qué porcentaje de despliegues causa fallos) y Tiempo para Restaurar el Servicio (MTTR).

Por qué: Estas cuatro métricas proporcionan una visión equilibrada tanto de la velocidad de desarrollo como de la estabilidad operativa, y se ha demostrado que se correlacionan con organizaciones de alto rendimiento.

Un equipo de SRE está dedicando demasiado tiempo a tareas operativas manuales y repetitivas (toil), sin tiempo para proyectos de ingeniería.

→Identificar y cuantificar el "toil" que consume más tiempo. Priorizar y automatizar estas tareas (por ejemplo, implementar autoescalado en lugar de escalado manual, auto-remediación para alertas comunes). Limitar el "toil" a < 50% del tiempo del ingeniero.

Por qué: El "toil" es un lastre para la productividad y la moral. Reducirlo sistemáticamente mediante la automatización libera a los ingenieros para trabajar en mejoras de fiabilidad a largo plazo.

Atribuir los costos de la nube con precisión a diferentes equipos, servicios o entornos en una infraestructura compartida.

→Implementar una estrategia consistente de etiquetado/etiquetado. Utilizar estas etiquetas para filtrar en los informes de Cloud Billing. Para GKE, habilitar la asignación de costos de GKE para desglosar los costos por namespace o carga de trabajo.

Por qué: La asignación precisa de costos proporciona visibilidad, lo que impulsa la rendición de cuentas. Los equipos que pueden ver sus gastos están capacitados para optimizarlos.

Optimizar los costos de cómputo para un conjunto diverso de cargas de trabajo (estable, interrumpible, desarrollo/prueba).

→Hacer coincidir la carga de trabajo con el modelo de precios. Utilizar descuentos por uso comprometido (CUDs) para cargas de trabajo estables, 24/7. Utilizar VMs Spot para trabajos tolerantes a fallos e interrumpibles (por ejemplo, procesamiento por lotes). Programar los entornos de desarrollo/prueba para que se apaguen fuera del horario laboral.

Por qué: Un enfoque único para los precios de cómputo es ineficiente. Usar la herramienta adecuada para el trabajo puede generar ahorros significativos (>70%) sin afectar el rendimiento.

Optimizar los costos y el rendimiento de GKE asegurando que los pods soliciten las cantidades adecuadas de CPU y memoria.

→Desplegar el Vertical Pod Autoscaler (VPA) en modo `recommendation`. Analizar sus sugerencias para ajustar las `requests` de recursos de los pods. Una vez seguro, cambiar al modo `auto` para un dimensionamiento continuo.

Por qué: El aprovisionamiento excesivo de pods desperdicia dinero, mientras que el aprovisionamiento insuficiente causa problemas de rendimiento (throttling, OOMKilled). VPA utiliza datos de uso reales para hacer recomendaciones precisas de tamaño, mejorando tanto la eficiencia como la estabilidad.

Reducir la latencia causada por los arranques en frío para un servicio de Cloud Run.

→Configurar un valor de `min-instances` para mantener un número de instancias activas. Además, optimizar la imagen del contenedor (imagen base más pequeña, menos capas) y el código de inicio de la aplicación (inicialización perezosa).

Por qué: `min-instances` es la forma más directa de reducir los arranques en frío, pero tiene un costo. Combinarlo con la optimización del contenedor y el código proporciona un enfoque equilibrado para el rendimiento y el costo.

Optimizar los costos para una carga de trabajo de análisis de BigQuery a gran escala con patrones de consulta variables.

→Cambiar de precios bajo demanda a BigQuery Editions (slots). Adquirir un compromiso de slots base para una carga predecible y habilitar el autoescalado para picos. Además, optimizar las consultas usando tablas particionadas/agrupadas y evitando `SELECT *`.

Por qué: Para cargas de trabajo consistentes, los precios basados en slots son más rentables que bajo demanda. El autoescalado proporciona flexibilidad para ráfagas mientras controla los costos. La optimización de consultas y tablas reduce la cantidad de datos procesados, disminuyendo directamente los costos.

Reducir los altos costos de egreso de red para una aplicación distribuida globalmente.

→Usar Cloud CDN para almacenar en caché contenido estático en el borde, más cerca de los usuarios. Para el tráfico dinámico, elegir el nivel de servicio de red apropiado (Premium para rendimiento, Standard para ahorro de costos). Procesar datos regionalmente para minimizar el tráfico entre regiones.

Por qué: El egreso es un factor importante de costo. CDN descarga tráfico del origen, reduciendo directamente el egreso. El uso cuidadoso de los niveles de red y el procesamiento regional de datos pueden reducir significativamente los costos.