Funzionamento dei criteri

Si supponga che l'amministratore crei un gruppo denominato HelpDesk con il compito di gestire gli utenti e le relative credenziali. Di seguito è riportata una politica che consente di:

Allow group HelpDesk to manage users in tenancy

Notare che poiché gli utenti risiedono nella tenancy (compartimento radice), il criterio indica semplicemente la parola tenancy, senza la parola compartment davanti a essa.

Successivamente, supponiamo di disporre di un compartimento denominato Project-A e di un gruppo denominato A-Admins il cui compito è quello di gestire tutte le risorse Oracle Cloud Infrastructure nel compartimento. Di seguito è riportato un criterio di esempio che consente quanto riportato di seguito.

Allow group A-Admins to manage all-resources in compartment Project-A

Tenere presente che il criterio riportato sopra include la possibilità di scrivere i criteri per tale compartimento, il che significa che gli amministratori A possono controllare l'accesso alle risorse del compartimento. Per ulteriori informazioni, vedere Allegato ai criteri.

Se si desidera limitare l'accesso di A-Admin all'avvio e alla gestione solo delle istanze di computazione e dei volumi di storage a blocchi (sia dei volumi che dei relativi backup) nel compartimento Progetto-A, ma la rete stessa vive nel compartimento Reti, il criterio potrebbe invece essere:

Allow group A-Admins to manage instance-family in compartment Project-A

Allow group A-Admins to manage volume-family in compartment Project-A

Allow group A-Admins to use virtual-network-family in compartment Networks

La terza istruzione con il tipo di risorsa virtual-network-family abilita il processo di avvio dell'istanza, poiché è coinvolta la rete cloud. In particolare, il processo di avvio crea una nuova VNIC e la collega alla subnet in cui risiede l'istanza.

Per ulteriori esempi, vedere Criteri comuni.

In genere, nel criterio verrà specificato un gruppo o un compartimento in base al nome. Tuttavia, è possibile utilizzare l'OCID. Assicurarsi di aggiungere "id" prima dell'OCID. Ad esempio:

Allow group

 id ocid1.group.oc1..aaaaaaaaqjihfhvxmumrl3isyrjw3n6c4rzwskaawuc7i5xwe6s7qmnsbc6a

 to manage instance-family in compartment Project-A

È possibile specificare più gruppi separati da virgole:

Allow group A-Admins, B-Admins to manage instance-family in compartment Projects-A-and-B

Oracle definisce i possibili verbi che è possibile utilizzare nei criteri. Ecco un riassunto dei verbi, dal minor numero di accessi al massimo:

Il verbo fornisce un determinato tipo generale di accesso (ad esempio, inspect consente di elencare e ottenere risorse). Quando quindi si accede a quel tipo di accesso con un determinato tipo di risorsa in un criterio (ad esempio, Allow group XYZ to inspect compartments in the tenancy), è possibile concedere a tale gruppo l'accesso a un set specifico di autorizzazioni e operazioni API (ad esempio, ListCompartments, GetCompartment). Per ulteriori esempi, vedere Dettagli per combinazioni Verbi + Tipo di risorsa. Ogni servizio descrive in dettaglio l'elenco delle operazioni API coperte per ogni combinazione di verbo e tipo di risorsa.

alcune eccezioni o sfumature speciali per determinati tipi di risorse.

Utenti: l'accesso sia a manage users che a manage groups consente di eseguire qualsiasi operazione con gli utenti e i gruppi, inclusa la creazione e l'eliminazione di utenti e gruppi, nonché l'aggiunta o la rimozione di utenti dai gruppi. Per aggiungere o rimuovere utenti da gruppi senza accesso alla creazione e all'eliminazione di utenti e gruppi, sono necessari solo use users e use groups. Vedere Criteri comuni.

Criteri: la possibilità di aggiornare un criterio è disponibile solo con manage policies, non con use policies, poiché l'aggiornamento di un criterio è simile a quello della creazione di un nuovo criterio (è possibile sovrascrivere le istruzioni dei criteri esistenti). Inoltre, inspect policies consente di ottenere il contenuto completo dei criteri.

Oggetti di storage degli oggetti: inspect objects consente di elencare tutti gli oggetti in un bucket ed eseguire un'operazione HEAD per un determinato oggetto. In confronto, read objects consente di scaricare l'oggetto stesso.

Risorse del load balancer: tenere presente che inspect load-balancers consente di ottenere tutte le informazioni sui load balancer e sui componenti correlati (set backend e altro ancora).

Risorse di networking:

Oracle definisce inoltre i tipi di risorsa che è possibile utilizzare nei criteri. In primo luogo, esistono tipi singoli. Ogni singolo tipo rappresenta un tipo specifico di risorsa. Ad esempio, il tipo di risorsa vcns è specifico per le reti cloud virtuali (VCN).

Per semplificare la scrittura dei criteri, esistono tipi di famiglia che includono più tipi di risorse individuali che vengono spesso gestiti insieme. Ad esempio, il tipo virtual-network-family riunisce una varietà di tipi relativi alla gestione delle reti VCN (ad esempio, vcns, subnets, route-tables, security-lists e così via). Se è necessario scrivere un criterio più granulare che dia accesso solo a un singolo tipo di risorsa, è possibile. Ma puoi anche scrivere facilmente una politica per dare accesso a una gamma più ampia di risorse.

In un altro esempio: il volume a blocchi contiene volumes, volume-attachments e volume-backups. Se è necessario concedere l'accesso solo alla creazione di backup dei volumi, è possibile specificare il tipo di risorsa volume-backups nel criterio. Tuttavia, se è necessario concedere un ampio accesso a tutte le risorse dei volumi a blocchi, è possibile specificare il tipo di famiglia denominato volume-family. Per un elenco completo dei tipi di risorse della famiglia, vedere Tipi di risorse.

Si noti che esistono altri modi per rendere i criteri più granulari, ad esempio la possibilità di specificare le condizioni alle quali viene concesso l'accesso. Per ulteriori informazioni, vedere Funzioni avanzate dei criteri.

Alcune operazioni API richiedono l'accesso a più tipi di risorsa. Ad esempio, LaunchInstance richiede la possibilità di creare istanze e utilizzare una rete cloud. L'operazione CreateVolumeBackup richiede l'accesso sia al volume che al backup del volume. Ciò significa che saranno disponibili istruzioni separate per concedere l'accesso a ciascun tipo di risorsa (ad esempio, vedere Consenti agli amministratori dei backup dei volumi di gestire solo i backup). Queste singole istruzioni non devono essere nello stesso criterio. E un utente può ottenere l'accesso richiesto dall'essere in gruppi diversi. Ad esempio, George può trovarsi in un gruppo che fornisce il livello di accesso richiesto al tipo di risorsa volumes e in un altro gruppo che fornisce l'accesso richiesto al tipo di risorsa volume-backups. La somma delle singole istruzioni, indipendentemente dalla loro posizione nel set complessivo di criteri, consente a George di accedere a CreateVolumeBackup.

Una funzione di base dei criteri è il concetto di ereditarietà: i compartimenti ereditano qualsiasi criterio dal proprio compartimento padre. L'esempio più semplice è il gruppo Administrators, che viene fornito automaticamente con la tenancy in uso (vedere Gruppo e criteri degli amministratori). È disponibile un criterio integrato che consente al gruppo Administrators di eseguire qualsiasi operazione nella tenancy:

Allow group Administrators to manage all-resources in tenancy

A causa dell'ereditarietà dei criteri, il gruppo di amministratori può eseguire qualsiasi operazione anche in qualsiasi compartimento della tenancy.

Per illustrare ulteriormente, considerare una tenancy con tre livelli di compartimenti: CompartmentA, CompartmentB e ComparmentC, mostrata qui:

I criteri applicabili alle risorse in CompartmentA si applicano anche alle risorse in CompartmentB e CompartmentC. Quindi questa politica:

Allow group NetworkAdmins to manage virtual-network-family in compartment CompartmentA

consente al gruppo NetworkAdmins di gestire le reti VCN in CompartmentA, CompartmentB e CompartmentC.

Un'altra caratteristica di base dei criteri è il concetto di allegato. Quando crei un criterio, devi collegarlo a un compartimento (o alla tenancy, che è il compartimento radice). La posizione alla quale lo associ controlla chi può successivamente modificarlo o eliminarlo. Se la associ alla tenancy (in altre parole, se il criterio si trova nel compartimento radice), chiunque disponga dell'accesso per gestire i criteri nella tenancy potrà quindi modificarlo o eliminarlo. In genere si tratta del gruppo Administrators o di qualsiasi gruppo simile creato e a cui si dispone di un ampio accesso. Chiunque abbia accesso solo a un compartimento figlio non può modificare o eliminare tale criterio.

Se, invece, associ il criterio a un compartimento figlio, tutti gli utenti con accesso per gestire i criteri in tale compartimento possono modificarlo o eliminarlo. In termini pratici, ciò significa che è facile concedere agli amministratori del compartimento (ad esempio, un gruppo che dispone dell'accesso a manage all-resources nel compartimento) l'accesso per gestire i criteri del proprio compartimento, senza garantire loro accesso più esteso per gestire i criteri che risiedono nella tenancy. Per un esempio che utilizza questo tipo di progettazione amministratore compartimento, vedere Scenario di esempio. Ricorda che, a causa dell'ereditarietà dei criteri, gli utenti con accesso per gestire i criteri nella tenancy possono gestire automaticamente i criteri nei compartimenti all'interno della tenancy.

Il processo di collegamento del criterio è semplice (sia che si tratti del collegamento a un compartimento o alla tenancy): se si utilizza la console, quando si aggiunge il criterio a IAM, è sufficiente assicurarsi di trovarsi nel compartimento desiderato quando si crea il criterio. Se si utilizza l'interfaccia API, si specifica l'OCID del compartimento desiderato (la tenancy o un altro compartimento) nell'ambito della richiesta di creazione del criterio.

Quando si collega un criterio a un compartimento, è necessario trovarsi in tale compartimento e è necessario indicare direttamente nell'istruzione a quale compartimento si applica. Se non ci si trova nel compartimento, si verificherà un errore se si tenta di collegare il criterio a un altro compartimento. Tenere presente che il collegamento si verifica durante la creazione del criterio, il che significa che un criterio può essere collegato a un solo compartimento. Per informazioni su come collegare un criterio a un compartimento, vedere Per creare un criterio.

Come descritto nella sezione precedente, un'istruzione criterio deve specificare il compartimento per il quale viene concesso l'accesso (o la tenancy). La posizione in cui si crea il criterio determina chi può aggiornare il criterio. Se si collega il criterio al compartimento o al relativo elemento padre, è sufficiente specificare il nome del compartimento. Se si allega il criterio più in alto nella gerarchia, è necessario specificare il percorso. Il formato del percorso è costituito da ogni nome di compartimento (o OCID) nel percorso, separato dai due punti:

<compartment_level_1>:<compartment_level_2>: . . . <compartment_level_n>

Ad esempio, si supponga di disporre di una gerarchia di compartimenti a tre livelli, mostrata qui:

Si desidera creare un criterio per consentire a NetworkAdmins di gestire le VCN in CompartmentC. Se si desidera allegare questo criterio a CompartmentC o al relativo elemento padre, CompartmentB, scrivere l'istruzione seguente:

Allow group NetworkAdmins to manage virtual-network-family in compartment CompartmentC

Tuttavia, se si desidera allegare questo criterio a CompartmentA (in modo che solo gli amministratori di CompartmentA possano modificarlo), scrivere questa istruzione di criterio che specifica il percorso:

Allow group NetworkAdmins to manage virtual-network-family in compartment CompartmentB:CompartmentC

Per collegare questo criterio alla tenancy, scrivere l'istruzione del criterio che specifica il percorso da CompartmentA a CompartmentC:

Allow group NetworkAdmins to manage virtual-network-family in compartment CompartmentA:CompartmentB:CompartmentC

È possibile che la definizione di un verbo o di un tipo di risorsa possa cambiare in futuro. Si supponga, ad esempio, che il tipo di risorsa virtual-network-family venga modificato per includere un nuovo tipo di risorsa aggiunto alla rete. Per impostazione predefinita, i criteri rimangono automaticamente aggiornati con eventuali modifiche nella definizione del servizio, pertanto qualsiasi criterio di cui si dispone che conceda l'accesso a virtual-network-family includerà automaticamente l'accesso alla risorsa appena aggiunta.

La Panoramica sui criteri IAM include i dettagli dei tipi di risorsa specifici per ciascun servizio e la combinazione di verbo e tipo di risorsa che consente di accedere alle operazioni API.