Criteri IAM per l'instradamento tra VCN

Informazioni sui criteri IAM utilizzati con i gateway di peering e instradamento dinamico.

Per informazioni sui criteri IAM più generali utilizzati nel networking, vedere Criteri IAM per il networking.

Per i criteri IAM specifici del peering locale o remoto che utilizza i DRG, vedere:

Per i criteri IAM specifici per il peering locale che utilizza GPL, vedere:

Per i criteri IAM specifici per il collegamento di DRG e VCN, vedere:

Controllo dell'istituzione di pari livello

Con i criteri IAM, puoi controllare:

Chi può sottoscrivere la tenancy in un'altra area (obbligatorio per il peering VCN remoto).
Chi nell'organizzazione ha l'autorità di stabilire i peer VCN (ad esempio, vedere i criteri IAM in Impostazione di un peering locale e Impostazione di un peering remoto). L'eliminazione di questi criteri IAM non influisce sui peer esistenti, ma solo sulla possibilità di creare peer futuri.
Per il peering VCN locale tramite un DRG collegato a vicenda nella stessa tenancy e nella stessa area, non sono necessari criteri IAM speciali. Il fatto che il peering possa verificarsi con le reti VCN in una tenancy diversa (che potrebbe appartenere alla tua organizzazione, a Oracle o a terze parti) richiederebbe istruzioni di criteri speciali per abilitare il peering cross-tenancy. Nelle istruzioni, è possibile specificare la tenancy specifica. Per informazioni sul peering VCN locale tramite un DRG collegato reciprocamente in una tenancy diversa ma nella stessa area, vedere Collegamento a VCN in altre tenancy. Per informazioni sul peering VCN remoto (possibilmente in una tenancy diversa), vedere Peering remoto con un DRG legacy.
Chi può gestire le tabelle di instradamento e gli elenchi di sicurezza.

Accordo esplicito richiesto da entrambi i lati

L'instradamento di peering e transito coinvolge due VCN di proprietà della stessa parte o di due diverse parti. Le due parti potrebbero essere entrambe nella tua azienda, ma in diversi reparti. Oppure le due parti potrebbero trovarsi in società completamente diverse (ad esempio, in un modello di fornitore di servizi). Per ulteriori esempi di criteri cross-tenant, vedere Accesso alle risorse di storage degli oggetti tra tenancy.

L'accordo è sotto forma di criteri di Oracle Cloud Infrastructure Identity and Access Management che ogni parte implementa per il compartimento o la tenancy della propria VCN. Se le reti VCN si trovano in tenancy diverse, ogni amministratore deve fornire la propria tenancy OCID e mettere in atto istruzioni di criteri speciali per abilitare il peering. Per i dettagli sui criteri IAM necessari per connettersi a una VCN in un'altra tenancy, vedere Pering remoto con un DRG aggiornato.

Istruzioni `Endorse`, `Admit` e `Define`

Di seguito è riportata una panoramica dei verbi utilizzati in queste istruzioni.

Endorse: indica il set generale di abilità che un gruppo nella propria tenancy può eseguire in altre tenancy. L'istruzione Endorse appartiene sempre alla tenancy che contiene il gruppo di utenti che superano i confini nell'altra tenancy per lavorare con le risorse di tale tenancy. Negli esempi, si fa riferimento a questa tenancy come tenancy di origine.
Admit: indica il tipo di capacità nella propria tenancy che si desidera concedere a un gruppo dell'altra tenancy. L'istruzione Admit appartiene alla tenancy che concede "admittance" alla tenancy. L'istruzione Admit identifica il gruppo di utenti che richiede l'accesso alle risorse dalla tenancy di origine e viene identificata con una corrispondente istruzione Endorse. Negli esempi, si fa riferimento a questa tenancy come tenancy di destinazione.
Define: assegna un alias locale a un OCID tenancy per le istruzioni dei criteri Endorse e Admit. È inoltre necessaria un'istruzione Define nella tenancy di destinazione per assegnare un alias all'OCID del gruppo IAM di origine per le istruzioni Admit.

Includere un'istruzione Define nella stessa entità criterio dell'istruzione Endorse o Admit.

Le istruzioni Endorse e Admit funzionano insieme. Un'istruzione Endorse risiede nella tenancy di origine mentre un'istruzione Admit risiede nella tenancy di destinazione. Senza un'istruzione corrispondente che specifica l'accesso, una determinata istruzione Endorse o Admit non concede alcun accesso. Entrambe le tenancy devono concordare l'accesso.

Importante

Oltre alle istruzioni dei criteri, devi anche effettuare la sottoscrizione a un'area per condividere le risorse tra le varie aree.

Peering remoto con un DRG legacy

Un DRG può connettersi a un altro DRG (e a qualsiasi VCN collegata) in un'altra area a condizione che i compartimenti contenenti il richiedente e il responsabile accettazione dispongano dei criteri corretti. Si tratta di:

Criterio R (attuato dal richiedente):
```
Define group RequestorGrp as <requestorGroupOcid>
Define compartment RequestorComp as <RequestorCompartmentOcid>

Allow group RequestorGrp to manage remote-peering-from in compartment RequestorComp
```
Il richiedente si trova in un gruppo IAM denominato RequestorGrp. Questo criterio consente a chiunque nel gruppo di avviare una connessione da qualsiasi DRG nel compartimento del richiedente (RequestorComp). Il criterio R può essere collegato alla tenancy (compartimento radice) o a RequestorComp. Per informazioni sul motivo per cui è consigliabile associarlo all'uno o all'altro, vedere Nozioni di base sui criteri.
Politica A (attuata dall'accettante):
```
Define group RequestorGrp as <requestorGroupOcid>
Define compartment AcceptorComp as <AcceptorCompartmentOcid>

Allow group RequestorGrp to manage remote-peering-to in compartment AcceptorComp
```
Questo criterio consente al richiedente di connettersi a qualsiasi RPC nel compartimento del responsabile accettazione (AcceptorComp). Questa dichiarazione riflette l'accordo richiesto dall'accettante per la creazione del peering. Il criterio A può essere collegato alla tenancy (compartimento radice) o a AcceptorComp.

Questa immagine mostra i due criteri per le reti VCN in aree diverse ma nella stessa tenancy.

Sia la politica R che la politica A danno accesso a RequestorGrp. Tuttavia, il criterio R ha un tipo di risorsa chiamato remote-peering-from e il criterio A ha un tipo di risorsa chiamato remote-peering-to. Insieme, questi criteri consentono a un utente in RequestorGrp di stabilire la connessione da un RPC nel compartimento del richiedente a un RPC nel compartimento del richiedente. La chiamata API per creare effettivamente la connessione specifica quali due RPC.

Suggerimento

L'autorizzazione concessa da Policy R potrebbe essere già disponibile se il richiedente dispone dell'autorizzazione in un altro criterio per gestire tutti i componenti di networking in RequestorComp. Ad esempio, potrebbe essere presente un criterio di amministrazione di rete generale come il seguente: Allow group NetworkAdmin to manage virtual-network-family in compartment RequestorComp. Se il richiedente si trova nel gruppo NetworkAdmin, dispone già delle autorizzazioni richieste coperte dal criterio R (la virtual-network-family include gli RPC). Inoltre, se il criterio viene scritto per coprire l'intera tenancy (Allow group NetworkAdmin to manage virtual-network-family in tenancy), il richiedente dispone già di tutte le autorizzazioni necessarie in entrambi i compartimenti per stabilire la connessione. In tal caso, la politica A non è richiesta.

Peering remoto con un DRG aggiornato

Sia il richiedente che l'accettante devono garantire che siano in vigore le giuste politiche. Questo esempio mostra i criteri di identità minimi necessari per creare una connessione peering remoto cross-tenancy:

Criterio R (attuato dal richiedente):

Define group requestorGroup as <requestorGroupOcid>
Define compartment requestorCompartment as id <requestorCompartmentOcid>
Define tenancy Acceptor as <AcceptorTenancyOcid>

Allow group requestorGroup to manage remote-peering-from in compartment requestorCompartment
Endorse group requestorGroup to manage remote-peering-to in tenancy Acceptor

Politica A (attuata dall'accettante):

Define group requestorGroup as <requestor-group-ocid>
Define tenancy Requestor as <requestorTenancyOcid>
Define compartment acceptorCompartment as id <acceptorCompartmentOcid>

Admit group requestorGroup of tenancy Requestor to manage remote-peering-to in compartment <acceptorCompartment>

Peering locale che utilizza un GPL (VCN nella stessa tenancy)

In questo caso d'uso, entrambi i VCN si trovano nella stessa tenancy. Se si trovano in tenancy diverse, vedere invece Peering locale mediante un VPG (VCN in tenancy diverse).

Gli amministratori delle reti VCN del richiedente e del ricevente devono assicurarsi che siano in vigore i criteri corretti:

Criterio R (attuato dal richiedente):
```
Define group requestorGrp as <requestorGroupOcid>
Define compartment requestorComp as <requestorCompartmentOcid>

Allow group requestorGrp to manage local-peering-from in compartment requestorComp
```
Il richiedente si trova in un gruppo IAM denominato requestorGrp. Questo criterio consente a chiunque nel gruppo di avviare una connessione da qualsiasi GPL nel compartimento del richiedente (requestorComp). Il criterio R può essere collegato alla tenancy (compartimento radice) o a requestorComp. Per informazioni sul motivo per cui è consigliabile associarlo all'uno o all'altro, vedere Nozioni di base sui criteri.
Politica A (attuata dall'accettante):
```
Define group requestorGrp as <requestorGroupOcid>
Define compartment acceptorComp as id <acceptorCompartmentOcid>

Allow group requestorGrp to manage local-peering-to in compartment acceptorComp
Allow group requestorGrp to inspect vcns in compartment acceptorComp
Allow group requestorGrp to inspect local-peering-gateways in compartment acceptorComp
```
Le istruzioni nel criterio consentono al richiedente di connettersi a qualsiasi GPL nel compartimento del responsabile accettazione (acceptorComp). Questa dichiarazione riflette l'accordo richiesto dall'accettante per la creazione del peering. Il criterio A può essere collegato alla tenancy (compartimento radice) o a acceptorComp.

Suggerimento

Le istruzioni nel criterio A consentono al richiedente di elencare i VCN e i GPL in acceptorComp. Le istruzioni sono necessarie per consentire al richiedente di utilizzare l'interfaccia utente della console per effettuare la selezione da una lista di VCN e GPL in acceptorComp e stabilire la connessione. Il diagramma seguente si concentra solo sulla prima istruzione, che è quella critica che consente la connessione.

Questa immagine mostra i due criteri per le reti VCN nella stessa tenancy.

Sia la politica R che la politica A danno accesso a requestorGrp. Tuttavia, il criterio R ha un tipo di risorsa chiamato local-peering-from e il criterio A ha un tipo di risorsa chiamato local-peering-to. Insieme, questi criteri consentono a un utente in requestorGrp di stabilire la connessione da un GPL nel compartimento del richiedente a un GPL nel compartimento del richiedente. La chiamata API per creare la connessione specifica quali due GPL.

Suggerimento

L'autorizzazione concessa da Policy R potrebbe essere già disponibile se il richiedente dispone dell'autorizzazione in un altro criterio per gestire tutti i componenti di networking in RequestorComp. Ad esempio, potrebbe essere presente un criterio di amministrazione di rete generale come questo:

 Allow group NetworkAdmin to manage virtual-network-family in compartment requestorComp

Se il richiedente si trova nel gruppo NetworkAdmin, dispone già delle autorizzazioni richieste coperte in Policy R (la virtual-network-family include GPL). Inoltre, se il criterio viene scritto per coprire l'intera tenancy invece del solo compartimento requestorComp, il richiedente dispone già di tutte le autorizzazioni necessarie in entrambi i compartimenti per stabilire la connessione. In tal caso, la politica A non è richiesta.

Peering locale che utilizza un GPL (VCN in tenancy diverse)

In questo caso d'uso, le VCN si trovano in tenancy diverse (in altre parole, si tratta di un peering cross-tenancy). Se le VCN si trovano nella stessa tenancy, vedere invece Peering locale mediante un LPG (VCN nella stessa tenancy).

Sia il richiedente che l'accettante devono garantire che siano in vigore le giuste politiche:

Criterio R (attuato dal richiedente):
```
Define tenancy Acceptor as <acceptorTenancyOcid>
Define group requestorGrp as <requestorGroupOcid>
Define compartment requestorComp as id <requestorCompartmentOcid>

Allow group requestorGrp to manage local-peering-from in compartment requestorComp
Endorse group requestorGrp to manage local-peering-to in tenancy Acceptor
Endorse group requestorGrp to associate local-peering-gateways in compartment requestorComp
   with local-peering-gateways in tenancy Acceptor
```
Il richiedente si trova in un gruppo IAM con un OCID assegnato fornito dall'utente. Questo criterio consente a chiunque in quel gruppo di avviare una connessione da qualsiasi GPL nel compartimento del richiedente (requestorComp).

La prima istruzione è un'istruzione Define che assegna un'etichetta descrittiva all'OCID tenancy del accettante. L'istruzione usa "Acceptor" come etichetta, ma potrebbe essere un valore della scelta del richiedente. Tutte le istruzioni Define in un criterio devono essere le prime (in alto).

La seconda istruzione consente a requestorGrp di stabilire una connessione da un GPL nel compartimento del richiedente.

Le istruzioni Allow e Endorse sono obbligatorie perché i GPL si trovano in tenancy diverse. Consentono a requestorGrp di collegare un GPL nella tenancy del richiedente a un GPL nella tenancy del accettante.

Se l'intento è quello di concedere all'utente requestorGrp l'autorizzazione per connettersi a un GPL in qualsiasi tenancy, il criterio sarà simile al seguente:
```
Allow group requestorGrp to manage local-peering-from in compartment requestorComp
Endorse group requestorGrp to manage local-peering-to in any-tenancy
Endorse group requestorGrp to associate local-peering-gateways in compartment requestorComp with local-peering-gateways in any-tenancy
```
Indipendentemente da ciò, il criterio R deve essere collegato alla tenancy (compartimento radice) del richiedente e non al compartimento del richiedente. I criteri che abilitano l'accesso cross-tenancy devono essere collegati alla tenancy. Per ulteriori informazioni sul collegamento dei criteri, vedere Nozioni di base sui criteri.
Politica A (attuata dall'accettante):
```
Define tenancy Requestor as <requestorTenancyOcid>
Define group requestorGrp as <requestorGroupOcid>
Define compartment acceptorComp as id <acceptorCompartmentOcid>

Admit group requestorGrp of tenancy Requestor to manage local-peering-to in compartment acceptorComp
Admit group requestorGrp of tenancy Requestor to associate local-peering-gateways in tenancy Requestor with local-peering-gateways in compartment acceptorComp
```
Simile al criterio del richiedente, questo criterio utilizza in primo luogo le istruzioni Define per assegnare etichette descrittive all'OCID della tenancy del richiedente e all'OCID del gruppo di amministratori del richiedente. Come accennato in precedenza, l'accettante potrebbe utilizzare altri valori per tali etichette, se lo si desidera.

La quarta e la quinta istruzione consentono al requestorGrp di connettersi a un GPL nel compartimento dell'accettore (acceptorComp). Queste istruzioni riflettono l'accordo critico richiesto per la creazione del peering. La parola Admit indica che l'accesso si applica a un gruppo al di fuori della tenancy in cui risiede il criterio.

Il criterio A deve essere collegato alla tenancy (compartimento radice) dell'accettore e non al compartimento dell'accettore.

Questa immagine mostra la posizione dei due criteri per le reti VCN in tenancy diverse.

Collegamento a VCN nella stessa tenancy

Se si desidera che il gruppo di amministratori VCN crei e gestisca i collegamenti della VCN e assegni le tabelle di instradamento DRG ai collegamenti, implementare il criterio riportato di seguito.

define group VcnAdmin as <vcnAdminGroupOcid>

Allow group VcnAdmin to manage vcns in tenancy
Allow group VcnAdmin to manage drgs in tenancy

Nota

Per associare una tabella di instradamento VCN al collegamento, aggiungere la riga aggiuntiva seguente:

Allow group VCN-Admin to manage route-tables in tenancy

Collegamento a VCN in altre tenancy

"Collegamenti cross-tenancy" sono collegamenti VCN speciali utilizzati per connettere un DRG direttamente a una VCN in un'altra tenancy, ma gestiti nella stessa area. La VCN non verrà collegata a un DRG nella propria tenancy. Il criterio di esempio riportato di seguito descrive i requisiti minimi dei criteri IAM per entrambe le tenancy per consentire questo tipo di connessione.

Questo esempio di set di criteri consente il seguente set di azioni:

Gli amministratori DRG nel tenant DRG possono creare un collegamento DRG nel tenant VCN.
Gli amministratori VCN nel tenant VCN possono associare una tabella di instradamento VCN al collegamento (utilizzata quando la VCN collegata è una VCN di transito). Se l'amministratore della VCN dispone di un criterio per gestire tutte le risorse nel tenant della VCN, ha già questa capacità, poiché il collegamento della VCN risiede nella tenancy della VCN.
Gli amministratori VCN non possono modificare l'associazione della tabella di instradamento DRG per il collegamento DRG.

Criterio R (DRG in questa tenancy)

define group vcnAdmin as <vcnAdminGroupOcid>
define group drgAdmin as <drgAdminGroupOcid>
define tenancy acceptorVCN as <acceptorTenancyOcid>

endorse group drgAdmin to manage drg-attachment in tenancy acceptorVCN
admit group vcnAdmin of tenancy acceptorVCN to manage drg in tenancy

vcnAdminGroupOcid è l'OCID del gruppo vcnAdmin che si trova nella tenancy Acceptor e approvato nel criterio Acceptor.

Criterio A (VCN in questa tenancy)

define tenancy requestorDRG as <requestorTenancyOcid>
define group drgAdmin as <drgAdminGroupOcid>
define group vcnAdmin as <vcnAdminGroupOcid>

admit group drgAdmin of tenancy requestorDRG to manage drg-attachment in tenancy
endorse group vcnAdmin to manage drg in tenancy requestorDRG

drgAdminGroupOcid è l'OCID del gruppo drgAdmin presente nella tenancy del richiedente e approvato nel criterio del richiedente.

Documentazione dell'infrastruttura Oracle Cloud