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 conexión específicos para políticas y permisos.
A un alto nivel, se ve así:
Una máquina virtual (llamada una Instancia de Cómputo) es un recurso. Un recurso reside en un proyecto, probablemente junto con otras Instancias de Cómputo, 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 moverlos fuera de la organización primero. Para más información, consulta este enlace.
Políticas de Organización
Permiten centralizar el control sobre los recursos en la nube de tu organización:
Centralizar el control para configurar restricciones sobre cómo pueden ser utilizados los recursos de tu organización.
Definir y establecer límites para que los equipos de desarrollo se mantengan dentro de los límites de cumplimiento.
Ayudar a los propietarios de proyectos y sus equipos a moverse rápidamente sin preocuparse por incumplir el cumplimiento.
Estas políticas pueden ser creadas para afectar a toda la organización, carpeta(s) o proyecto(s). Los descendientes del nodo de jerarquía de recursos objetivo heredan la política de la organización.
Para definir una política de organización, se elige una restricción, 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 las restricciones deseadas.
Casos de uso comunes
Limitar el intercambio de recursos basado en dominio.
Limitar el uso de cuentas de servicio de Identidad y Acceso.
Restringir la ubicación física de los recursos recién creados.
Deshabilitar la creación de cuentas de servicio.
Existen muchas más restricciones que te brindan 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 otorgan roles de acceso X a principios Y, y la única forma de averiguar quién tiene acceso a un recurso es utilizar el método get-iam-policy sobre ese recurso.
Esto podría ser un problema porque esto significa que la única forma de averiguar qué permisos tiene un principio es preguntar a cada recurso a quién está otorgando 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 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.
Existen 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 SA debido a algunos permisos que contienen. Además, ten en cuenta que los permisos solo tendrán efecto si están asignados al servicio relevante.
O verifica si un rol personalizado puede usar un permiso específico aquí.
pageGCP - IAM, Principals & Org Policies EnumUsuarios
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 forzado a los usuarios de Workspaces, sin embargo, un atacante podría usar un token para acceder a GCP a través de la CLI que no estará protegido por MFA (solo estará protegido por MFA cuando el usuario inicie sesión para generarlo: gcloud auth login).
Grupos
Cuando se crea una organización, se sugiere crear varios grupos. Si administras alguno de ellos, podrías comprometer toda o una parte importante de la organización:
Grupo | Función |
| Administrar cualquier recurso que pertenezca a la organización. Asigna este rol con moderación; los administradores de la organización tienen acceso a todos tus recursos de Google Cloud. Alternativamente, debido a que esta función es altamente privilegiada, considera usar cuentas individuales en lugar de crear un grupo. |
| Crear redes, subredes, reglas de firewall y dispositivos de red como Cloud Router, Cloud VPN y equilibradores de carga en la nube. |
| Configurar cuentas de facturación y monitorear su uso. |
| Diseñar, codificar y probar aplicaciones. |
| Establecer y administrar políticas de seguridad para toda la organización, incluido el manejo de accesos y políticas de restricción de organización. Consulta la guía de fundamentos de seguridad de Google Cloud para obtener más información sobre la planificación de la infraestructura de seguridad de Google Cloud. |
| Crear o administrar flujos de trabajo de extremo a extremo que admitan la integración y entrega continuas, monitoreo y aprovisionamiento de sistemas. |
| |
| |
| |
| Monitorear el gasto en proyectos. Los miembros típicos son parte del equipo financiero. |
| Revisar información de recursos en toda la organización de Google Cloud. |
| Revisar la seguridad en la nube. |
| Revisar configuraciones de red. |
| Ver registros de auditoría. |
| Administrar Security Command Center. |
| Administrar secretos en Secret Manager. |
Política de Contraseña por Defecto
Imponer contraseñas fuertes
Entre 8 y 100 caracteres
No reutilización
Sin caducidad
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 principios a los que los recursos pueden estar adjuntos y acceder 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 alcances de acceso. Por ejemplo, tu cuenta de servicio puede tener el rol IAM de compute.instanceAdmin pero la instancia a la que has accedido ha sido limitada con el alcance de https://www.googleapis.com/auth/compute.readonly. Esto te impediría realizar cambios utilizando el token OAuth que se asigna automáticamente a tu instancia.
Es similar a los roles IAM de AWS. Pero a diferencia de AWS, cualquier cuenta de servicio puede ser adjuntada a cualquier servicio (no es necesario permitirlo mediante 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 los recursos cuentas de servicio personalizadas, que se verán así:
Alcances de acceso
Los alcances de acceso están adjuntos a los tokens de OAuth generados para acceder a los puntos finales de la API de GCP. Estos restringen los permisos del token de OAuth. Esto significa que si un token pertenece a un Propietario de un recurso pero no tiene en el alcance del token el acceso a ese recurso, el token no se puede utilizar para (ab)usar esos privilegios.
Google realmente recomienda que los alcances de acceso no se utilicen y se confíe totalmente en IAM. El portal de gestión web realmente hace cumplir esto, pero los alcances de acceso aún se pueden aplicar a las instancias utilizando cuentas de servicio personalizadas de forma programática.
Puedes ver qué alcances están asignados mediante consulta:
Los alcances anteriores son los generados por defecto al usar gcloud para acceder a los datos. Esto se debe a que al usar gcloud primero se crea un token de OAuth y luego se utiliza para contactar los puntos finales.
El alcance más importante de esos potencialmente es cloud-platform, lo 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 de IAM, Vínculos y Miembros de Terraform
Según lo definido por 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:
Miembros: Estableces principales como miembros de roles sin restricciones sobre el rol o los principales. Puedes poner un usuario como miembro de un rol y luego poner un grupo como miembro del mismo rol y también establecer esos principales (usuario y grupo) como miembros de otros roles.
Vínculos: 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 es establecido como miembro de un rol vinculado, la próxima vez que se aplique el vínculo, 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, vínculos o membresías). Por lo tanto, cuando se especifica un rol o principal en una 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 vincularle un nuevo rol).
Referencias
Última actualización
