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 unión específicos para políticas y permisos.
A un alto nivel, se ve así:
Una máquina virtual (llamada 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 con el soporte de GCP para sacarlos 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:
Centralizar el control para configurar restricciones sobre cómo pueden usarse los recursos de tu organización.
Definir y establecer límites para que tus 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 romper el cumplimiento.
Estas políticas pueden crearse 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, eliges 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 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 de 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 manera 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 esto significa que la única manera de averiguar qué permisos tiene un principal es preguntar a cada recurso a quién 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/primarios, que incluyen los roles de Owner, Editor y Viewer 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 según 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 adjuntados 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í.
GCP - IAM, Principals & Org Policies EnumUsuarios
En GCP console 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 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 fuertemente crear varios grupos. Si gestionas alguno de ellos, podrías haber comprometido 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 balanceadores de carga en la nube. |
| Configurar cuentas de facturación y monitorear su uso. |
| Diseñar, codificar y probar aplicaciones. |
| Establecer y gestionar políticas de seguridad para toda la organización, incluyendo la gestión de acceso y políticas de restricciones de la organización. Consulta la guía de fundamentos de seguridad de Google Cloud para más información sobre la planificación de tu infraestructura de seguridad en Google Cloud. |
| Crear o gestionar pipelines de extremo a extremo que soporten la integración y entrega continua, monitoreo y aprovisionamiento del sistema. |
| |
| |
| |
| Monitorear el gasto en proyectos. Los miembros típicos son parte del equipo de finanzas. |
| Revisar la información de recursos en toda la organización de Google Cloud. |
| Revisar la seguridad en la nube. |
| Revisar configuraciones de red. |
| Ver logs de auditoría. |
| Administrar Security Command Center. |
| Gestionar secretos en Secret Manager. |
Política de Contraseñas Predeterminada
Hacer cumplir contraseñas fuertes
Entre 8 y 100 caracteres
No reutilización
Sin expiración
Si las personas acceden a Workspace a través de un proveedor externo, 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 alcances 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 el alcance de https://www.googleapis.com/auth/compute.readonly. Esto te impediría hacer cambios 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 custom service accounts, que se verán así:
Access scopes
Los alcances de acceso están adjuntos a los tokens OAuth generados para acceder a los endpoints 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 para acceder a ese recurso, el token no puede ser usado para (ab)usar esos privilegios.
Google en realidad recomienda que no se usen los alcances de acceso y se confíe totalmente en IAM. El portal de gestión web en realidad refuerza esto, pero los alcances de acceso aún pueden aplicarse a instancias usando 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 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:
Terraform IAM Policies, Bindings and Memberships
Como se define en terraform en https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam usando terraform con GCP hay diferentes maneras de otorgar acceso a un principal sobre un recurso:
Memberships: Se establecen principals como miembros de roles sin restricciones sobre el rol o los principals. 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 principals (usuario y grupo) como miembros de otros roles.
Bindings: Varios principals pueden ser vinculados a un rol. Esos principals aún pueden ser 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á.
Policies: Una política es autoritativa, indica roles y principals y luego, esos principals no pueden tener más roles y esos roles no pueden tener más principals a menos que esa política sea modificada (ni siquiera en otras políticas, bindings o memberships). Por lo tanto, cuando un rol o principal se especifica en una política, todos sus privilegios están limitados por esa política. Obviamente, esto se puede eludir en caso de que al principal se le dé la opción de modificar la política o permisos de escalación de privilegios (como crear un nuevo principal y vincularle un nuevo rol).
Referencias
Last updated
