Questo argomento illustra come configurare le autorizzazioni di Identity and Access Management (IAM) per gli scenari di networking. Fornisce indicazioni su quali ruoli IAM concedere ai ruoli funzionali relativi al networking nella tua azienda per gli scenari. Questi contenuti sono rivolti principalmente agli amministratori di rete e ai dipendenti che gestiscono attività di networking per un'organizzazione. Gli scenari descritti di seguito presuppongono tutti che sia stata configurata un'organizzazione Google Cloud.
Questo documento non spiega in dettaglio i ruoli e le autorizzazioni di networking. Per una descrizione dettagliata dei ruoli e delle autorizzazioni associati alle API di computing e rete, consulta Ruoli IAM predefiniti di Compute Engine.
Un unico team che gestisce sicurezza e rete per l'organizzazione
In questo scenario, una grande organizzazione ha un team centrale che gestisce i controlli di sicurezza e networking per l'intera organizzazione. Gli sviluppatori non hanno le autorizzazioni per apportare modifiche alle impostazioni di rete o di sicurezza definite dal team per la sicurezza e la rete, ma ricevono l'autorizzazione per creare risorse, ad esempio macchine virtuali in subnet condivise.
Per facilitare questa operazione, l'organizzazione utilizza un VPC condiviso (Virtual Private Cloud). Un VPC condiviso consente di creare una rete VPC di spazi IP RFC 1918 utilizzabili dai progetti associati (progetti di servizio). Gli sviluppatori che utilizzano i progetti associati possono creare istanze VM negli spazi di rete VPC condivisi. Gli amministratori di rete e della sicurezza dell'organizzazione possono creare subnet, VPN e regole firewall utilizzabili da tutti i progetti nella rete VPC.
Le tabelle seguenti spiegano i ruoli IAM che devono essere concessi al team di sicurezza e di amministrazione e al team di sviluppo, nonché il livello di risorsa a cui vengono concessi i ruoli.
| Risorsa: | organizzazione | |
|---|---|---|
| Ruoli: | Amministratore VPC condiviso Amministratore di rete Amministratore sicurezza |
|
| Entità: | Team di amministrazione della sicurezza e della rete |
| Risorsa: | Progetto host | Questo ruolo concede l'autorizzazione per utilizzare le subnet condivise dal VPC condiviso. |
|---|---|---|
| Ruolo: | Utente della rete | |
| Entità: | Sviluppatori |
| Risorsa: | Progetto di servizio | Tieni presente che questo ruolo consente l'autorizzazione a utilizzare indirizzi IP esterni. Consulta la nota riportata di seguito per indicazioni su come evitare questa azione. |
|---|---|---|
| Ruolo: | compute.instanceAdmin | |
| Entità: | Sviluppatori |
Per questo scenario sono necessari tre criteri di autorizzazione distinti: uno per l'organizzazione, uno per il progetto host e uno per i progetti di servizio.
Il primo criterio di autorizzazione, che deve essere associato a livello di organizzazione, concede alla rete e al team di sicurezza i ruoli necessari per amministrare i progetti host VPC condivisi. Ciò include la possibilità di associare i progetti di servizio al progetto host. Concede inoltre alla rete e al team per la sicurezza la possibilità di gestire tutte le risorse di rete e di sicurezza in tutti i progetti dell'organizzazione.
{
"bindings": [
{
"role": "roles/compute.xpnAdmin",
"members": [
"group:sec-net@example.com"
]
},
{
"role":"roles/compute.networkAdmin",
"members": [
"group:sec-net@example.com"
]
},
{
"role": "roles/compute.securityAdmin",
"members": [
"group:sec-net@example.com"
]
}
]
}
Il secondo criterio di autorizzazione deve essere associato al progetto host e consente agli sviluppatori dell'organizzazione di utilizzare le reti condivise nel progetto host VPC condiviso.
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
}
]
}
Il terzo criterio di autorizzazione deve essere associato a ogni progetto di servizio. Ciò consente agli sviluppatori che utilizzano il progetto di gestire le istanze nel progetto di servizio e di utilizzare le subnet condivise nel progetto host.
Puoi inserire tutti i progetti di servizio in una cartella e impostare questo particolare criterio di autorizzazione a quel livello della gerarchia. In questo modo, tutti i progetti creati in quella cartella erediteranno le autorizzazioni impostate a livello di cartella all'interno della quale viene creato il progetto di servizio.
Devi inoltre concedere agli sviluppatori il ruolo Utente di rete nel progetto di servizio.
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
},
{
"role": "roles/compute.instanceAdmin",
"members": [
"group:developers@example.com"
]
}
]
}
La best practice prevede l'uso dei gruppi per gestire le entità. Nell'esempio precedente,
devi aggiungere gli ID utente degli utenti che gestiscono i controlli di sicurezza e di rete
al gruppo sec-net e gli sviluppatori nel gruppo developers.
Quando devi modificare chi è in grado di eseguire la funzione, devi semplicemente modificare l'appartenenza al gruppo, eliminando la necessità di aggiornare il criterio di autorizzazione.
Team di rete e sicurezza separati
In questo scenario, una grande organizzazione ha due team centrali: uno che gestisce i controlli di sicurezza e un altro che gestisce tutte le altre risorse di networking per l'intera organizzazione. Gli sviluppatori non sono autorizzati ad apportare modifiche alle impostazioni di rete o di sicurezza definite dal team per la sicurezza e la rete, ma hanno l'autorizzazione per creare risorse come macchine virtuali in subnet condivise.
Come nel primo scenario, verrà utilizzato un VPC condiviso e verranno configurate le autorizzazioni appropriate per i tre gruppi, rete, sicurezza e sviluppatori.
Le tabelle seguenti spiegano i ruoli IAM che devono essere concessi al team di sicurezza e di amministrazione e al team di sviluppo, nonché il livello di risorsa a cui vengono concessi i ruoli.
| Risorsa: | organizzazione | |
|---|---|---|
| Ruoli: | Amministratore VPC condiviso Amministratore di rete |
|
| Entità: | Team di amministrazione di rete |
| Risorsa: | organizzazione | |
|---|---|---|
| Ruoli: | Amministratore sicurezza Amministratore dell'organizzazione |
|
| Entità: | Team addetto alla sicurezza |
| Risorsa: | Progetto host | Questo ruolo concede l'autorizzazione per utilizzare le subnet condivise dal VPC condiviso. |
|---|---|---|
| Ruolo: | Utente della rete | |
| Entità: | Sviluppatori |
| Risorsa: | Progetto di servizio | Tieni presente che questo ruolo consente l'autorizzazione a utilizzare indirizzi IP esterni. Consulta la nota riportata di seguito per indicazioni su come evitare questa azione. |
|---|---|---|
| Ruolo: | compute.instanceAdmin | |
| Entità: | Sviluppatori |
Per questo scenario sono necessari tre criteri di autorizzazione distinti: uno per l'organizzazione, uno per il progetto host e uno per i progetti di servizio.
Il primo criterio di autorizzazione, che deve essere associato a livello di organizzazione, concede al team di rete i ruoli necessari per amministrare i progetti host VPC condivisi e gestire tutte le risorse di rete. Ciò include la possibilità di associare progetti di servizio al progetto host. Il ruolo Amministratore di rete concede inoltre al team di rete la possibilità di visualizzare ma non di modificare le regole firewall. Concede inoltre al team per la sicurezza la possibilità di impostare criteri di autorizzazione e gestire le regole firewall e i certificati SSL in tutti i progetti dell'organizzazione.
{
"bindings": [
{
"role": "roles/compute.xpnAdmin",
"members": [
"group:networks@example.com"
]
},
{
"role": "roles/compute.networkAdmin",
"members": [
"group:networks@example.com"
]
},
{
"role": "roles/compute.securityAdmin",
"members": [
"group:security@example.com"
]
},
{
"role": "roles/resourcemanager.organizationAdmin",
"members": [
"group:security@example.com"
]
}
]
}
Il secondo criterio di autorizzazione deve essere associato al progetto host. Questo criterio di autorizzazione consente agli sviluppatori dell'organizzazione di utilizzare le reti condivise nel progetto host del VPC condiviso.
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
}
]
}
Il terzo criterio di autorizzazione deve essere associato a ogni progetto di servizio. Ciò consente agli sviluppatori che utilizzano il progetto di gestire le istanze nel progetto di servizio e di utilizzare le subnet condivise nel progetto host.
Puoi inserire tutti i progetti di servizio in una cartella e impostare questo particolare criterio di autorizzazione a quel livello della gerarchia. In questo modo, tutti i progetti creati in quella cartella erediteranno le autorizzazioni impostate a livello di cartella all'interno della quale viene creato il progetto di servizio.
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
},
{
"role": "roles/compute.instanceAdmin",
"members": [
"group:developers@example.com"
]
}
]
}
Ogni team può gestire la propria rete
Un nativo digitale vuole offrire ai propri team di sviluppo la possibilità di lavorare in modo autonomo. Non hanno team di amministratori IT centrali e si affidano ai loro team per gestire tutti gli aspetti dei loro progetti.
Ciononostante, vogliono anche avere la possibilità di mettere in atto alcuni controlli generali per consentire loro di adottare una configurazione più formale man mano che crescono e il loro prodotto diventa disponibile pubblicamente.
Per implementare questo scenario, a ogni team di sviluppatori viene assegnata una cartella specifica. Questa struttura garantisce che i singoli progetti creati nella cartella ereditino le autorizzazioni appropriate, consentendo a ogni team di lavorare in modo indipendente. Ogni team deve comunque seguire il principio del privilegio minimo quando imposta criteri di autorizzazione per le proprie risorse.
Anche se inizialmente saranno gli stessi membri del team a gestire le risorse di rete e le risorse effettive nei progetti, creare gruppi separati per i compiti logici è una best practice.
Questo approccio facilita l'accesso alle risorse di cui il personale temporaneo ha bisogno o magari anche di nuovo personale che ha bisogno di formazione prima di poter modificare le risorse di rete. Consente inoltre di cambiare chi ha accesso a quali risorse senza dover modificare il criterio di autorizzazione ogni volta che si verifica un cambiamento del personale.
| Risorsa: | cartella | Un account di servizio può essere utilizzato per creare progetti personali. |
|---|---|---|
| Ruoli: | Autore progetto Amministratore cartelle |
|
| Entità: | Lead del team di sviluppo Account di servizio |
| Risorsa: | cartella | |
|---|---|---|
| Ruoli: | Amministratore di rete Amministratore sicurezza |
|
| Entità: | Team Rete e sicurezza |
| Risorsa: | cartella | Questi ruoli consentono agli sviluppatori di gestire tutti gli aspetti di BigQuery e Compute Engine. |
|---|---|---|
| Ruoli: | Amministratore istanza Amministratore BigQuery |
|
| Entità: | Sviluppatori |
Ciò richiede un criterio di autorizzazione associato alla cartella allocata di ogni team.
{
"bindings": [
{
"role": "roles/resourcemanager.foldersAdmin",
"members": [
"group:devteamleads01@example.com",
"serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
]
},
{
"role":"roles/resourcemanager.projectCreator",
"members": [
"group:devteamleads01@example.com",
"serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
]
},
{
"role": "roles/compute.securityAdmin",
"members": [
"group:net-sec-dev01@example.com"
]
},
{
"role": "roles/compute.networkAdmin",
"members": [
"group:net-sec-dev01@example.com"
]
},
{
"role": "roles/compute.instanceAdmin",
"members": [
"group:dev01@example.com"
]
},
{
"role": "roles/bigquery.admin",
"members": [
"group:dev01@example.com"
]
}
]
}