GCP - Basic Information
Jerarquía de recursos
Google Cloud utiliza una Jerarquía de recursos que es similar, conceptualmente, a la de un sistema de archivos tradicional. Esto proporciona un flujo de trabajo lógico de padre/hijo con puntos de adjunto específicos para políticas y permisos.
A un alto nivel, se ve así:
Una máquina virtual (llamada una Compute Instance) es un recurso. Un recurso reside en un proyecto, probablemente junto a otras Compute Instances, buckets de almacenamiento, etc.
Migración de Proyectos
Es posible migrar un proyecto sin ninguna organización a una organización con los permisos roles/resourcemanager.projectCreator y roles/resourcemanager.projectMover. Si el proyecto está dentro de otra organización, es necesario contactar al soporte de GCP para moverlo fuera de la organización primero. Para más información, consulta esto.
Políticas de Organización
Permiten centralizar el control sobre los recursos en la nube de tu organización:
Centraliza el control para configurar restricciones sobre cómo se pueden usar los recursos de tu organización.
Define y establece guardrails para que tus equipos de desarrollo se mantengan dentro de los límites de cumplimiento.
Ayuda a los propietarios de proyectos y sus equipos a moverse rápidamente sin preocuparse por romper el cumplimiento.
Estas políticas pueden ser creadas para afectar a la organización completa, carpeta(s) o proyecto(s). Los descendientes del nodo de jerarquía de recursos objetivo heredan la política de organización.
Para definir una política de organización, eliges un constraint, que es un tipo particular de restricción contra un servicio de Google Cloud o un grupo de servicios de Google Cloud. Configuras esa restricción con tus restricciones deseadas.
Casos de uso comunes
Limitar el uso compartido de recursos según el dominio.
Limitar el uso de cuentas de servicio de Identity and Access Management.
Restringir la ubicación física de los recursos recién creados.
Deshabilitar la creación de cuentas de servicio.
Hay muchas más restricciones que te dan un control detallado sobre los recursos de tu organización. Para más información, consulta la lista de todas las restricciones del Servicio de Políticas de Organización.
Políticas de Organización Predeterminadas
Roles de IAM
Estos son como las políticas de IAM en AWS ya que cada rol contiene un conjunto de permisos.
Sin embargo, a diferencia de AWS, no hay un repositorio centralizado de roles. En lugar de eso, los recursos dan X roles de acceso a Y principales, y la única forma de averiguar quién tiene acceso a un recurso es usar el método get-iam-policy sobre ese recurso.
Esto podría ser un problema porque significa que la única forma de averiguar qué permisos tiene un principal es preguntar a cada recurso a quién le está dando permisos, y un usuario podría no tener permisos para obtener permisos de todos los recursos.
Hay tres tipos de roles en IAM:
Roles Básicos/Primitivos, que incluyen los roles de Propietario, Editor y Visualizador que existían antes de la introducción de IAM.
Roles Predefinidos, que proporcionan acceso granular para un servicio específico y son gestionados por Google Cloud. Hay muchos roles predefinidos, puedes ver todos ellos con los privilegios que tienen aquí.
Roles Personalizados, que proporcionan acceso granular de acuerdo a una lista de permisos especificada por el usuario.
Hay miles de permisos en GCP. Para verificar si un rol tiene un permiso, puedes buscar el permiso aquí y ver qué roles lo tienen.
También puedes buscar aquí roles predefinidos ofrecidos por cada producto. Ten en cuenta que algunos roles no pueden ser asignados a usuarios y solo a SAs debido a algunos permisos que contienen. Además, ten en cuenta que los permisos solo tendrán efecto si están adjuntos al servicio relevante.
O verifica si un rol personalizado puede usar un permiso específico aquí.
Usuarios
En la consola de GCP no hay gestión de Usuarios o Grupos, eso se hace en Google Workspace. Aunque podrías sincronizar un proveedor de identidad diferente en Google Workspace.
Puedes acceder a los usuarios y grupos de Workspaces en https://admin.google.com.
MFA puede ser forzada a los usuarios de Workspaces, sin embargo, un atacante podría usar un token para acceder a GCP a través de cli que no estará protegido por MFA (estará protegido por MFA solo cuando el usuario inicie sesión para generarlo: gcloud auth login).
Grupos
Cuando se crea una organización, se sugiere encarecidamente crear varios grupos. Si gestionas alguno de ellos, podrías haber comprometido toda o una parte importante de la organización:
Política de Contraseñas Predeterminada
Hacer cumplir contraseñas fuertes
Entre 8 y 100 caracteres
Sin reutilización
Sin expiración
Si las personas acceden a Workspace a través de un proveedor de terceros, estos requisitos no se aplican.
Cuentas de servicio
Estos son los principales que los recursos pueden tener adjuntos y acceso para interactuar fácilmente con GCP. Por ejemplo, es posible acceder al token de autenticación de una Cuenta de Servicio adjunta a una VM en los metadatos.
Es posible encontrar algunos conflictos al usar tanto IAM como scopes de acceso. Por ejemplo, tu cuenta de servicio puede tener el rol de IAM de compute.instanceAdmin, pero la instancia que has comprometido ha sido limitada con la restricción de scope de https://www.googleapis.com/auth/compute.readonly. Esto te impediría hacer cualquier cambio usando el token OAuth que se asigna automáticamente a tu instancia.
Es similar a los roles de IAM de AWS. Pero a diferencia de AWS, cualquier cuenta de servicio puede ser adjunta a cualquier servicio (no necesita permitirlo a través de una política).
Varias de las cuentas de servicio que encontrarás son en realidad generadas automáticamente por GCP cuando comienzas a usar un servicio, como:
Sin embargo, también es posible crear y adjuntar a recursos cuentas de servicio personalizadas, que se verán así:
Claves y Tokens
Hay 2 formas principales de acceder a GCP como una cuenta de servicio:
A través de tokens OAuth: Estos son tokens que obtendrás de lugares como puntos finales de metadatos o robando solicitudes http y están limitados por los alcances de acceso.
Claves: Estos son pares de claves públicas y privadas que te permitirán firmar solicitudes como la cuenta de servicio e incluso generar tokens OAuth para realizar acciones como la cuenta de servicio. Estas claves son peligrosas porque son más complicadas de limitar y controlar, por eso GCP recomienda no generarlas.
Ten en cuenta que cada vez que se crea una SA, GCP genera una clave para la cuenta de servicio a la que el usuario no puede acceder (y no se listará en la aplicación web). Según este hilo, esta clave es utilizada internamente por GCP para dar acceso a los puntos finales de metadatos para generar los tokens OAuth accesibles.
Alcances de acceso
Los alcances de acceso están adjuntos a los tokens OAuth generados para acceder a los puntos finales de la API de GCP. Restringen los permisos del token OAuth. Esto significa que si un token pertenece a un Propietario de un recurso pero no tiene en el alcance del token acceso a ese recurso, el token no puede ser utilizado para (ab)usar esos privilegios.
Google en realidad recomienda que no se utilicen alcances de acceso y se confíe totalmente en IAM. El portal de gestión web en realidad hace cumplir esto, pero los alcances de acceso aún se pueden aplicar a instancias utilizando cuentas de servicio personalizadas programáticamente.
Puedes ver qué alcances están asignados consultando:
Los alcances anteriores son los generados por defecto usando gcloud para acceder a datos. Esto se debe a que cuando usas gcloud primero creas un token de OAuth y luego lo usas para contactar los endpoints.
El alcance más importante de esos potencialmente es cloud-platform, que básicamente significa que es posible acceder a cualquier servicio en GCP.
Puedes encontrar una lista de todos los posibles alcances aquí.
Si tienes credenciales de navegador de gcloud, es posible obtener un token con otros alcances, haciendo algo como:
Políticas, Vinculaciones y Membresías de IAM de Terraform
Como se define en terraform en https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam, al usar terraform con GCP hay diferentes formas de otorgar acceso a un principal sobre un recurso:
Membresías: Se establecen principales como miembros de roles sin restricciones sobre el rol o los principales. Puedes poner a un usuario como miembro de un rol y luego poner a un grupo como miembro del mismo rol y también establecer esos principales (usuario y grupo) como miembros de otros roles.
Vinculaciones: Varios principales pueden estar vinculados a un rol. Esos principales aún pueden estar vinculados o ser miembros de otros roles. Sin embargo, si un principal que no está vinculado al rol se establece como miembro de un rol vinculado, la próxima vez que se aplique la vinculación, la membresía desaparecerá.
Políticas: Una política es autoritativa, indica roles y principales y luego, esos principales no pueden tener más roles y esos roles no pueden tener más principales a menos que esa política sea modificada (ni siquiera en otras políticas, vinculaciones o membresías). Por lo tanto, cuando un rol o principal se especifica en la política, todos sus privilegios están limitados por esa política. Obviamente, esto puede ser eludido en caso de que al principal se le dé la opción de modificar la política o permisos de escalada de privilegios (como crear un nuevo principal y vincularlo a un nuevo rol).
Referencias
Last updated
