Acertar con la jerarquía de Google Cloud: carpetas, proyectos y org policies
En GCP el proyecto es el radio de explosión y la carpeta es donde vive la política. Casi ningún entorno que vemos usa ninguna de las dos a propósito. Esta es la estructura que desplegamos y las ocho políticas que ponemos el primer día.
Google Cloud te da un modelo organizativo más fuerte del que AWS tuvo durante años, y casi todos los equipos usan un tercio. Los proyectos se crean sobre la marcha desde la consola, todo cuelga directamente del nodo de organización y el IAM se concede por proyecto a quien necesitara acceso ese día.
La jerarquía no es papeleo. Es donde ocurre la herencia, y la herencia es lo único que mantiene gobernable un entorno que crece.
La estructura
Organización → carpetas por entorno y dominio → proyectos por carga de trabajo.
Solemos desplegar cuatro carpetas de primer nivel:
bootstrap— el proyecto semilla con el estado de Terraform, las cuentas de servicio que crean todo lo demás y nada que toque una carga. El acceso aquí es solo de emergencia.common— servicios compartidos: el proyecto anfitrión de Shared VPC, Artifact Registry, los proyectos de logging y monitorización, el de Cloud Build o CI.production— una subcarpeta por dominio (pagos, analítica) y un proyecto por carga dentro.non-production— la misma forma, con política más laxa y un tope duro de gasto.
El proyecto sigue siendo la unidad de radio de explosión. Una carga, un entorno, un proyecto. Las cuotas, el IAM, la facturación y casi todas las APIs son por proyecto, así que un proyecto compartido por cuatro servicios significa cuatro servicios compartiendo un techo de cuota y una superficie de IAM.
Los proyectos de pruebas de cada ingeniero van en su propia carpeta con alerta de presupuesto, ciclo de vida de 30 días y sin conectividad a la Shared VPC. Da a la gente un sitio legítimo para experimentar o experimentarán en staging.
Las ocho org policies que ponemos primero
Las restricciones de org policy se aplican a nivel de organización o carpeta y se heredan hacia abajo. Estas ocho eliminan la mayoría de lo que un escaneo de postura encontraría:
compute.requireShieldedVm— arranque seguro y vTPM en todas las VM.compute.vmExternalIpAccess— denegar por defecto y permitir explícitamente los pocos proyectos que necesitan IP pública de verdad.sql.restrictPublicIp— las instancias de Cloud SQL solo con IP privada.storage.publicAccessPrevention— impuesta en toda la organización. Es el equivalente en GCP del Block Public Access de S3 y no debería estar apagada nunca.iam.allowedPolicyMemberDomains— restringe las concesiones de IAM a tu propio dominio de Cloud Identity. Esta única restricción corta la clase de incidente "alguien compartió un bucket con su Gmail personal".iam.disableServiceAccountKeyCreation— la más valiosa de la lista. Las claves JSON de cuenta de servicio de larga vida son la credencial que se filtra, y Workload Identity Federation elimina la necesidad de tenerlas.compute.restrictVpcPeeringycompute.vmCanIpForward— mantienen la topología de red bajo control del equipo de redes.gcp.resourceLocations— fija los recursos a las regiones en las que operas, que es a la vez un control de latencia y de residencia de datos.
Aplícalas en el nodo de organización con excepciones a nivel de carpeta, no al revés. Una política con veinte excepciones por proyecto no es una política.
IAM que sobrevive al crecimiento
Tres reglas que lo mantienen manejable:
Concede a grupos, nunca a usuarios. Cada binding en Terraform referencia un grupo de Google sincronizado desde tu proveedor de identidad. Entrar en un equipo pasa a ser una pertenencia a grupo, y la baja pasa a ser una acción en lugar de cuarenta.
Concede en el ámbito más pequeño que funcione, y prefiere roles predefinidos a los básicos. roles/editor sobre un proyecto está cerca de admin e incluye poder concederse más. Es el hallazgo más común en una revisión de GCP.
Usa credenciales de vida corta en todas partes. Workload Identity Federation para CI y para cargas fuera de GCP, Workload Identity para pods de GKE, y suplantación de cuenta de servicio para los humanos que necesitan acceso elevado. Si existe un fichero .json de clave en algún punto de tu entorno, ese es el ticket que hay que abrir primero.
Facturación y etiquetas
Una cuenta de facturación, exportación de facturación a BigQuery desde el primer día y una política de etiquetas impuesta en Terraform: cada proyecto lleva env, owner y centro-de-coste. Sin la exportación no puedes responder una pregunta de coste con SQL; sin las etiquetas la respuesta tiene una fila grande de "sin atribuir" que no es de nadie. El mismo problema aparece en todas las nubes — es el paso uno del artículo de la factura de AWS y aquí es idéntico.
Todo esto es Terraform, aplicado desde el proyecto bootstrap por un pipeline. Crear un proyecto en particular no debería ser nunca una acción de consola, porque un proyecto creado en consola no tiene dueño, ni etiquetas, ni base. Es de lo primero que arreglamos en un proyecto cloud.
Qué hacer esta semana
Abre la página de políticas de organización y comprueba tres restricciones: iam.disableServiceAccountKeyCreation, storage.publicAccessPrevention e iam.allowedPolicyMemberDomains. Si alguna no está impuesta, ya tienes el trabajo de la semana, y las tres se revierten con un clic si algo se rompe.