Tema 1 de 5
Jerarquía de recursos y políticas de organización
Antes de desplegar una sola máquina virtual hay que decidir dónde vive: en qué organización, en qué carpeta y en qué proyecto. Esa estructura determina quién es dueño de los recursos, cómo se heredan los permisos y qué restricciones aplican. El examen pregunta tanto la jerarquía como el Organization Policy Service que la protege.
Contenido
- La jerarquía de recursos
- El recurso organización
- Organizaciones independientes (standalone)
- Carpetas
- Proyectos
- Cerrar y restaurar un proyecto
- Organization Policy Service
- Tipos de restricciones
- Herencia, dry-run y condiciones
- Security baseline de Google Cloud
- Etiquetas (tags) frente a labels
- Escenarios de examen
- Trampas frecuentes del examen
La jerarquía de recursos
Un árbol con la organización como raíz, carpetas opcionales para agrupar y proyectos que contienen los recursos de servicio: máquinas virtuales, buckets, bases de datos.
Todos los recursos, salvo el más alto, tienen exactamente un padre. Google Cloud destaca dos ventajas de esta estructura:
Propiedad
El ciclo de vida de un recurso queda ligado a su padre. Los proyectos pertenecen a la organización, no al empleado que los creó: si se marcha, el proyecto sigue activo.
Herencia
Las políticas de permisos (allow), de denegación (deny) y de organización bajan por el árbol. Un rol concedido en una carpeta lo heredan todos sus proyectos.
La política efectiva de cada recurso es la combinación de las políticas aplicadas directamente sobre él y las heredadas de sus antepasados.
El recurso organización
Representa a una entidad, como una empresa, y es el nodo raíz. Para tener uno hace falta una cuenta de Google Workspace o de Cloud Identity asociada a un dominio. Cada cuenta de Workspace o Cloud Identity se asocia con exactamente una organización, y cada organización con exactamente un dominio.
- Se crea automáticamente cuando un usuario del dominio inicia sesión en la consola y acepta los términos, o cuando crea un proyecto o una cuenta de facturación sin organización asociada.
- Los proyectos creados antes aparecen como «No organization» y hay que migrarlos a mano.
- Una vez existe la organización, los usuarios administrados del dominio solo pueden crear proyectos dentro de ella.
- La política inicial concede Project Creator y Billing Account Creator a todo el dominio, para que nadie note el cambio.
- Se identifica por un ID numérico único (sin ceros a la izquierda) que se obtiene con
gcloud organizations list.
| Rol | Responsabilidades |
|---|---|
| Superadministrador de Workspace o Cloud Identity | Asigna el rol de Organization Administrator, es el contacto en caso de recuperación y controla el ciclo de vida de la cuenta y de la organización. No debe usarse para la administración diaria. |
Organization Administrator (roles/resourcemanager.organizationAdmin) | Define políticas allow y deny, concede roles y ve la estructura. Por mínimo privilegio, no puede crear carpetas ni proyectos sin roles adicionales. |
Google recomienda que el superadministrador delegue el rol de Organization Administrator en otro usuario o grupo para separar funciones, porque Workspace y Google Cloud suelen gestionarlos departamentos distintos.
Organizaciones independientes (standalone)
El temario incluye configurarlas. Son una segunda vía para tener una organización sin Cloud Identity ni dominio: se crean automáticamente para los clientes nuevos de la prueba gratuita cuando se registran con una dirección de Google y aceptan los términos. No están disponibles para cuentas de Google Cloud que ya existían.
Nombre
Nombre de usuario + «-org» (lara_brown → lara-brown-org). Se puede cambiar; no puede ser un nombre de dominio.
Roles iniciales
El creador recibe Organization Owner (roles/cloudowner.admin, gestionado fuera de IAM) y Organization Administrator.
Ventajas
Propietarios con identidades federadas, varias organizaciones para probar y varios propietarios para no depender de una persona.
- Se crea una organización por cuenta de usuario, pero un mismo usuario puede ser propietario de varias.
- Los propietarios se invitan desde la página Organization details y deben aceptar en 30 días. Pueden ser cuentas de Google o principales de un grupo de Workforce Identity Federation; las cuentas de servicio no.
- Siempre debe quedar al menos una cuenta de Google activa como propietaria.
- Si nadie conserva permisos para editar la política IAM de la organización, un Organization Owner puede volver a conceder Organization Administrator desde esa misma página.
Carpetas
Mecanismo opcional de agrupación entre la organización y los proyectos. Requieren una organización. Funcionan como suborganizaciones: pueden representar entidades legales, departamentos, equipos, aplicaciones o entornos (desarrollo, pruebas, producción), y permiten delegar la administración, por ejemplo dando a cada jefe de departamento la propiedad de todo lo que hay en su carpeta.
10 niveles
Profundidad máxima de anidamiento de carpetas.
300 carpetas
Máximo de carpetas hijas directas en una carpeta padre.
gcloud resource-manager folders create \ --display-name=Engineering --organization=ORGANIZATION_ID gcloud resource-manager folders create \ --display-name=Equipo-A --folder=FOLDER_ID
Google recomienda empezar con una carpeta de sandbox para experimentar qué jerarquía encaja mejor antes de crear la definitiva.
Proyectos
El proyecto es la entidad organizativa fundamental: hace falta uno para usar Google Cloud. En él se habilitan las APIs, se activa la facturación, se añaden colaboradores y se gestionan los permisos. Quien lo crea recibe el rol Owner.
| Identificador | Quién lo elige | ¿Se puede cambiar? | Reglas |
|---|---|---|---|
| Nombre del proyecto | Tú | Sí | 4 a 30 caracteres: letras, números, comillas simples, guiones, espacios o signos de exclamación |
| ID del proyecto | Tú (la consola propone uno) | No, es permanente | 6 a 30 caracteres, empieza por minúscula, solo letras ASCII, dígitos y guiones. Único global, nunca usado antes (ni por proyectos borrados). Sin cadenas como google o ssl |
| Número del proyecto | Google, automáticamente | No, de solo lectura | Numérico |
gcloud projects create PROJECT_ID --organization=ORGANIZATION_ID gcloud projects create PROJECT_ID --folder=FOLDER_ID
- No incluyas información sensible en el nombre ni en el ID: el ID aparece en el nombre de muchos otros recursos.
- Cualquiera puede crear proyectos, incluidos los usuarios de prueba gratuita. Solo los proyectos creados por usuarios de prueba o del nivel gratuito pueden quedar en la cima de su jerarquía, sin organización; se pueden migrar a una organización después.
- El número de proyectos que puede crear un usuario o cuenta de servicio está limitado. Dentro de una organización se comprueba la cuota del usuario y la de la organización: basta con que una de las dos tenga margen.
Cerrar y restaurar un proyecto
Cerrar (shut down) un proyecto detiene toda la facturación y el uso de recursos. Solo se pueden cerrar proyectos en estado ACTIVE, y hace falta el permiso resourcemanager.projects.delete.
Cierre inmediato: El proyecto queda marcado para borrado y deja de poder usarse.
Aviso: Se envía un correo a quien inició el cierre y a los contactos de la categoría Technical de Essential Contacts.
Facturación: Se desvincula la cuenta de facturación. Si se restaura el proyecto, el vínculo no vuelve automáticamente.
30 días en DELETE_REQUESTED: Los propietarios pueden restaurarlo. Durante ese tiempo sigue contando en la cuota de proyectos.
Borrado permanente: Pasados 30 días, el proyecto y todos sus recursos se eliminan sin posibilidad de recuperación.
A tener en cuenta
- Algunos servicios, como Cloud Storage y Pub/Sub, pueden borrar sus recursos mucho antes de los 30 días.
- Tras restaurar, algunos servicios tardan hasta 36 horas en volver a funcionar del todo.
- El proyecto puede seguir generando cargos hasta el final del ciclo de facturación: desactiva la facturación antes de cerrarlo.
- Si tiene descuentos por compromiso de uso (CUD) activos, Google recomienda aplicar project liens para evitar borrados accidentales.
Organization Policy Service
Da control centralizado y programático sobre cómo se pueden configurar los recursos de la organización. Sirve para poner barreras de cumplimiento sin frenar a los equipos. Casos típicos: limitar el uso compartido por dominio, limitar el uso de cuentas de servicio y restringir la ubicación física de los recursos nuevos.
IAM = quién
Autoriza quién puede realizar acciones sobre qué recursos, mediante permisos.
Organization Policy = qué
Restringe cómo se pueden configurar los recursos, sea quien sea el que lo intente.
Una restricción (constraint) es el «plano» que define qué comportamiento se controla, por ejemplo compute.storageResourceUseRestrictions. Una política de organización aplica esa restricción sobre una organización, carpeta o proyecto, y afecta a ese recurso y a todos sus descendientes. Cada política aplica exactamente una restricción, en modo activo, dry-run o ambos, y se define en YAML o JSON. El rol para administrarlas es Organization Policy Administrator (roles/orgpolicy.policyAdmin).
Tipos de restricciones
| Tipo | Quién la gestiona | Cómo funciona |
|---|---|---|
| Gestionadas (managed) | Sustituyen a las heredadas. Parámetros de lista o booleanos y compatibles con Policy Simulator. Ej.: iam.managed.disableServiceAccountCreation. | |
| Personalizadas (custom) | Tu organización | Permiten o restringen la creación y actualización de recursos de los servicios compatibles. Se aplican o no se aplican. |
| Gestionadas heredadas (legacy) | Antes llamadas predefinidas. Reglas de lista (antes list constraints) o booleanas (antes boolean constraints). |
Reglas de lista
Permiten o deniegan una lista de valores. Si solo permites ciertos valores, el resto queda denegado implícitamente. Prefijos:
is:valor exacto.under:el valor y todos sus hijos (ID de organización, carpeta o proyecto).in:todos los recursos que incluyen ese valor, p. ej.in:us-locationsengcp.resourceLocations.
Reglas booleanas
Aplicada o no aplicada. Ejemplo: compute.disableSerialPortAccess aplicada impide el acceso al puerto serie. Si la política vuelve al valor por defecto de Google, rige el comportamiento por defecto de la restricción.
Herencia, dry-run y condiciones
- Herencia: los descendientes heredan la política por defecto. Un recurso hijo puede definir su propia política que sustituya la herencia o que herede la del padre. Las políticas con restricciones heredadas (legacy) se fusionan según las reglas de evaluación jerárquica; las restricciones gestionadas no se fusionan: el hijo aplica la del padre tal cual o la sustituye.
- Dry-run: las infracciones se registran en los logs de auditoría pero no se deniegan. Sirve para medir el impacto antes de aplicar.
- Condiciones con tags: una política puede aplicarse solo a recursos con un tag concreto, por ejemplo
environment=development. - No es retroactiva (normalmente): si un recurso ya incumple una política nueva, se considera una infracción pero el servicio no se detiene; hay que corregirlo a mano. Las restricciones que sí se aplican de forma retroactiva lo indican.
- Policy Intelligence: herramientas para simular cambios, probar políticas y analizar qué recursos cubre cada una. Google recomienda probar y hacer dry-run de todos los cambios.
Security baseline de Google Cloud
Las organizaciones creadas el 3 de mayo de 2024 o después reciben automáticamente un paquete de políticas de organización aplicadas, porque la configuración abierta por defecto era vulnerable (por ejemplo, la creación de claves de cuentas de servicio).
| Política | Restricción |
|---|---|
| Desactivar la creación de claves de cuentas de servicio | iam.managed.disableServiceAccountKeyCreation |
| Desactivar la subida de claves de cuentas de servicio | iam.disableServiceAccountKeyUpload |
| Impedir que las cuentas de servicio predeterminadas reciban el rol Editor | iam.automaticIamGrantsForDefaultServiceAccounts |
| Restringir identidades por dominio | iam.allowedPolicyMemberDomains |
| Restringir contactos por dominio | essentialcontacts.managed.allowedContactDomains |
| Permitir el reenvío de protocolos solo para IP internas | compute.managed.restrictProtocolForwardingCreationForTypes |
| Acceso uniforme a nivel de bucket | storage.uniformBucketLevelAccess |
gcloud resource-manager org-policies list --organization=ORGANIZATION_ID gcloud org-policies delete iam.allowedPolicyMemberDomains --organization=ORGANIZATION_ID
Escenarios de examen
| Situación | Respuesta | Por qué |
|---|---|---|
| Que los proyectos no desaparezcan cuando el empleado que los creó deja la empresa | Tener un recurso organización | Los proyectos pertenecen a la organización, no a la persona. |
| Dar al equipo de redes acceso a todas las redes de la empresa con una sola asignación | Conceder el rol en la organización | Los roles se heredan hacia carpetas y proyectos. |
| Separar departamentos y delegar su administración | Carpetas por departamento | Las carpetas funcionan como suborganizaciones. |
| Impedir que se creen recursos fuera de la UE | Política de organización con gcp.resourceLocations | Restringe la ubicación de los recursos nuevos. |
| Probar una política antes de aplicarla sin bloquear a nadie | Modo dry-run | Registra las infracciones en auditoría sin denegar. |
| Aplicar una restricción solo a los recursos de desarrollo | Política condicional con tags | Se aplica según el tag del recurso. |
| Conservar un ID de proyecto personalizado para reutilizarlo | Borrar los recursos, no el proyecto | Un ID de proyecto nunca se puede reutilizar. |
| Recuperar un proyecto cerrado hace 10 días | Restaurarlo | Sigue en DELETE_REQUESTED durante 30 días. |
Trampas frecuentes del examen
❓ ¿Se pueden usar carpetas sin un recurso organización?
No. Las carpetas requieren una organización.
❓ ¿El Organization Administrator puede crear proyectos por defecto?
No. Por mínimo privilegio solo gestiona políticas IAM y ve la jerarquía. Necesita roles adicionales, como Project Creator o Folder Admin.
❓ ¿Se puede cambiar el ID de un proyecto?
No. El nombre se puede cambiar, el ID es permanente y no se puede reutilizar ni siquiera después de borrar el proyecto.
❓ ¿Una política de organización nueva detiene los recursos que ya la incumplen?
Normalmente no. Queda como infracción y hay que corregirla a mano, salvo en restricciones marcadas como retroactivas.
❓ ¿IAM o Organization Policy para impedir VM con IP externa a todos, incluidos los propietarios?
Organization Policy (compute.vmExternalIpAccess). IAM decide quién; la política de organización decide qué configuraciones están permitidas.
❓ ¿Los labels se heredan como los tags?
No. Las vinculaciones de tags se heredan; los labels no.
❓ ¿Un proyecto restaurado recupera su cuenta de facturación?
No automáticamente. Hay que volver a vincularla.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa quiere que ningún proyecto de su organización pueda crear recursos fuera de la Unión Europea, sin importar los permisos IAM de quien lo intente. Primero quiere comprobar qué cargas se verían afectadas sin bloquear nada. ¿Qué hace?
¿Listo para poner a prueba "Jerarquía de recursos y políticas de organización"?
Preguntas originales, cada una con su explicación.
Empezar un simulacro