De forma predeterminada, todos los proyectos Google Cloud tienen un solo usuario: el creador original del proyecto. Ningún otro usuario tiene acceso al proyecto y, por lo tanto, a los recursos de Compute Engine, hasta que se añade como miembro del proyecto o se vincula a un recurso específico. En esta página se describe cómo añadir usuarios nuevos a tu proyecto y cómo configurar el control de acceso a tus recursos de Compute Engine mediante Gestión de Identidades y Accesos (IAM).
Para obtener información sobre cómo proporcionar acceso a las aplicaciones que se ejecutan en tus instancias de Compute Engine, consulta Cómo se determina la autorización.
Opciones de control de acceso para usuarios
Para que los usuarios puedan crear y gestionar tus recursos de Compute Engine, puedes añadirlos como miembros del equipo a tu proyecto o a recursos específicos y concederles permisos mediante roles de gestión de identidades y accesos.
Un miembro del equipo puede ser un usuario individual con una cuenta de Google válida o una cuenta de usuario de un proveedor de identidades externo, un grupo de Google, un grupo de identidades de un grupo de identidades de la plantilla, una cuenta de servicio o un dominio de Google Workspace. Cuando añades un miembro del equipo a un proyecto o a un recurso, especificas los roles que quieres asignarle. Gestión de identidades y accesos ofrece tres tipos de roles: roles predefinidos, roles básicos y roles personalizados.
Los recursos heredan las políticas de sus recursos superiores en la Google Cloud jerarquía de recursos. La política efectiva de un recurso es la unión de la política definida en ese recurso y la política heredada de su elemento superior.
Roles predefinidos de Compute Engine
Los roles predefinidos conceden un conjunto de permisos relacionados. Compute Engine ofrece los siguientes roles predefinidos:
| Título del rol | Funciones | Usuario objetivo |
|---|---|---|
| Usuario de imágenes de Compute Engine |
Permiso para enumerar y usar imágenes de otro proyecto. Asigna a un miembro este rol junto con otro para que pueda usar imágenes de otro proyecto para crear un recurso. Por ejemplo, asigna este rol y el rol Administrador de instancias para que un miembro pueda usar imágenes de otro proyecto para crear instancias de VM y discos persistentes. Si vas a crear grupos de instancias gestionadas o si usas Deployment Manager para crear instancias de VM, puede que tengas que conceder este rol a la cuenta de servicio de las APIs de Google del proyecto para poder usar imágenes de otros proyectos. |
|
| Administrador de instancias de Compute Engine (v. 1) |
Control total de las instancias, grupos de instancias, discos, capturas e imágenes de Compute Engine. Acceso de solo lectura a todos los recursos de red de Compute Engine. Si el miembro gestiona instancias de VM configuradas para ejecutarse como una cuenta de servicio, también debe concederle el rol |
|
| Rol de administrador de Compute Engine |
Control total sobre todos los recursos de Compute Engine. Si el usuario gestiona instancias de VM configuradas para ejecutarse como cuenta de servicio, también debes concederle el rol |
|
| Administrador de red de Compute Engine |
Permisos para crear, modificar y eliminar recursos de red, excepto reglas de cortafuegos y certificados SSL. El rol de administrador de red permite el acceso de solo lectura a las reglas de cortafuegos, los certificados SSL y las instancias (para ver sus direcciones IP efímeras). El rol de administrador de red no permite que un miembro cree, inicie, detenga o elimine instancias. |
Administradores de red |
| Administrador de seguridad de Compute Engine |
Permisos para crear, modificar y eliminar reglas de cortafuegos y certificados SSL. |
Administradores de seguridad |
| Administrador de balanceadores de carga de Compute Enginebeta |
Permisos para crear, modificar y eliminar balanceadores de carga y recursos asociados. |
Administradores de balanceadores de carga |
| Usuario de cuenta de servicio de Compute Engine |
Permiso para crear instancias que usen cuentas de servicio y permiso para adjuntar un disco y definir metadatos en una instancia que ya esté configurada para ejecutarse como cuenta de servicio. No debes asignar este rol por sí solo, ya que no proporciona permisos a la API Compute Engine. Debes conceder a un miembro este rol y otro, como el rol de administrador de la instancia. |
|
| Rol de lector de Compute Engine |
Acceso de solo lectura para obtener y mostrar recursos de Compute Engine, sin poder leer los datos almacenados en ellos. Por ejemplo, una cuenta con este rol podría inventariar todos los discos de un proyecto, pero no podría leer ninguno de los datos de esos discos. |
Administradores del sistema |
| Usuario de red de Compute Engine |
Permisos para usar una red de VPC compartida. En concreto, concede este rol a los propietarios de servicios que necesiten usar recursos en el proyecto host. Una vez concedido, los propietarios del servicio pueden usar subredes y redes que pertenezcan al proyecto del host. Por ejemplo, un usuario de la red puede crear una instancia de VM que pertenezca a una red de host de VPC compartida, pero no puede eliminar ni crear redes en el proyecto del host. |
|
| Lector de red de Compute Engine |
Acceso de solo lectura a todos los recursos de red. Por ejemplo, si tienes un software que inspecciona la configuración de tu red, puedes conceder a la cuenta de servicio de ese software el rol de lector de red. |
|
| Administrador de almacenamiento de Compute Enginebeta |
Permiso para crear, modificar y eliminar discos, imágenes y capturas. Por ejemplo, si en tu empresa hay alguien que gestiona las imágenes y no quieres que tenga el rol de editor en el proyecto, asigna este rol a su cuenta. |
|
| Administrador de VPC compartidas de Compute Engine |
Permisos para administrar proyectos de host de VPC compartidas, concretamente para habilitar los proyectos de host y asociar proyectos de servicio a la red del proyecto de host. Este rol solo se puede asignar a nivel de organización. |
Creadores del proyecto |
Para ver una lista de los métodos de la API a los que un rol específico concede permiso, consulta la documentación sobre los roles de gestión de identidades y accesos de Compute Engine.
Matriz de roles predefinidos
En la siguiente tabla se ofrece una comparación completa de las funciones de cada rol de Compute Engine.
| Competencia | Administrador de instancias (v1) | Usuario de imagen | Usuario de la red | Lector de redes | Administrador de red | Administrador de seguridad | Administrador de almacenamiento | Administrador de VPC compartida | Administrador de Compute | Lector de Compute | Administrador de balanceadores de carga |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Crear o eliminar instancias de VM | * | ||||||||||
| Acceder a instancias de VM a través de SSH | * | * | |||||||||
| Listar o obtener instancias de VM | |||||||||||
| Crear o eliminar imágenes, discos o instantáneas | |||||||||||
| Listar o obtener imágenes | |||||||||||
| Crear o eliminar grupos de instancias | * | ||||||||||
| Mostrar u obtener grupos de instancias | |||||||||||
| Crear y gestionar balanceadores de carga | |||||||||||
| Crear y gestionar VPNs | |||||||||||
| Ver recursos de redes o subredes | |||||||||||
| Ver reglas de cortafuegos | |||||||||||
| Crear y gestionar cortafuegos y certificados SSL |
para firewalls para certificados SSL |
||||||||||
| Crear y gestionar proyectos host de VPC compartida | |||||||||||
| Usar redes y subredes en un proyecto host de VPC compartida | |||||||||||
| Crear y gestionar redes y subredes |
*Si la instancia de VM puede ejecutarse como una cuenta de servicio, asigna también el rol de usuario de cuenta de servicio.
Para ver una lista de los métodos de la API a los que un rol específico concede permiso, consulta la documentación sobre los roles de gestión de identidades y accesos de Compute Engine.
Roles básicos de gestión de identidades y accesos
Los roles básicos de gestión de identidades y accesos se asignan directamente a los roles antiguos de propietario, editor y lector del proyecto. Por lo general, debes usar roles predefinidos siempre que sea posible. Sin embargo, en algunos casos en los que aún no se admite la gestión de identidades y accesos, es posible que tengas que usar un rol básico para conceder los permisos correctos.
| Título del rol | Permisos |
|---|---|
Owner |
Todos los privilegios de lector y editor, además de la capacidad de cambiar la configuración de facturación, gestionar el control de acceso y eliminar un proyecto. |
Editor |
Todos los privilegios de lector, además de la capacidad de crear, modificar y eliminar recursos. |
Viewer |
Permisos de solo lectura para todos los recursos; no se pueden cambiar los recursos. |
Para obtener más información sobre los roles básicos, consulta la documentación sobre los roles básicos.
Si los roles predefinidos o básicos no se ajustan a tus necesidades, puedes crear roles personalizados.
Políticas de gestión de identidades y accesos para recursos de Compute Engine
Puedes conceder acceso a recursos de Compute Engine, como instancias de VM, imágenes y discos, adjuntando políticas de IAM directamente a esos recursos. Una política de gestión de identidades y accesos te permite gestionar roles de gestión de identidades y accesos en esos recursos en lugar de gestionar roles a nivel de proyecto, o además de hacerlo. De esta forma, puedes aplicar el principio de mínimos accesos, que consiste en conceder acceso solo a los recursos específicos que los colaboradores necesitan para hacer su trabajo.
Con las políticas de gestión de identidades y accesos de los recursos de Compute Engine, las organizaciones pueden hacer lo siguiente:
- Conceder acceso a los usuarios a un subconjunto específico de recursos. Supongamos que Alicia debe gestionar un subconjunto de instancias de un proyecto. Con las políticas de gestión de identidades y accesos a nivel de instancia, le asignas el rol
compute.instanceAdmin.v1solo en esas instancias. Si le concedieras a Alicia el mismo rol en el proyecto, tendría permiso para modificar todas las instancias del proyecto. - Permitir que los administradores concedan acceso. Los administradores pueden conceder acceso a instancias, discos e imágenes a otros usuarios sin necesidad de ser propietarios de proyectos con privilegios. Supongamos que Bob es un desarrollador al que se le ha asignado el rol
compute.storageAdminen una imagen específica. Puede compartir esa imagen con sus compañeros de equipo dándoles el rolcompute.imageUseren la imagen. Si no hay políticas de gestión de identidades y accesos para los recursos de Compute Engine, Bob no podrá compartir esa imagen con sus compañeros de equipo a menos que se convierta en propietario del proyecto, ya que tendría que modificar la política de gestión de identidades y accesos del proyecto.
Los recursos también heredan las políticas de sus recursos superiores. Si defines una política a nivel de proyecto, todos sus recursos secundarios la heredarán. La política efectiva de un recurso es la unión de la política definida en ese recurso y la política heredada de un nivel superior de la jerarquía. Para obtener más información, consulta la jerarquía de políticas de gestión de identidades y accesos.
Políticas de organización
Si eres miembro de Google Workspace, es posible que tu proyecto forme parte de un recurso de organización. Un recurso de organización es el supernodo de la Google Cloud jerarquía de recursos que está estrechamente asociado a una cuenta de Google Workspace. Una vez que se crea un recurso de organización para un dominio de Google Workspace, todos los proyectos creados por los miembros del dominio pertenecen al recurso de organización.Google Cloud
Una organización puede implementar políticas de organización, que son políticas que restringen las configuraciones permitidas en toda laGoogle Cloud jerarquía de recursos. En Compute Engine, puedes implementar las siguientes políticas:
- Inhabilita el acceso interactivo a la consola en serie.
- Inhabilita las direcciones IP externas de las instancias de VM.
- Restringir los proyectos de imágenes que están disponibles para los miembros de tu proyecto
Para definir políticas de la organización, debes tener asignado el rol orgpolicy.policyAdmin en la organización.
También puedes definir anulaciones específicas de un proyecto si tienes excepciones a la política.
Para obtener más información sobre las organizaciones, consulta la documentación sobre organizaciones.
Para obtener más información sobre las políticas de organización, consulta la documentación sobre la política de organización.
Conceder acceso SSH a instancias de VM a los usuarios
Para dar a un usuario la posibilidad de conectarse a una instancia de VM mediante SSH sin concederle la capacidad de gestionar recursos de Compute Engine, añade la clave pública del usuario al proyecto o a una instancia específica. Con este método, puedes evitar añadir a un usuario como miembro del proyecto y, al mismo tiempo, concederle acceso a instancias específicas.
Para obtener más información sobre SSH y la gestión de claves SSH, consulta el artículo Información general sobre las claves SSH.
Ten en cuenta que, si asignas el rol roles/compute.instanceAdmin.v1 a un miembro de un proyecto, este podrá conectarse automáticamente a las instancias mediante SSH, siempre que la instancia no esté configurada para ejecutarse como una cuenta de servicio. Si la instancia está configurada para ejecutarse como una cuenta de servicio, también debes conceder el rol roles/iam.serviceAccountUser para que el miembro pueda conectarse a la instancia.
Si añades un miembro como propietario o editor de un proyecto, también tendrá automáticamente acceso SSH a las instancias de VM del proyecto.
Control de acceso para aplicaciones que se ejecutan en instancias de VM
Si ejecutas código de aplicación en instancias y la aplicación necesita autenticarse en otras APIs, puedes crear cuentas de servicio y asignarles roles de gestión de identidades y accesos específicos para que se autentiquen en otras APIs en tu nombre. Google Cloud Google Cloud Una cuenta de servicio es una cuenta especial que no tiene credenciales de usuario y es ideal para las interacciones de servidor a servidor.
Para obtener más información sobre las cuentas de servicio, consulta la documentación sobre cuentas de servicio.
Identidades de cargas de trabajo gestionadas para cargas de trabajo de Compute Engine
Puedes configurar el aprovisionamiento automático y la gestión del ciclo de vida de los certificados X.509 desde el servicio de autoridades de certificación (CA Service) mediante identidades de carga de trabajo gestionadas. Los certificados de identidad de carga de trabajo gestionada se emiten desde el Servicio de Autoridades de Certificación, que es un servicio de alta disponibilidad y escalable Google Cloud que te ayuda a simplificar y automatizar el despliegue, la gestión y la seguridad de los servicios de AC, al tiempo que mantienes el control de tus claves privadas.
Con las identidades de carga de trabajo gestionadas, puedes beneficiarte de mTLS por máquina virtual, gestionado por Compute Engine. La autenticación TLS mutua por VM usa certificados X.509 que se emiten cuando creas una VM. Estos certificados mTLS se rotan automáticamente, por lo que ya no tienes que preocuparte por gestionarlos.
Las identidades de carga de trabajo gestionadas proporcionan una base para habilitar las comunicaciones cifradas y autenticadas mutuamente entre dos máquinas virtuales de Compute Engine. Por ejemplo, cuando usas identidades de carga de trabajo gestionadas, el servicio A que se ejecuta en una VM se comunica con el servicio B que se ejecuta en otra a través de un canal cifrado que se establece mediante mTLS.
Para obtener información sobre cómo configurar identidades de cargas de trabajo gestionadas, consulta Autenticar cargas de trabajo en otras cargas de trabajo mediante mTLS.
Siguientes pasos
- Añade usuarios como miembros del equipo.
- Consulta más información sobre los roles de gestión de identidades y accesos.
- Consulta más información sobre cómo añadir y eliminar claves SSH.
- Más información sobre las cuentas de servicio