Por defecto, todos Google Cloud Los proyectos vienen con un solo usuario: el creador del proyecto original. Ningún otro usuario tiene acceso al proyecto y, por lo tanto, acceso a los recursos de Compute Engine, hasta que se agregue un usuario como miembro del proyecto o se vincule a un recurso específico. Esta página describe las formas en que puedes agregar nuevos usuarios a tu proyecto y cómo configurar el control de acceso para tus recursos de Compute Engine mediante la administración de identidad y acceso (IAM).
Para obtener información sobre cómo brindar acceso a las aplicaciones que se ejecutan en sus instancias de Compute Engine, consulte Cómo se determina la autorización .
Opciones de control de acceso para usuarios.
Para brindarles a los usuarios la capacidad de crear y administrar sus recursos de Compute Engine, puede agregar usuarios como miembros del equipo a su proyecto o a recursos específicos y otorgarles permisos mediante roles de IAM.
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 identidad externo , un grupo de Google, un grupo de identidades de un grupo de identidades de personal, una cuenta de servicio o un dominio de Google Workspace. Cuando agrega un miembro del equipo a un proyecto o a un recurso, especifica qué roles otorgarle. IAM proporciona tres tipos de roles: roles predefinidos , roles básicos y roles personalizados .
Los recursos heredan las políticas de sus recursos principales en elGoogle Cloudjerarquía de recursos . La política efectiva para un recurso es la unión de la política establecida en ese recurso y la política heredada de su padre.
Roles predefinidos de Compute Engine
Los roles predefinidos otorgan un conjunto de permisos relacionados. Compute Engine ofrece los siguientes roles predefinidos:
| Título del rol | Capacidades | Usuario objetivo |
|---|---|---|
| Usuario de imagen de Compute Engine | Permiso para enumerar y utilizar imágenes de otro proyecto. Otorgue a un miembro este rol junto con otro rol para que el miembro pueda usar imágenes de otro proyecto para crear un nuevo recurso. Por ejemplo, otorgue esta función y la función de administrador de instancias para que un miembro pueda usar imágenes de otro proyecto para crear instancias de VM y discos persistentes. Si está creando grupos de instancias administrados o si está utilizando Deployment Manager para crear instancias de VM, es posible que deba otorgar esta función a la cuenta de servicio de las API de Google del proyecto antes de poder usar imágenes de otros proyectos. |
|
| Administrador de instancia de Compute Engine (v1) | Control total de instancias, grupos de instancias, discos, instantáneas e imágenes de Compute Engine. Acceso de solo lectura a todos los recursos de red de Compute Engine. Si el miembro administra instancias de VM que están configuradas para ejecutarse como una cuenta de servicio, también debe otorgar el rol |
|
| Rol de administrador de Compute Engine | Control total de todos los recursos de Compute Engine. Si el usuario administra instancias de VM que están configuradas para ejecutarse como una cuenta de servicio, también debe otorgar el rol |
|
| Administrador de red de Compute Engine | Permisos para crear, modificar y eliminar recursos de red, excepto reglas de firewall y certificados SSL. La función de administrador de red permite el acceso de solo lectura a reglas de firewall, certificados SSL e instancias (para ver sus direcciones IP efímeras). La función 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 firewall y certificados SSL. | Administradores de seguridad |
| Beta del administrador del balanceador de carga de Compute Engine | Permisos para crear, modificar y eliminar balanceadores de carga y recursos asociados. | Administradores del balanceador de carga |
| Usuario de la cuenta de servicio de Compute Engine | Permiso para crear instancias que usan cuentas de servicio y permiso para adjuntar un disco y configurar metadatos en una instancia ya configurada para ejecutarse como una cuenta de servicio. No debes otorgar esta función por sí sola porque no proporciona permisos para la API de Compute Engine. Debe otorgarle a un miembro este rol y otro rol, como el rol de administrador de instancia. |
|
| Rol de visor de Compute Engine | Acceso de solo lectura para obtener y enumerar recursos de Compute Engine, sin poder leer los datos almacenados en ellos. Por ejemplo, una cuenta con esta función podría inventariar todos los discos de un proyecto, pero no podría leer ninguno de los datos de esos discos. | Administradores de sistemas |
| Usuario de red de Compute Engine | Permisos para utilizar una red VPC compartida . Específicamente, otorgue este rol a los propietarios de servicios que necesiten utilizar recursos en el proyecto anfitrión. Una vez concedidos, los propietarios del servicio pueden utilizar subredes y redes que pertenecen al proyecto anfitrión. Por ejemplo, un usuario de red puede crear una instancia de VM que pertenezca a una red de host de VPC compartida, pero no puede eliminar ni crear nuevas redes en el proyecto de host. |
|
| Visor de red de Compute Engine | Acceso de solo lectura a todos los recursos de red. Por ejemplo, si tiene un software que inspecciona la configuración de su red, puede otorgarle a la cuenta de servicio de ese software la función de visor de red. |
|
| Versión beta del administrador de almacenamiento de Compute Engine | Permisos para crear, modificar y eliminar discos, imágenes e instantáneas. Por ejemplo, si su empresa tiene a alguien que administra imágenes y no desea que tenga la función de editor en el proyecto, otorgue esta función a su cuenta. |
|
| Administrador de VPC compartida de Compute Engine | Permisos para administrar proyectos de host de VPC compartidos, habilitando específicamente los proyectos de host y asociando proyectos de servicio a la red del proyecto de host. Este rol sólo se puede otorgar a nivel de organización. | Creadores de proyectos |
Para ver una lista de métodos API a los que una función específica otorga permiso, revisa la documentación de funciones de IAM de Compute Engine .
Matriz de roles predefinidos
La siguiente tabla proporciona una comparación completa de las capacidades de cada función de Compute Engine.
| Capacidad | Administrador de instancia (v1) | Usuario de imagen | Usuario de red | Visor de red | Administrador de red | Administrador de seguridad | Administrador de almacenamiento | Administrador de VPC compartido | Administrador de computación | Visor de cálculo | Administrador del balanceador de carga |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Crear o eliminar instancias de VM | * | ||||||||||
| SSH en instancias de VM | * | * | |||||||||
| Listar u obtener instancias de VM | |||||||||||
| Crear o eliminar imágenes, discos, instantáneas. | |||||||||||
| Listar u obtener imágenes | |||||||||||
| Crear o eliminar grupos de instancias | * | ||||||||||
| Listar u obtener grupos de instancias | |||||||||||
| Crear y administrar balanceadores de carga | |||||||||||
| Crear y administrar VPN | |||||||||||
| Ver recursos de red/subred | |||||||||||
| Ver reglas de firewall | |||||||||||
| Cree y administre firewalls y certificados SSL | para cortafuegos, para certificados SSL | ||||||||||
| Crear y gestionar proyectos de host de VPC compartidos | |||||||||||
| Usar redes y subredes en un proyecto de host de VPC compartido | |||||||||||
| Crear y gestionar redes y subredes. |
*Si la instancia de VM se puede ejecutar como una cuenta de servicio, otorgue también el rol de usuario de la cuenta de servicio.
Para ver una lista de métodos API a los que una función específica otorga permiso, revisa la documentación de funciones de IAM de Compute Engine .
Roles básicos de IAM
Los roles básicos de IAM se asignan directamente a los roles de propietario, editor y visor del proyecto heredado. Generalmente, debes utilizar roles predefinidos siempre que sea posible; sin embargo, en algunos casos en los que IAM aún no es compatible, es posible que deba utilizar una función básica para otorgar los permisos correctos.
| Título del rol | Permisos |
|---|---|
Owner | Todos los privilegios de espectador y editor, además de la capacidad de cambiar la configuración de facturación, administrar el control de acceso y eliminar un proyecto. |
Editor | Todos los privilegios de espectador, además de la capacidad de crear, modificar y eliminar recursos. |
Viewer | Permisos de solo lectura para todos los recursos; No hay permiso para cambiar recursos. |
Para obtener más información sobre los roles básicos, lea la documentación sobre roles básicos .
Si los roles predefinidos o básicos no satisfacen sus necesidades, puede crear roles personalizados .
Políticas de IAM para recursos de Compute Engine
Puedes otorgar 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 IAM le permite administrar funciones de IAM en esos recursos en lugar de, o además de, administrar funciones a nivel de proyecto. Esto le brinda flexibilidad para aplicar el principio de privilegio mínimo, que consiste en otorgar acceso solo a los recursos específicos que los colaboradores necesitan para realizar su trabajo.
Con las políticas de IAM para los recursos de Compute Engine, las organizaciones pueden:
- Otorgue a los usuarios acceso a un subconjunto específico de recursos . Supongamos que Alice debería gestionar un subconjunto de instancias en un proyecto. Con las políticas de IAM a nivel de instancia, le otorga la función
compute.instanceAdmin.v1solo en esas instancias. Si le concedió a Alice el mismo rol en el proyecto, ella tendría permiso para modificar todas las instancias del proyecto. - Permitir a los administradores otorgar acceso . Los administradores pueden otorgar acceso a otras personas a instancias, discos e imágenes sin necesidad de ser poderosos propietarios de proyectos. Supongamos que Bob es un desarrollador al que se le ha otorgado la función
compute.storageAdminen una imagen específica. Puede compartir esa imagen con sus compañeros de equipo otorgándoles el rolcompute.imageUseren la imagen. Sin políticas de IAM para los recursos de Compute Engine, Bob no puede compartir esa imagen con sus compañeros de equipo a menos que se convierta en propietario del proyecto porque necesitaría modificar la política de IAM del proyecto.
Los recursos también heredan las políticas de sus recursos principales. Si establece una política a nivel de proyecto, todos sus recursos secundarios la heredan. La política efectiva para un recurso es la unión de la política establecida en ese recurso y la política heredada de un nivel superior en la jerarquía. Para obtener más información, lea acerca de la jerarquía de políticas de IAM .
Políticas de la organización
Si es miembro de Google Workspace, su proyecto podría ser parte de un recurso de la organización . Un recurso de organización es el supernodo en el Google Cloudjerarquía de recursos que está estrechamente asociada con una cuenta de Google Workspace. Después de crear un recurso de organización para un dominio de Google Workspace, todosGoogle Cloud Los proyectos creados por miembros del dominio pertenecen al recurso de la Organización.
Una organización puede implementar políticas de organización , que son políticas que restringen las configuraciones permitidas en todo suGoogle Cloud jerarquía de recursos. Para Compute Engine, puedes implementar las siguientes políticas:
- Deshabilite el acceso interactivo a la consola serie .
- Deshabilite las direcciones IP externas para instancias de VM .
- Restringir qué proyectos de imágenes están disponibles para los miembros de su proyecto
Para establecer políticas de la organización , se le debe haber otorgado el rol orgpolicy.policyAdmin en la organización. También puede establecer anulaciones específicas del proyecto en caso de que tenga excepciones a la política.
Para obtener más información sobre Organizaciones, lea la documentación de Organizaciones .
Para obtener más información sobre las políticas de la organización, lea la documentación de políticas de la organización .
Otorgar a los usuarios acceso SSH a instancias de VM
Para brindarle a un usuario la capacidad de conectarse a una instancia de VM usando SSH sin otorgarle la capacidad de administrar los recursos de Compute Engine, agregue la clave pública del usuario al proyecto o agregue la clave pública de un usuario a una instancia específica. Con este método, puede evitar agregar un usuario como miembro del proyecto y al mismo tiempo otorgarle acceso a instancias específicas.
Para obtener más información sobre SSH y la administración de claves SSH, lea la descripción general de las claves SSH .
Tenga en cuenta que si otorga la función roles/compute.instanceAdmin.v1 a un miembro del proyecto, este puede conectarse automáticamente a instancias mediante SSH, siempre y cuando 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 debe otorgar el rol roles/iam.serviceAccountUser antes de que el miembro pueda conectarse a la instancia.
Si agrega un miembro como propietario o editor del 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 ejecuta el código de la aplicación en instancias y la aplicación necesita autenticarse en otras Google Cloud API, puede crear cuentas de servicio y asignarles roles de IAM específicos para autenticarse ante otros. Google Cloud API en su nombre. Una cuenta de servicio es una cuenta especial que no tiene credenciales de usuario y es ideal para interacciones de servidor a servidor.
Para obtener más información sobre las cuentas de servicio, lea la documentación de Cuentas de servicio .
Identidades de cargas de trabajo administradas para cargas de trabajo de Compute Engine
Puede configurar el aprovisionamiento automático y la administración del ciclo de vida de los certificados X.509 desde el Servicio de autoridad de certificación (servicio CA) mediante identidades de carga de trabajo administradas. Los certificados de identidad de cargas de trabajo administradas se emiten desde CA Service, que es una solución escalable y de alta disponibilidad. Google Cloud servicio que le ayuda a simplificar y automatizar la implementación, gestión y seguridad de los servicios de CA mientras mantiene el control de sus claves privadas.
Con las identidades de carga de trabajo administradas, puedes beneficiarte de mTLS por máquina virtual, administrado por Compute Engine. mTLS por máquina virtual utiliza certificados X.509 que se emiten al crear una máquina virtual. Estos certificados mTLS se rotan automáticamente, por lo que ya no necesita preocuparse por administrarlos.
Las identidades de cargas de trabajo administradas proporcionan una base para permitir comunicaciones cifradas y autenticadas mutuamente entre dos máquinas virtuales de Compute Engine. Por ejemplo, cuando utiliza identidades de carga de trabajo administradas, el servicio A que se ejecuta en una máquina virtual se comunica con el servicio B que se ejecuta en otra diferente 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 administradas, consulte Autenticar cargas de trabajo en otras cargas de trabajo a través de mTLS .
¿Qué sigue?
- Agregar usuarios como miembros del equipo .
- Obtenga más información sobre las funciones de IAM .
- Obtenga más información sobre cómo agregar y eliminar claves SSH .
- Obtenga más información sobre las cuentas de servicio .