Ruoli IAM per funzioni di job relative al networking

Questo argomento mostra come configurare le autorizzazioni Identity and Access Management (IAM) per scenari di networking. Fornisce indicazioni su quali ruoli IAM concedere ai ruoli funzionali relativi al networking della tua azienda in diversi scenari. Questi contenuti sono principalmente rivolti agli amministratori di rete e ai dipendenti che gestiscono le attività di networking per un'organizzazione. Gli scenari descritti di seguito presuppongono tutti che sia configurata un'organizzazione. Google Cloud

Questo documento non spiega nel dettaglio le autorizzazioni e i ruoli di networking. Per una descrizione dettagliata dei ruoli e delle autorizzazioni associati alle API di calcolo e networking, leggi Ruoli IAM di Compute Engine predefiniti.

Un unico team gestisce la sicurezza e la rete per l'organizzazione

In questo scenario, una grande organizzazione ha un team centrale che gestisce i controlli di sicurezza e di rete per l'intera organizzazione. Gli sviluppatori non dispongono delle autorizzazioni per apportare modifiche alle impostazioni di rete o di sicurezza definite dal team di sicurezza e networking, ma hanno l'autorizzazione per creare risorse come macchine virtuali in subnet condivise.

Per facilitare questa operazione, l'organizzazione utilizza un VPC condiviso (Virtual Private Cloud). Un VPC condiviso consente la creazione di una rete VPC di spazi IP RFC 1918 che i progetti associati (progetti di servizio) possono quindi utilizzare. Gli sviluppatori che utilizzano i progetti associati possono creare istanze VM negli spazi della rete VPC condivisa. 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 riportate di seguito illustrano i ruoli IAM che devono essere concessi al team di sicurezza e amministrazione e al team di sviluppo, nonché il livello di risorsa a cui vengono concessi i ruoli.

Risorsa: Organizzazione
Ruoli: Amministratore del VPC condiviso
Amministratore di rete
Amministratore della sicurezza
Entità: Team di amministratori di rete e della sicurezza
Risorsa: Progetto host Questo ruolo concede l'autorizzazione a utilizzare le subnet condivise dalla VPC condivisa.
Ruolo: Utente di 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 impedire questa azione.
Ruolo: compute.instanceAdmin
Entità: Sviluppatori

Per questo scenario sono necessarie tre policy di autorizzazione separate: una per l'organizzazione, una per il progetto host e una per i progetti di servizio.

Il primo criterio di autorizzazione, che deve essere associato a livello di organizzazione, concede al team di rete e sicurezza i ruoli necessari per amministrare i progetti host della rete VPC condivisa. Ciò include la possibilità di associare progetti di servizio al progetto host. Inoltre, concede al team di rete e sicurezza la possibilità di gestire tutte le risorse di rete e 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"
      ]
    }
  ]
}

La seconda policy di autorizzazione deve essere associata al progetto host e 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. In questo modo, gli sviluppatori che utilizzano il progetto possono gestire le istanze nel progetto di servizio e utilizzare le subnet condivise nel progetto host.

Puoi inserire tutti i progetti di servizio in una cartella e impostare questa policy di autorizzazione specifica a questo livello della gerarchia. In questo modo, tutti i progetti creati in questa cartella ereditano le autorizzazioni impostate nella cartella in cui viene creato il progetto di servizio.

Devi anche 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'utilizzo di gruppi per gestire i principal. Nell'esempio precedente, aggiungeresti gli ID utente degli utenti che gestiscono i controlli di sicurezza e di rete al gruppo sec-net e gli sviluppatori al gruppo developers. Per modificare chi deve poter eseguire la funzione, dovrai semplicemente modificare l'appartenenza al gruppo, senza dover 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 dispongono delle autorizzazioni per apportare modifiche a qualsiasi impostazione di rete o di sicurezza definita dal team di sicurezza e networking, 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 di rete, sicurezza e sviluppatori.

Le tabelle riportate di seguito illustrano i ruoli IAM che devono essere concessi al team di sicurezza e amministrazione e al team di sviluppo, nonché il livello di risorsa a cui vengono concessi i ruoli.

Risorsa: Organizzazione
Ruoli: Amministratore del VPC condiviso
Amministratore di rete
Entità: Team di amministratori di rete
Risorsa: Organizzazione
Ruoli: Amministratore sicurezza
Amministratore dell'organizzazione
Entità: Team di sicurezza
Risorsa: Progetto host Questo ruolo concede l'autorizzazione a utilizzare le subnet condivise dalla VPC condivisa.
Ruolo: Utente di 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 impedire questa azione.
Ruolo: compute.instanceAdmin
Entità: Sviluppatori

Per questo scenario sono necessarie tre policy di autorizzazione separate: una per l'organizzazione, una per il progetto host e una per i progetti di servizio.

Il primo criterio di autorizzazione, che deve essere collegato a livello di organizzazione, concede al team di rete i ruoli necessari per amministrare i progetti host VPC condiviso e per gestire tutte le risorse di rete. Ciò include la possibilità di associare progetti di servizio al progetto host. Il ruolo Amministratore rete concede inoltre al team di rete la possibilità di visualizzare, ma non di modificare le regole firewall. Inoltre, concede al team di sicurezza la possibilità di impostare criteri di autorizzazione e gestire regole firewall e 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. Questa policy 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. In questo modo, gli sviluppatori che utilizzano il progetto possono gestire le istanze nel progetto di servizio e utilizzare le subnet condivise nel progetto host.

Puoi inserire tutti i progetti di servizio in una cartella e impostare questa policy di autorizzazione specifica a questo livello della gerarchia. In questo modo, tutti i progetti creati in questa cartella ereditano le autorizzazioni impostate nella cartella in cui 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'azienda digitale vuole dare ai suoi team di sviluppo la possibilità di lavorare in modo autonomo. Non hanno team di amministratori IT centrali e si fidano dei propri team per gestire tutti gli aspetti dei loro progetti.

Nonostante ciò, vogliono anche essere in grado di implementare alcuni controlli blandi per adottare una configurazione più formale man mano che crescono e il loro prodotto diventa GA.

Per implementare questo scenario, a ogni team di sviluppatori viene assegnata una cartella. 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 le policy 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, la creazione di gruppi separati per le attività logiche è una best practice.

Questo approccio facilita la limitazione dell'accesso alle risorse di cui il personale temporaneo ha bisogno o al nuovo personale che deve essere formato prima di poter modificare le risorse di rete. Consente inoltre di modificare 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 e possedere progetti.
Ruoli: Autore progetto
Amministratore cartelle
Entità: Dev Teamleads
Service account
Risorsa: Cartella
Ruoli: Amministratore di rete

Amministratore sicurezza
Entità: Team di rete e sicurezza
Risorsa: Cartella Questi ruoli consentono agli sviluppatori di gestire tutti gli aspetti di BigQuery e Compute Engine.
Ruoli: Amministratore istanza
BigQuery Admin
Entità: Sviluppatori

È necessaria una norma di autorizzazione associata 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"
        ]
    }
  ]
}