Vincoli dei criteri dell'organizzazione

Questa pagina fornisce informazioni sui vincoli dei criteri dell'organizzazione che puoi configurare per Cloud NAT.

Gli amministratori di rete possono creare configurazioni Cloud NAT e specificare quali subnet possono utilizzare il gateway. Per impostazione predefinita, non ci sono limiti alle subnet create dall'amministratore o a quali di queste possono utilizzare una configurazione Cloud NAT.

Un amministratore delle policy dell'organizzazione (roles/orgpolicy.policyAdmin) può utilizzare il vincolo constraints/compute.restrictCloudNATUsage per limitare le subnet che possono utilizzare Cloud NAT.

Puoi creare e applicare vincoli organizzativi in una policy dell'organizzazione.

Prerequisiti

Autorizzazioni IAM

  • La persona che crea i vincoli deve disporre del ruolo roles/orgpolicy.policyAdmin.
  • Se utilizzi un VPC condiviso, il ruolo utente deve trovarsi nel progetto host.

Sfondo dei criteri dell'organizzazione

Se non hai mai utilizzato i vincoli delle policy dell'organizzazione, consulta prima la seguente documentazione:

Pianificare i vincoli

Puoi creare vincoli allow o deny ai seguenti livelli della gerarchia delle risorse:

  • Organizzazione
  • Cartella
  • Progetto
  • Subnet

Per impostazione predefinita, un vincolo creato in un nodo viene ereditato da tutti i nodi secondari. Tuttavia, un amministratore delle norme dell'organizzazione per una determinata cartella può decidere se una determinata cartella eredita dalle relative cartelle principali, pertanto l'ereditarietà non è automatica. Per saperne di più, consulta Ereditarietà in Informazioni sulla valutazione della gerarchia.

I vincoli non vengono applicati retroattivamente. Le configurazioni esistenti continuano a funzionare anche se violano i vincoli.

I vincoli sono costituiti dalle impostazioni allow e deny.

Interazione tra valori consentiti e negati

  • Se è configurato un vincolo restrictCloudNatUsage, ma non sono specificati né allowedValues né deniedValues, è consentito tutto.
  • Se allowedValues è configurato e deniedValues non lo è, tutto ciò che non è specificato in allowedValues viene negato.
  • Se deniedValues è configurato e allowedValues non lo è, tutto ciò che non è specificato in deniedValues è consentito.
  • Se vengono configurati sia allowedValues che deniedValues, tutto ciò che non è specificato in allowedValues viene negato.
  • Se due valori sono in conflitto, deniedValues ha la precedenza.

Interazione tra subnet e gateway

I vincoli non impediscono alle subnet di utilizzare un gateway NAT. I vincoli, invece, impediscono una configurazione che violerebbe il vincolo impedendo la creazione di un gateway o di una subnet.

Esempio 1: tentativo di creare una subnet che viola una regola deny

  1. Esiste un gateway in una regione.
  2. Il gateway è configurato per consentire a tutte le subnet di una regione di utilizzarlo.
  3. Nella regione esiste una sola subnet (subnet-1).
  4. Viene creato un vincolo in modo che solo subnet-1 possa utilizzare il gateway.
  5. Gli amministratori non possono creare altre subnet in quella rete in quella regione. Il vincolo impedisce la creazione di subnet che potrebbero utilizzare il gateway. Se le nuove subnet devono esistere, l'amministratore dei criteri dell'organizzazione può aggiungerle all'elenco delle subnet consentite.

Esempio 2: tentativo di creare un gateway che viola una regola deny

  1. Esistono due subnet (subnet-1 e subnet-2) in una regione.
  2. Esiste un vincolo che consente solo a subnet-1 di utilizzare un gateway.
  3. Gli amministratori non possono creare un gateway aperto a tutte le subnet della regione. In alternativa, deve creare un gateway che gestisca solo subnet-1 oppure l'amministratore delle policy dell'organizzazione deve aggiungere subnet-2 all'elenco delle subnet consentite.

Creare i vincoli

Per creare una policy dell'organizzazione con un determinato vincolo, consulta Utilizzo dei vincoli.

Passaggi successivi