Cloud Governance

Cloud Governance define las reglas del juego para usar la nube en Grupo Herdez. Nuestro objetivo es asegurar consistencia, seguridad y eficiencia en la gestión de nuestra infraestructura en GCP.

Estructura Organizacional en GCP

Para mantener el orden, los recursos en GCP se organizan en una jerarquía estricta.

Jerarquía GCP — Grupo Herdez

Organización

grupoherdez.com

Políticas globales · Control central

Folder

Production

Máxima seguridad

Folder

QA

Pre-producción

Folder

Development

Flexibilidad

Proyecto

app-A-prd

Recursos de producción

Proyecto

app-A-qa

Recursos de QA

Proyecto

app-A-dev

Recursos de desarrollo

Mensaje clave Organization → Folders por ambiente → Projects. Las policies se heredan automáticamente.

• Organización: El nivel raíz, donde se aplican las políticas más globales.
• Folders: Agrupan proyectos por ambiente (production, qa, development). Las políticas de seguridad más estrictas se aplican al folder de production.
• Proyectos: Contienen los recursos de una aplicación para un ambiente específico.

---

Políticas Clave de Recursos

Para garantizar la seguridad y el control, aplicamos varias políticas a nivel de organización.

Política	Descripción	Aplicación
Ubicación de Recursos	Solo se permiten recursos en regiones aprobadas (ej. us-central1, us-east1).	Bloqueo (Deny)
IPs Externas	Se prohíbe el uso de IPs públicas en VMs, salvo excepciones muy específicas.	Bloqueo (Deny)
Tipos de VM	Solo se permiten familias de máquinas eficientes (E2, N2, etc.).	Auditoría y Alerta
Claves de Service Account	Se prohíbe la creación de nuevas claves. Se debe usar Workload Identity.	Bloqueo (Deny)
Acceso Público	Se prohíbe por defecto el acceso público a buckets de Storage.	Bloqueo (Deny)

Infraestructura como código (IaC)

Todo aprovisionamiento de infraestructura debe realizarse a través de Terraform y ser validado por el pipeline de CI/CD. La creación manual de recursos en la consola de GCP está estrictamente prohibida para ambientes productivos.

---

Control de Acceso (IAM)

Nuestro modelo se basa en el principio de privilegio mínimo.

• Grupos: Los permisos no se asignan a usuarios individuales, sino a grupos predefinidos en Google Workspace (ej. dev-team-ecommerce@, security-admins@).
• Roles: Utilizamos una combinación de roles básicos de GCP (Viewer, Editor) y roles personalizados (roles/hera.deployer) para otorgar solo los permisos necesarios.
• Workload Identity: Es el método preferido y obligatorio para que las aplicaciones en GKE accedan a otros servicios de GCP, eliminando la necesidad de gestionar claves de service account.

---

Networking

• Shared VPC: Utilizamos un modelo de VPC Compartida donde una VPC central es gestionada por el equipo de infraestructura, y los proyectos de las aplicaciones se conectan a ella. Esto centraliza el control de la red.
• Reglas de Firewall: Por defecto, todo el tráfico de entrada desde internet está bloqueado (deny-all-ingress). Se crean reglas explícitas para permitir solo el tráfico necesario (ej. desde el balanceador de carga de GCP).
• VPC Service Controls: Creamos “perímetros de servicio” que actúan como un firewall virtual alrededor de nuestros proyectos más críticos, previniendo la exfiltración de datos.