Cómo asignar roles IAM en Google Cloud

Asignar permisos IAM en Google Cloud define quién puede hacer qué dentro de tu proyecto. Aquí aprendes a otorgar acceso a usuarios, grupos y cuentas de servicio aplicando el principio de mínimo privilegio, evitando roles primarios y priorizando los predefinidos para mantener una administración segura y sostenible.

¿Qué tipos de roles existen en Google Cloud IAM?

Google Cloud organiza los permisos en tres categorías, y elegir bien entre ellas marca la diferencia entre un proyecto seguro y uno lleno de baches.

• Roles primarios (básicos): propietario, editor, visualizador y navegador. Aplican a todo el proyecto y conviene evitarlos porque chocan con el mínimo privilegio.
• Roles predefinidos: dan acceso a recursos específicos como máquinas virtuales o bases de datos. Son los más recomendados para la mayoría de proyectos.
• Roles personalizados: los creas tú asignando endpoint por endpoint los permisos asociados a las API. Útiles en casos puntuales, pero costosos de mantener.

¿Cuál es la diferencia entre un rol predefinido y uno personalizado? El predefinido lo mantiene Google y se actualiza solo cuando salen nuevas funciones. El personalizado lo administras tú y debes agregar manualmente los nuevos endpoints cada vez que cambien las APIs.

¿Por qué evitar los roles primarios y los personalizados?

La tentación de dar acceso de editor o propietario es alta porque resuelve rápido, pero rompe la seguridad. Lo mismo pasa con la complejidad excesiva en roles personalizados: lo que hoy parece flexible, mañana es un dolor de cabeza.

¿Qué buenas prácticas seguir al asignar permisos?

• Usa roles predefinidos siempre que sea posible.
• Recuerda que la complejidad no es amiga de la mantenibilidad.
• Evita los roles primarios para no violar el principio de mínimo privilegio.
• Considera que los roles personalizados requieren administración constante.

Un ejemplo claro: si asignas Compute Network Admin, que es un rol predefinido, y Google lanza una nueva característica de networking, ese permiso se actualiza automáticamente. En cambio, con un rol personalizado, tú tienes que agregar cada nuevo endpoint a mano.

¿Cómo otorgar acceso a un grupo desde IAM?

Antes de asignar nada, verifica que estés con la cuenta correcta y dentro del proyecto correspondiente. Desde ahí el flujo es directo.

1. Ve al menú principal y entra a IAM y Administración.
2. Selecciona la opción IAM, donde se listan los permisos del proyecto y los heredados desde carpeta u organización.
3. Haz clic en Otorgar acceso.
4. En Principales nuevas, ingresa el correo del grupo previamente creado.
5. En Seleccionar rol, navega hasta encontrar el rol deseado.

Para este ejemplo se asocia el rol administrador de Compute, que permite crear máquinas virtuales. Puedes agregar más de un permiso usando la lupa, y también aplicar condiciones como restricciones de tiempo. Luego das clic en Guardar.

¿Qué hace el rol administrador de Compute? Otorga permisos para crear, modificar y administrar máquinas virtuales dentro del proyecto, sin dar acceso a otros recursos como bases de datos o redes.

¿Cómo asignar permisos a una cuenta de servicio?

Las cuentas de servicio también necesitan permisos para operar, y se asignan igual que a un usuario, pero con una particularidad: necesitas su correo identificador.

• Entra a Cuentas de servicio desde el mismo menú IAM.
• Copia el identificador (correo) de la cuenta de servicio.
• Vuelve a IAM y haz clic en Otorgar acceso.
• Pega el correo en Principales nuevas.
• Selecciona un rol, en este caso visualizador, que permite ver todo el proyecto sin modificarlo.
• Guarda los cambios.

Al final, no importa si la identidad es un usuario como Admin, un grupo como Developers o una cuenta de servicio: todas aparecen listadas en IAM. Lo que cambia es el tipo de identidad detrás del permiso.

¿Qué son las cuentas de servicio gestionadas por Google?

Cuando habilitas servicios como Compute Engine o Kubernetes Engine, Google crea cuentas de servicio propias por detrás. Esas cuentas asignan permisos automáticamente para que cada recurso funcione a nombre de ellas, sin que tú las configures manualmente. Las verás en acción cuando trabajes con máquinas virtuales y clústeres de Kubernetes.

¿Qué rol predefinido aplicarías tú primero en tu proyecto? Cuéntame en los comentarios cómo estás organizando los permisos de tu equipo.