Google Cloud IAM – Roles y Permisos

por | 08/08/2018

Cuando alguien (usuario, grupo o cuenta de servicio) quiere acceder a una API o recurso de Google Cloud, IAM debe comprobar si tiene los permisos necesarios para hacerlo. Los permisos no se otorgan directamente a los usuarios sino que se realiza mediante la asignación de roles, que son un conjunto de permisos.

Tipos de roles

  • Primitivos: antes de la existencia de IAM, existían  los siguientes 3 roles: owner, editor y viewer.
  • Predefinidos: gestionados por GCP, permitiendo un acceso granular para un determinado servicio.
  • Personalizado: definido por el usuario, de forma granular con los permisos requeridos.
Roles Primitivos

roles/viewer: permiso para realizar acciones de solo lectura, no permite realizar ningún cambio.

roles/editor: incluye los permisos de viewer, y además incluye permisos para modificar, crear y borrar en la mayoría de los servicios (hay algunas excepciones).

roles/owner: incluye los permisos de editor, y además permite gestionar roles y permisos, y además configurar la parte de facturación del proyecto.

El rol de owner solo se puede otorgar mediante la consola GCP, no es posible hacerlo mediante API o la shell de gcloud.

Roles Predefinidos

Existe una extensa lista de roles predefinidos, que nos permiten asignar permisos de forma granular dependiendo de las necesidades de cada usuario/aplicación a cada uno de los recursos, proyectos, …

Los roles están definidos por Proyecto (ej: roles/brower), o servicios como App Engine (ej: roles/appengine.deployer), BigQuery (ej: roles/bigquery.dataViewer), Billing (ej: roles/billing.viewer), Cloud Storage (ej: roles/storage.objectAdmin),  Compute Engine (ej: roles/compute.networkAdmin) o Stackdriver (roles/monitoring.editor).

Roles personalizados

Los roles personalizados se basan en agrupar una serie de permisos en la definición del rol. Estos permisos tienen una definición como la siguiente:

<servicio>.<recurso>.<accion>

Esto son algunos ejemplos:

  • appengine.instances.update
  • datastore.namespaces.list
  • compute.address.*

Cuando se crea un nuevo rol, hay que seguir una serie de recomendaciones:

  • Revisar si uno de los roles predefinidos se adapta a las necesidades, para evitar crear roles iguales
  • Algunos permisos tienen dependencias. Por ejemplo, para tener permiso de actualización sobre una Policy (setIamPolicy) es necesario tener el permiso de lectura previamente (getIamPolicy).
  • El ID debe ser único, el nombre no.
  • Existe una propiedad del rol para identificar el entorno al que aplica: role.stage. Esta misma propiedad se utiliza para deshabilitarlo asignándole el valor DEPRECATED.

Más información sobre roles personalizados en Google Cloud.

Principio de menor privilegio

  • Los roles predefinidos proporcionan permiso más granular que los roles primitivos. Se deben utilizar roles predefinidos siempre que sea posible.
  • Los roles primitivos solo se deben utilizar cuando no hay un rol predefinido, cuando se requieren permisos más amplios para un proyecto (ej: desarrollo o test), cuando un usuario debe modificar permisos de un proyecto o cuando no se necesitan permisos granulares (ej: equipos muy pequeños de trabajo).
  • Cada servicio de un aplicativo, debe utilizar una cuenta de servicio diferente y se deben asignar roles específicos a cada uno de ellos.
  • Una política aplicada en un recurso no se puede limitar en sus recursos superiores en la jerarquía de recursos de GCP.
  • Asigna permisos al ámbito más limitado posible para cada usuario.
  • Restringe los usuarios con permisos sobre las cuentas de servicio.
  • Restringe quién puede crear y gestionar cuentas de servicio en cada proyecto.
  • El rol de owner puede modificar la política de IAM, por lo que este rol debe asignarse de manera muy muy controlada.

Modificar roles de usuarios

Hay varias formas de modificar los permisos/roles de usuarios de un proyecto para añadir, quitar o modificar permisos.

Se puede hacer obteniendo la política del proyecto:

gcloud projects get-iam-policy PROYECTO_A --format json > policy.json

Y después de haber hecho los cambios correspondientes al fichero JSON, se actualiza la política del proyecto:

gcloud projects set-iam-policy PROYECTO_A policy.json

Pero también podemos añadir un nuevo binding para un usuario en concreto:

gcloud projects add-iam-policy-binding PROYECTO_A --member user:[email protected] --role roles/editor

Para eliminar permisos a un usuario, lo podemos hacer así:

gcloud projects remove-iam-policy-binding PROYECTO_A --member user:[email protected] --role roles/editor

Entradas relacionadas

Google Cloud IAM – Introducción Este servicio está basado en dos características básicas que permiten controlar usuarios y accesos a cada uno de los recursos de Google Cloud: ...
Google Cloud Resource Manager – Jerarquía de... Cuando trabajamos con la plataforma de Google Cloud, necesitamos organizar todos los recursos, usuarios, proyectos, ... y para ello debemos basarnos e...

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.