Cuando añades un nuevo miembro a tu proyecto, puedes usar una política de gestión de identidades y accesos (IAM) para asignarle uno o varios roles de IAM. Cada rol de gestión de identidades y accesos contiene permisos que conceden al miembro acceso a recursos específicos.
Compute Engine tiene un conjunto de roles de gestión de identidades y accesos predefinidos que se describen en esta página. También puedes crear roles personalizados que contengan subconjuntos de permisos que se ajusten directamente a tus necesidades.
Para saber qué permisos se necesitan para cada método, consulta la documentación de referencia de la API Compute Engine:
Para obtener información sobre cómo conceder acceso, consulta las siguientes páginas.
- Para definir políticas de gestión de identidades y accesos a nivel de proyecto, consulta el artículo Gestionar el acceso a proyectos, carpetas y organizaciones de la documentación de IAM.
- Para definir políticas en recursos específicos de Compute Engine, consulta Conceder acceso a recursos de Compute Engine.
- Para asignar roles a una cuenta de servicio de Compute Engine, consulta el artículo Crear una VM que use una cuenta de servicio gestionada por el usuario.
¿Qué es IAM?
Google Cloud ofrece IAM, que te permite dar un acceso más granular a recursos específicosGoogle Cloud y evita el acceso no deseado a otros recursos. IAM te permite adoptar el principio de seguridad de mínimos accesos, por lo que solo concedes el acceso necesario a tus recursos.
La gestión de identidades y accesos te permite controlar quién (identidad) tiene qué (roles) permiso para acceder a qué recursos mediante la configuración de políticas de gestión de identidades y accesos. Las políticas de gestión de identidades y accesos conceden roles específicos a un miembro del proyecto, lo que otorga a esa identidad determinados permisos. Por ejemplo, en el caso de un recurso concreto, como un proyecto, puedes asignar el rol Administrador de red de Compute (roles/compute.networkAdmin) a una cuenta de usuario (una cuenta de Google o una cuenta de un proveedor de identidades externo). Esta cuenta puede controlar los recursos relacionados con la red del proyecto, pero no puede gestionar otros recursos, como instancias y discos. También puedes usar IAM para gestionar los Google Cloud roles antiguos de la consola
asignados a los miembros del equipo del proyecto.
Rol serviceAccountUser
Si se concede junto con el rol Administrador de instancias de Compute (v. 1) (roles/compute.instanceAdmin.v1), el rol Usuario de cuenta de servicio (roles/iam.serviceAccountUser) permite a los miembros crear y gestionar instancias que usen una cuenta de servicio. En concreto, si se conceden los permisos roles/iam.serviceAccountUser y roles/compute.instanceAdmin.v1
a la vez, los miembros podrán hacer lo siguiente:
- Crea una instancia que se ejecute como una cuenta de servicio.
- Acopla un disco persistente a una instancia que se ejecute como cuenta de servicio.
- Definir metadatos de instancia en una instancia que se ejecuta como cuenta de servicio.
- Usa SSH para conectarte a una instancia que se ejecuta como cuenta de servicio.
- Reconfigura una instancia para que se ejecute como una cuenta de servicio.
Puedes asignar el rol Usuario de cuenta de servicio (roles/iam.serviceAccountUser) de dos formas:
Recomendado. Asigna el rol a un miembro de una cuenta de servicio específica. De esta forma, un miembro puede acceder a la cuenta de servicio de la que es
iam.serviceAccountUser, pero no a otras cuentas de servicio de las que no lo sea.iam.serviceAccountUserAsigna el rol a un miembro a nivel de proyecto. El miembro tiene acceso a todas las cuentas de servicio del proyecto, incluidas las que se creen en el futuro.
Si no conoces las cuentas de servicio, consulta más información sobre ellas.
Permiso de la consola deGoogle Cloud
Para usar la Google Cloud console para acceder a los recursos de Compute Engine, debes tener un rol que incluya el siguiente permiso en el proyecto:
compute.projects.get
Conectarse a una instancia como instanceAdmin
Después de asignar el rol roles/compute.instanceAdmin.v1 a un miembro del proyecto, este podrá conectarse a instancias de máquina virtual (VM) mediante herramientas estándar, como la CLI de gcloud o SSH en el navegador. Google Cloud
Cuando un miembro usa la CLI de gcloud o SSH en el navegador, las herramientas generan automáticamente un par de claves pública y privada, y añaden la clave pública a los metadatos del proyecto. Si el miembro no tiene permisos para editar los metadatos del proyecto, la herramienta añade la clave pública del miembro a los metadatos de la instancia.
Si el miembro tiene un par de claves que quiere usar, puede añadir manualmente su clave pública a los metadatos de la instancia. Más información sobre cómo añadir claves SSH a una instancia
Gestión de identidades y accesos con cuentas de servicio
Crea cuentas de servicio personalizadas y concede roles de gestión de identidades y accesos a las cuentas de servicio para limitar el acceso de tus instancias. Usa roles de gestión de identidades y accesos con cuentas de servicio personalizadas para hacer lo siguiente:
- Limita el acceso que tienen tus instancias a las APIs mediante roles de gestión de identidades y accesos granulares. Google Cloud
- Asigne una identidad única a cada instancia o conjunto de instancias.
- Limita el acceso de tu cuenta de servicio predeterminada.
Más información sobre las cuentas de servicio
Grupos de instancias gestionados y gestión de identidades y accesos
Los grupos de instancias gestionadas (MIGs) son recursos que realizan acciones en tu nombre sin que los usuarios tengan que intervenir directamente. Por ejemplo, la MIG puede añadir y quitar VMs del grupo.
Todas las operaciones que realiza Compute Engine como parte del MIG las lleva a cabo el agente de servicio de las APIs de Google de tu proyecto, que tiene una dirección de correo como la siguiente:
PROJECT_ID@cloudservices.gserviceaccount.com
De forma predeterminada, el agente de servicio de las APIs de Google tiene el rol Editor (roles/editor) a nivel de proyecto, lo que le otorga los privilegios suficientes para crear recursos en función de la configuración del MIG. Si vas a personalizar el acceso del agente de servicio de las APIs de Google, asigna el rol Administrador de instancias de Compute (v. 1) (roles/compute.instanceAdmin.v1) y, opcionalmente, el rol Usuario de cuenta de servicio (roles/iam.serviceAccountUser). El rol Usuario de cuenta de servicio solo es necesario si el MIG crea VMs que pueden ejecutarse como una cuenta de servicio.
Ten en cuenta que el agente de servicio de las APIs de Google también se usa en otros procesos, como Deployment Manager.
Cuando creas un MIG o actualizas su plantilla de instancia, Compute Engine comprueba que el agente de servicio de las APIs de Google tiene el siguiente rol y los siguientes permisos:
- Rol Usuario de cuenta de servicio, que es importante si tienes previsto crear instancias que puedan ejecutarse como una cuenta de servicio
- Permisos para todos los recursos a los que se hace referencia desde las plantillas de instancia, como imágenes, discos, redes de VPC y subredes
Roles de gestión de identidades y accesos de Compute Engine predefinidos
Con la gestión de identidades y accesos, todos los métodos de la API de Compute Engine requieren que la identidad que hace la solicitud a la API tenga los permisos adecuados para usar el recurso. Los permisos se conceden configurando políticas que asignan roles a un miembro (usuario, grupo o cuenta de servicio) de tu proyecto.
Además de los roles básicos (lector, editor y propietario) y los roles personalizados, puedes asignar los siguientes roles predefinidos de Compute Engine a los miembros de tu proyecto.
Puedes asignar varios roles a un miembro del proyecto en el mismo recurso. Por ejemplo, si tu equipo de redes también gestiona las reglas del cortafuegos, puedes conceder roles/compute.networkAdmin y roles/compute.securityAdmin al grupo de Google del equipo de redes.
En las siguientes tablas se describen los roles de gestión de identidades y accesos de Compute Engine predefinidos, así como los permisos que contiene cada rol. Cada rol contiene un conjunto de permisos adecuado para una tarea específica. Por ejemplo, los roles InstanceAdmin conceden permisos para gestionar instancias, los roles relacionados con la red incluyen permisos para gestionar recursos relacionados con la red y el rol de seguridad incluye permisos para gestionar recursos relacionados con la seguridad, como cortafuegos y certificados SSL. Cuando trabajes en Compute Engine, es posible que también necesites roles para otros servicios, como Cloud DNS y cuentas de servicio de IAM. Para ver una lista completa de los roles de gestión de identidades y accesos, consulta la documentación de referencia de los roles de gestión de identidades y accesos.
| Role | Permissions |
|---|---|
Compute Admin( Full control of all Compute Engine resources.
If the user will be managing virtual machine instances that are configured
to run as a service account, you must also grant the
Lowest-level resources where you can grant this role:
|
|
Compute Future Reservation Admin Beta(
|
|
Compute Future Reservation User Beta(
|
|
Compute Future Reservation Viewer Beta(
|
|
Compute Image User( Permission to list and read images without having other permissions on the image. Granting this role at the project level gives users the ability to list all images in the project and create resources, such as instances and persistent disks, based on images in the project. Lowest-level resources where you can grant this role:
|
|
Compute Instance Admin (beta)( Permissions to create, modify, and delete virtual machine instances. This includes permissions to create, modify, and delete disks, and also to configure Shielded VM settings.
If the user will be managing virtual machine instances that are configured
to run as a service account, you must also grant the
For example, if your company has someone who manages groups of virtual machine instances but does not manage network or security settings and does not manage instances that run as service accounts, you can grant this role on the organization, folder, or project that contains the instances, or you can grant it on individual instances. Lowest-level resources where you can grant this role:
|
|
Compute Instance Admin (v1)( Full control of Compute Engine instances, instance groups, disks, snapshots, and images. Read access to all Compute Engine networking resources. If you grant a user this role only at an instance level, then that user cannot create new instances. |
|
Instance Group Manager Service Agent( Role containing all permissions required by Managed Instance Groups to create and manage instances. |
|
Interconnect Attachment Group Analyzer( Analyze Interconnect Attachment Groups via their GetOperationalStatus method. |
|
Interconnect Group Analyzer( Analyze Interconnect Groups via their GetOperationalStatus method. |
|
Compute Load Balancer Admin( Permissions to create, modify, and delete load balancers and associate resources. For example, if your company has a load balancing team that manages load balancers, SSL certificates for load balancers, SSL policies, and other load balancing resources, and a separate networking team that manages the rest of the networking resources, then grant this role to the load balancing team's group. Lowest-level resources where you can grant this role:
|
|
Compute Load Balancer Services User( Permissions to use services from a load balancer in other projects. |
|
Compute Network Admin( Permissions to create, modify, and delete networking resources, except for firewall rules and SSL certificates. The network admin role allows read-only access to firewall rules, SSL certificates, and instances (to view their ephemeral IP addresses). The network admin role does not allow a user to create, start, stop, or delete instances.
For example, if your company has a security team that manages firewalls
and SSL certificates and a networking team that manages the rest of the
networking resources, then grant this role to the networking team's group.
Or, if you have a combined team that manages both security and networking,
then grant this role as well as the
Lowest-level resources where you can grant this role:
|
|
Compute Network User( Provides access to a shared VPC network Once granted, service owners can use VPC networks and subnets that belong to the host project. For example, a network user can create a VM instance that belongs to a host project network but they cannot delete or create new networks in the host project. Lowest-level resources where you can grant this role:
|
|
Compute Network Viewer( Read-only access to all networking resources For example, if you have software that inspects your network configuration, you could grant this role to that software's service account. Lowest-level resources where you can grant this role:
|
|
Compute Organization Firewall Policy Admin( Full control of Compute Engine Organization Firewall Policies. |
|
Compute Organization Firewall Policy User( View or use Compute Engine Firewall Policies to associate with the organization or folders. |
|
Compute Organization Security Policy Admin( Full control of Compute Engine Organization Security Policies. |
|
Compute Organization Security Policy User( View or use Compute Engine Security Policies to associate with the organization or folders. |
|
Compute Organization Resource Admin( Full control of Compute Engine Firewall Policy associations to the organization or folders. |
|
Compute OS Admin Login( Access to log in to a Compute Engine instance as an administrator user. Lowest-level resources where you can grant this role:
|
|
Compute OS Login( Access to log in to a Compute Engine instance as a standard user. Lowest-level resources where you can grant this role:
|
|
Compute OS Login External User( Available only at the organization level. Access for an external user to set OS Login information associated with this organization. This role does not grant access to instances. External users must be granted one of the required OS Login roles in order to allow access to instances using SSH. Lowest-level resources where you can grant this role:
|
|
Compute packet mirroring admin( Specify resources to be mirrored. |
|
Compute packet mirroring user( Use Compute Engine packet mirrorings. |
|
Compute Peer Subnet Migration Admin( Use subnetwork whose PURPOSE is "PEER_MIGRATION" |
|
Compute Public IP Admin( Full control of public IP address management for Compute Engine. |
|
Compute Security Admin( Permissions to create, modify, and delete firewall rules and SSL certificates, and also to configure Shielded VM settings. For example, if your company has a security team that manages firewalls and SSL certificates and a networking team that manages the rest of the networking resources, then grant this role to the security team's group. Lowest-level resources where you can grant this role:
|
|
Compute Engine Service Agent( Gives Compute Engine Service Account access to assert service account authority. Includes access to service accounts. |
|
Compute Sole Tenant Viewer( Permissions to view sole tenancy node groups |
|
Compute Storage Admin( Permissions to create, modify, and delete disks, images, and snapshots. For example, if your company has someone who manages project images and you don't want them to have the editor role on the project, then grant this role to their account on the project. Lowest-level resources where you can grant this role:
|
|
Compute Viewer( Read-only access to get and list Compute Engine resources, without being able to read the data stored on them. For example, an account with this role could inventory all of the disks in a project, but it could not read any of the data on those disks. Lowest-level resources where you can grant this role:
|
|
Compute Shared VPC Admin( Permissions to administer shared VPC host projects, specifically enabling the host projects and associating shared VPC service projects to the host project's network. At the organization level, this role can only be granted by an organization admin.
Google Cloud recommends that the Shared VPC Admin be the owner of the shared VPC host project. The
Shared VPC Admin is responsible for granting the Compute Network User role
( Lowest-level resources where you can grant this role:
|
|
Siguientes pasos
- Más información sobre Cloud IAM
- Crear y gestionar roles de gestión de identidades y accesos personalizados
- Conceder roles de gestión de identidades y accesos a usuarios del proyecto
- Conceder roles de gestión de identidades y accesos a recursos específicos de Compute Engine
- Conceder roles de gestión de identidades y accesos a cuentas de servicio