Quando aggiungi un nuovo membro al tuo progetto, puoi utilizzare una policy IAM (Identity and Access Management) per assegnare a questo membro uno o più ruoli IAM. Ogni ruolo IAM contiene autorizzazioni che concedono al membro l'accesso a risorse specifiche.
Compute Engine dispone di un insieme di ruoli IAM predefiniti descritti in questa pagina. Puoi anche creare ruoli personalizzati che contengono sottoinsiemi di autorizzazioni che corrispondono direttamente alle tue esigenze.
Per scoprire quali autorizzazioni sono richieste per ogni metodo, consulta la documentazione di riferimento dell'API Compute Engine:
Per informazioni sulla concessione dell'accesso, consulta le seguenti pagine.
- Per impostare i criteri IAM a livello di progetto, consulta Gestire l'accesso a progetti, cartelle e organizzazioni nella documentazione IAM.
- Per impostare policy su risorse Compute Engine specifiche, leggi Concessione dell'accesso alle risorse Compute Engine.
- Per assegnare ruoli a un account di servizio Compute Engine, leggi Crea una VM che utilizza un service account gestito dall'utente.
Che cos'è IAM?
Google Cloud offre IAM, che ti consente di concedere un accesso più granulare a risorseGoogle Cloud specifiche e impedisce l'accesso indesiderato ad altre risorse. IAM ti consente di adottare il principio di sicurezza del privilegio minimo, in modo da concedere solo il livello di accesso necessario per le tue risorse.
IAM consente di controllare chi (identità) ha
quale (ruoli) autorizzazione per quali risorse impostando
i criteri IAM. I criteri IAM concedono ruoli specifici
a un membro del progetto, conferendo a questa identità determinate autorizzazioni. Ad esempio, per una determinata risorsa, come un progetto, puoi assegnare il ruolo Amministratore rete Compute (roles/compute.networkAdmin
) a un account utente (un Account Google o un account di un provider di identità esterno) e questo account può controllare le risorse correlate alla rete nel progetto, ma non può gestire altre risorse, come istanze e dischi. Puoi anche utilizzare
IAM per gestire i
ruoli legacy della console
concessi ai membri del team del progetto.Google Cloud
Il ruolo ServiceAccountUser
Se concesso insieme al
ruolo Amministratore istanze Compute (v1)
(roles/compute.instanceAdmin.v1
),
il ruolo Utente service account
(roles/iam.serviceAccountUser
) consente ai membri di creare
e gestire istanze che utilizzano un account di servizio. In particolare,
la concessione di roles/iam.serviceAccountUser
e roles/compute.instanceAdmin.v1
insieme consente ai membri di:
- Crea un'istanza che viene eseguita come service account.
- Collega un disco permanente a un'istanza eseguita come account di servizio.
- Imposta i metadati dell'istanza su un'istanza eseguita come account di servizio.
- Utilizza SSH per connetterti a un'istanza eseguita come account di servizio.
- Riconfigura un'istanza per l'esecuzione come account di servizio.
Puoi concedere il ruolo Service Account User (roles/iam.serviceAccountUser
) in
uno dei due modi seguenti:
Consigliato. Concedi il ruolo a un membro di un account di servizio specifico. In questo modo, un membro ha accesso al account di servizio di cui è
iam.serviceAccountUser
, ma non ad altri service account di cui non èiam.serviceAccountUser
.Concedi il ruolo a un membro a livello di progetto. Il membro ha accesso a tutti i service account del progetto, inclusi quelli che verranno creati in futuro.
Se non hai familiarità con i service account, scopri di più sui service account.
Google Cloud console permission
Per utilizzare Google Cloud console per accedere alle risorse Compute Engine, devi disporre di un ruolo che contenga la seguente autorizzazione sul progetto:
compute.projects.get
Connessione a un'istanza come instanceAdmin
Dopo aver concesso a un membro del progetto il ruolo roles/compute.instanceAdmin.v1
, quest'ultimo
può connettersi alle istanze di macchine virtuali (VM) utilizzando strumenti Google Cloud
standard, come gcloud CLI o
SSH nel browser.
Quando un membro utilizza gcloud CLI o SSH in Browser, gli strumenti generano automaticamente una coppiachiave pubblica/privataa e aggiungono la chiave pubblica ai metadati del progetto. Se il membro non dispone delle autorizzazioni per modificare i metadati del progetto, lo strumento aggiunge la chiave pubblica del membro ai metadati dell'istanza.
Se il membro ha una coppia di chiavi esistente che vuole utilizzare, può aggiungere manualmente la chiave pubblica ai metadati dell'istanza. Scopri di più sull'aggiunta di chiavi SSH a un'istanza.
IAM con service account
Crea nuovi service account personalizzati e concedi ruoli IAM ai service account per limitare l'accesso delle tue istanze. Utilizza i ruoli IAM con account di servizio personalizzati per:
- Limita l'accesso delle tue istanze alle API utilizzando ruoli IAM granulari. Google Cloud
- Assegna a ogni istanza o insieme di istanze un'identità univoca.
- Limita l'accesso del account di servizio predefinito.
Scopri di più sui service account.
Gruppi di istanze gestite e IAM
I gruppi di istanze gestite (MIG) sono risorse che eseguono azioni per tuo conto senza interazione diretta con l'utente. Ad esempio, il MIG può aggiungere e rimuovere VM dal gruppo.
Tutte le operazioni eseguite da Compute Engine nell'ambito del MIG vengono eseguite dall'agente di servizio API di Google per il tuo progetto, che ha un indirizzo email simile al seguente:
PROJECT_ID@cloudservices.gserviceaccount.com
Per impostazione predefinita, all'agente di servizio delle API di Google viene concesso il ruolo Editor (roles/editor
) a livello di progetto, che concede privilegi sufficienti per creare risorse in base alla configurazione del MIG. Se stai personalizzando
l'accesso per l'agente di servizio delle API di Google, concedi il ruolo Amministratore istanze Compute (v1)
(roles/compute.instanceAdmin.v1
) e, facoltativamente, il ruolo Utente service account
(roles/iam.serviceAccountUser
). Il ruolo Utente service account è richiesto
solo se il gruppo di istanze gestite crea VM che possono essere eseguite come account di servizio.
Tieni presente che l'agente di servizio delle API di Google viene utilizzato anche da altri processi, tra cui Deployment Manager.
Quando crei un MIG o aggiorni il relativo modello di istanza, Compute Engine verifica che l'agente di servizio API di Google disponga del seguente ruolo e delle seguenti autorizzazioni:
- Ruolo Utente service account, importante se prevedi di creare istanze che possono essere eseguite comeaccount di serviziot
- Autorizzazioni per tutte le risorse a cui viene fatto riferimento dai modelli di istanza, ad esempio immagini, dischi, reti VPC e subnet
Ruoli IAM di Compute Engine predefiniti
Con IAM, ogni metodo API nell'API Compute Engine richiede che l'identità che effettua la richiesta API disponga delle autorizzazioni appropriate per utilizzare la risorsa. Le autorizzazioni vengono concesse impostando policy che assegnano ruoli a un membro (utente, gruppo o account di servizio) del tuo progetto.
Oltre ai ruoli di base (visualizzatore, editor, proprietario) e ai ruoli personalizzati, puoi assegnare i seguenti ruoli predefiniti di Compute Engine ai membri del tuo progetto.
Puoi concedere più ruoli a un membro del progetto sulla stessa risorsa. Ad esempio, se il tuo team di networking gestisce anche le regole firewall, puoi concedere sia roles/compute.networkAdmin
che roles/compute.securityAdmin
al gruppo Google del team di networking.
Le tabelle seguenti descrivono i ruoli IAM predefiniti di Compute Engine, nonché le autorizzazioni contenute in ciascun ruolo. Ogni ruolo contiene un insieme di autorizzazioni adatto a un'attività specifica. Ad esempio, i ruoli Amministratore istanze concedono le autorizzazioni per gestire le istanze, i ruoli correlati alla rete includono le autorizzazioni per gestire le risorse correlate alla rete e il ruolo di sicurezza include le autorizzazioni per gestire le risorse correlate alla sicurezza, come firewall e certificati SSL. Quando lavori su Compute Engine, potresti aver bisogno anche di ruoli per altri servizi come Cloud DNS e account di servizio IAM. Per un elenco completo dei ruoli IAM, consulta la documentazione di riferimento sui ruoli IAM.
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:
|
|
Passaggi successivi
- Scopri di più su IAM
- Creare e gestire ruoli IAM personalizzati
- Concedi ruoli IAM agli utenti del progetto
- Concedi ruoli IAM per risorse Compute Engine specifiche
- Concedi ruoli IAM ai service account