Accesso alle risorse correlate ai cluster tra le tenancy

Scopri i criteri IAM necessari per consentire a una tenancy di accedere alle risorse correlate al cluster in altre tenancy.

Quando si desidera che una tenancy acceda alle risorse in altre tenancy, è necessario creare criteri cross-tenancy.

Se non si ha familiarità con i criteri, vedere Gestione dei domini di Identity e fare riferimento a:

Criteri cross-tenancy

L'organizzazione potrebbe voler condividere le risorse correlate ai cluster con un'altra organizzazione che dispone di una propria tenancy. Potrebbe trattarsi di un'altra business unit della società, di un cliente della società, di una società che fornisce servizi alla società e così via. In casi come questi, sono necessari criteri cross-tenancy oltre ai criteri utente e servizio richiesti descritti nella sezione Configurazione dei criteri per la creazione e la distribuzione del cluster.

Approvare, ammettere e definire i rendiconti

Per accedere e condividere le risorse tra due tenancy, gli amministratori di entrambe le tenancy devono creare istruzioni criteri speciali che specifichino in modo esplicito le risorse a cui è possibile accedere e condividere. Queste istruzioni speciali utilizzano le parole Definisci, Approva e Ammetti.

Ecco una panoramica dei verbi speciali utilizzati nelle istruzioni cross-tenancy:

Approva: indica il set generale di abilità che un gruppo nella propria tenancy può eseguire in altre tenancy. L'istruzione Endorse appartiene sempre alla tenancy con il gruppo di utenti che superano i confini nell'altra tenancy per utilizzare le risorse di tale tenancy. Negli esempi, questa tenancy viene definita tenancy di origine.
Admit: indica il tipo di capacità nella propria tenancy che si desidera concedere a un gruppo di un'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 identificato con l'istruzione Endorse corrispondente. Negli esempi, questa tenancy viene indicata come tenancy di destinazione.
Definisci: assegna un alias a un OCID tenancy per le istruzioni dei criteri Endorse e Admit. È inoltre necessaria un'istruzione Definisci nella tenancy di destinazione per assegnare un alias all'OCID del gruppo IAM di origine per le istruzioni Admit.

Le istruzioni di definizione devono essere incluse nella stessa entità criterio dell'istruzione Endorse o Admit.

Le istruzioni Endorse e Admit funzionano insieme, ma risiedono in criteri separati, uno in ogni tenancy. Senza un'istruzione corrispondente che specifica l'accesso, un'istruzione Endorse o Admit specifica non concede alcun accesso. L'accordo è obbligatorio per entrambe le tenancy.

Criteri di origine

L'amministratore di origine crea istruzioni criteri che approvano un gruppo IAM di origine per gestire le risorse in una tenancy di destinazione.

Di seguito è riportato un esempio di un'ampia istruzione di criteri che avalla il gruppo IAM OKE-Admins affinché esegua qualsiasi operazione con tutte le risorse correlate al cluster in qualsiasi tenancy:

Endorse group OKE-Admins to manage cluster-family in any-tenancy

Per consentire al gruppo IAM di origine di creare cluster nella tenancy di destinazione, l'amministratore di origine deve anche creare istruzioni criteri per approvare il gruppo per gestire le reti virtuali e ispezionare i compartimenti. Ad esempio:

Endorse group OKE-Admins to manage virtual-network-family in any-tenancy
Endorse group OKE-Admins to inspect compartments in any-tenancy

Per scrivere un criterio che riduca l'ambito dell'accesso della tenancy solo alla tenancy di destinazione, l'amministratore di origine deve ottenere l'OCID della tenancy di destinazione dall'amministratore di destinazione e includere tale OCID in un'istruzione dei criteri. Di seguito è riportato un esempio di istruzioni dei criteri che supportano il gruppo IAM OKE-Admins per gestire le risorse correlate al cluster solo in DestinationTenancy.

Define tenancy DestinationTenancy as ocid1.tenancy.oc1..<unique_ID>
Endorse group OKE-Admins to manage cluster-family in tenancy DestinationTenancy

Criteri di destinazione

L'amministratore di destinazione crea le istruzioni dei criteri che:

Definire la tenancy di origine e il gruppo IAM a cui è consentito accedere alle risorse nella tenancy di destinazione. L'amministratore di origine deve fornire gli OCID della tenancy di origine e il gruppo IAM di origine.
Ammettere il gruppo IAM di origine per accedere alle risorse correlate al cluster nella tenancy di destinazione.

Di seguito è riportato un esempio di istruzioni dei criteri che consentono agli amministratori OKE del gruppo IAM della tenancy di origine di eseguire qualsiasi operazione con tutte le risorse correlate al cluster nella tenancy di destinazione.

Define tenancy SourceTenancy as ocid1.tenancy.oc1..<unique_ID>
Define group OKE-Admins as ocid1.group.oc1..<unique_ID>
Admit group OKE-Admins of tenancy SourceTenancy to manage cluster-family in tenancy

Per consentire al gruppo IAM di origine di creare cluster nella tenancy di destinazione, l'amministratore di destinazione deve anche creare istruzioni dei criteri per consentire al gruppo di gestire le reti virtuali e ispezionare i compartimenti nella tenancy di destinazione. Ad esempio:

Admit group OKE-Admins of tenancy SourceTenancy to manage virtual-network-family in tenancy
Admit group OKE-Admins of tenancy SourceTenancy to inspect compartments in tenancy

Di seguito è riportato un esempio di istruzioni dei criteri che avallano il gruppo IAM OKE-Admins nella tenancy di origine per gestire le risorse correlate al cluster solo nel compartimento SharedOKEClusters.

Define tenancy SourceTenancy as ocid1.tenancy.oc1..<unique_ID>
Define group OKE-Admins as ocid1.group.oc1..<unique_ID>
Admit group OKE-Admins of tenancy SourceTenancy to manage cluster-family in compartment SharedOKEClusters

Accesso alle immagini personalizzate in altre tenancy durante la creazione o l'aggiornamento dei pool di nodi gestiti

Quando si utilizza l'interfaccia CLI o l'API per creare o aggiornare un pool di nodi gestiti, si specifica l'OCID dell'immagine utilizzata da Kubernetes Engine per eseguire il provisioning dei nodi gestiti nel pool di nodi. Se si specifica l'OCID di un'immagine personalizzata, l'immagine personalizzata può trovarsi nella stessa tenancy del cluster o in una tenancy diversa. Se l'immagine personalizzata si trova in una tenancy diversa, devono esistere criteri per consentire l'accesso all'altra tenancy per la lettura dell'immagine.

Nella tenancy (la tenancy di origine) contenente il cluster con il pool di nodi gestiti di cui si desidera che Kubernetes Engine esegua il provisioning utilizzando un'immagine personalizzata, l'amministratore di origine deve creare istruzioni dei criteri per approvare l'accesso all'immagine personalizzata nella tenancy di destinazione. Ad esempio:

Define tenancy image-tenancy as ocid1.tenancy.oc1...<unique_ID>
Endorse any-user to {INSTANCE_IMAGE_INSPECT, INSTANCE_IMAGE_READ} in tenancy image-tenancy where request.principal.type = 'nodepool'

Nella tenancy contenente l'immagine personalizzata (la tenancy di destinazione), l'amministratore di destinazione deve creare istruzioni dei criteri per ammettere l'accesso dalla tenancy di origine all'immagine personalizzata. Ad esempio:

Define tenancy nodepool-tenancy as ocid1.tenancy.oc1...<unique_ID>
Admit any-user of tenancy nodepool-tenancy to {INSTANCE_IMAGE_INSPECT, INSTANCE_IMAGE_READ} where request.principal.type = 'nodepool'