Fonctionnement des politiques

Supposons que votre administrateur crée un groupe appelé HelpDesk dont la tâche est de gérer les utilisateurs et leurs données d'identification. Voici une politique qui le lui permet :

Allow group HelpDesk to manage users in tenancy

Notez que comme les utilisateurs se trouvent dans la location (compartiment racine), la politique énonce simplement le mot tenancy, sans le mot compartment devant.

Ensuite, supposons que vous ayez un compartiment appelé Project-A, et un groupe appelé A-Admins dont la tâche est de gérer toutes les ressources Oracle Cloud Infrastructure dans le compartiment. Voici un exemple de politique qui le permet :

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

N'oubliez pas que la politique ci-dessus inclut la possibilité d'écrire des politiques pour ce compartiment, ce qui signifie que A-Admins peut contrôler l'accès aux ressources du compartiment. Pour plus d'informations, voir Association de politique.

Si vous vouliez limiter l'accès d'A-Admins au lancement et à la gestion des instances de calcul et des volumes de stockage par blocs (volumes et sauvegardes) dans le compartiment Project-A, alors que le réseau lui-même se trouve dans le compartiment Networks, la politique se présenterait plutôt comme suit :

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

Le troisième énoncé avec le type de ressource virtual-network-family permet le processus de lancement d'instance, car le réseau en nuage est concerné. Concrètement, le processus de lancement crée une nouvelle carte d'interface réseau virtuelle (vNIC) et l'associe au sous-réseau dans lequel se trouve l'instance.

Pour d'autres exemples, voir Politiques courantes.

En général, pour spécifier un groupe ou un compartiment, vous indiquez son nom dans la politique. Vous pouvez également utiliser l'OCID. Veillez à ajouter "id" avant l'OCID. Par exemple :

Allow group

 id ocid1.group.oc1..aaaaaaaaqjihfhvxmumrl3isyrjw3n6c4rzwskaawuc7i5xwe6s7qmnsbc6a

 to manage instance-family in compartment Project-A

Vous pouvez spécifier plusieurs groupes en les séparant par des virgules :

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

Oracle définit les verbes que vous pouvez utiliser dans vos politiques. Voici un sommaire des verbes, de l'accès le plus restreint au plus large :

Le verbe fournit un certain type d'accès général (par exemple, inspect vous permet de lister et d'obtenir les ressources). Lorsque vous associez ensuite ce type d'accès à un type de ressource particulier dans une politique (par exemple, Allow group XYZ to inspect compartments in the tenancy), vous accordez à ce groupe l'accès à un jeu spécifique d'autorisations et d'opérations d'API (par exemple, ListCompartments, GetCompartment). Pour d'autres exemples, voir Informations détaillées sur les combinaisons Verbe + Type de ressource. La rubrique Informations de référence sur les politiques présente un tableau similaire pour chaque service, qui vous fournit une liste des opérations d'API couvertes pour chaque combinaison de verbe et de type de ressource.

Des exceptions spéciales ou des nuances s'appliquent à certains types de ressource.

Utilisateurs : L'accès à manage users et manage groups vous permet d'effectuer toutes les opérations liées aux utilisateurs et groupes, notamment de créer et de supprimer des utilisateurs et des groupes, et d'ajouter des utilisateurs à des groupes ou d'en retirer. Pour ajouter des utilisateurs à des groupes ou en retirer sans accès à la création et à la suppression d'utilisateurs et de groupes, seuls use users et use groups sont requis. Voir Politiques courantes.

Politiques : La possibilité de mettre à jour une politique est disponible uniquement avec manage policies, et non avec use policies, car la mise à jour d'une politique est similaire à celle permettant la création d'une nouvelle politique (vous pouvez remplacer les énoncés existants). De plus, inspect policies vous permet d'obtenir tout le contenu des politiques.

Objets de stockage d'objets : inspect objects vous permet de répertorier tous les objets d'un seau et d'effectuer une opération HEAD sur un objet particulier. En comparaison, read objects vous permet de télécharger l'objet lui-même.

Ressources d'équilibreur de charge : Gardez à l'esprit que inspect load-balancers vous permet d'obtenir toutes les informations sur vos équilibreurs de charge et composants connexes ( jeux dorsaux, etc.).

Ressources de réseau :

Oracle définit également les types de ressource que vous pouvez utiliser dans vos politiques. Tout d'abord, ce sont des types individuels. Chaque type individuel représente un type de ressource particulier. Par exemple, le type de ressource vcns s'applique spécifiquement aux réseaux en nuage virtuels (VCN).

Pour faciliter l'écriture de politiques, les types famille contiennent plusieurs types de ressource individuels qui sont souvent gérés ensemble. Par exemple, le type virtual-network-family regroupe divers types relatifs à la gestion des réseaux en nuage virtuels (notamment, vcns, subnets, route-tables, security-lists, etc.). Si vous devez écrire une politique plus granulaire qui ne permet d'accéder qu'à un seul type de ressource individuel, vous pouvez le faire. Il est également possible d'écrire une politique pour accorder l'accès à un ensemble de ressources plus large.

Autre exemple : Un volume par blocs a des volumes, volume-attachments et volume-backups. Si vous devez donner accès à des sauvegardes de volumes uniquement, vous pouvez spécifier le type de ressource volume-backups dans votre politique. Toutefois, si vous devez permettre un accès étendu à toutes les ressources de volume par blocs, vous pouvez spécifier le type de famille appelé volume-family. Pour une liste complète des types de ressource de famille, voir Types de ressource.

Notez qu'il existe d'autres moyens de rendre les politiques plus granulaires, notamment la possibilité de spécifier des conditions en fonction desquelles l'accès est accordé. Pour plus d'informations, voir Fonctions avancées liées aux politiques.

Certaines opérations d'API requièrent un accès à plusieurs types de ressource. Par exemple, LaunchInstance nécessite de pouvoir créer des instances et d'utiliser un réseau en nuage. L'opération CreateVolumeBackup nécessite l'accès au volume et à la sauvegarde du volume. Autrement dit, vous aurez des énoncés distincts qui permettent d'accéder à chaque type de ressource (pour un exemple, voir Permettre aux administrateurs de sauvegardes de volume de ne gérer que les sauvegardes). Il n'est pas nécessaire que ces énoncés individuels figurent dans la même politique. En outre, un utilisateur peut obtenir l'accès requis en faisant partie de différents groupes. Par exemple, George pourrait figurer dans un groupe offrant le niveau d'accès requis au type de ressource volumes et dans un autre groupe lui donnant l'accès requis au type de ressource volume-backups. La somme des énoncés individuels, quel que soit leur emplacement dans le jeu général de politiques, donne à George l'accès à CreateVolumeBackup.

Une fonction de base des politiques est le concept d'héritage : les compartiments héritent des politiques du compartiment parent. L'exemple le plus simple est le groupe Administrateurs, qui est fourni automatiquement avec votre location (voir Groupe Administrateurs et politique). Il existe une politique intégrée qui permet au groupe Administrateurs d'effectuer toutes les opérations dans la location :

Allow group Administrators to manage all-resources in tenancy

Grâce à l'héritage des politiques, le groupe Administrateurs peut également effectuer toutes les opérations dans tout compartiment de la location.

Pour donner un exemple concret, prenons une location avec trois niveaux de compartiments : CompartmentA, CompartmentB et ComparmentC, présentés ici :

Les politiques qui s'appliquent aux ressources de CompartmentA s'appliquent également aux ressources de CompartmentB et CompartmentC. Ainsi, cette politique :

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

permet au groupe NetworkAdmins de gérer les réseaux en nuage virtuels (VCN) dans CompartmentA, CompartmentB et CompartmentC.

Une autre fonction de base des politiques est le concept d'association. Lorsque vous créez une politique, vous devez l'associer à un compartiment (ou à la location, qui est le compartiment racine). L'emplacement auquel vous l'associez détermine qui peut la modifier ou la supprimer. Si vous l'associez à la location (autrement dit, si la politique se trouve dans le compartiment racine), toute personne ayant accès à la gestion des politiques dans la location peut la modifier ou la supprimer. En général, il s'agit du groupe Administrateurs ou d'un groupe similaire que vous créez et auquel vous donnez un accès étendu. Un utilisateur qui ne peut accéder qu'à un compartiment enfant ne peut pas modifier ni supprimer cette politique.

Si vous associez la politique à un compartiment enfant, toute personne ayant accès à la gestion des politiques dans ce compartiment peut la modifier ou la supprimer. En pratique, cela signifie qu'il est facile d'accorder aux administrateurs du compartiment (c'est-à-dire un groupe autorisé à gérer toutes les resources (manage all-resources) du compartiment) un accès pour qu'ils puissent gérer les politiques de leur propre compartiment, sans pour autant les autoriser à gérer les politiques qui se trouvent dans la location. Pour un exemple de ce type de conception d'administrateur de compartiment, voir Exemple de scénario. (Gardez à l'esprit qu'en raison de l'héritage des politiques, les utilisateurs qui ont accès à la gestion des politiques de la location peuvent automatiquement gérer les politiques des compartiments de la location.)

Le processus d'association de politique est facile (que la politique soit associée à un compartiment ou à la location) : Si vous utilisez la console, lorsque vous ajoutez la politique au service GIA, assurez-vous de vous trouver dans le compartiment voulu lorsque vous créez la politique. Si vous utilisez l'API, vous spécifiez l'OCID du compartiment souhaité (la location ou un autre compartiment) dans le cadre de la demande pour créer la politique.

Lorsque vous associez une politique à un compartiment, vous devez vous trouver dans ce compartiment et vous devez indiquer directement dans l'énoncé à quel compartiment elle s'applique. Si vous n'êtes pas dans le compartiment, vous verrez s'afficher un message d'erreur si vous tentez d'associer la politique à un autre compartiment. Notez que l'association se produit lors de la création de la politique, ce qui signifie qu'une politique ne peut être associée qu'à un seul compartiment. Pour apprendre à associer une politique à un compartiment, voir Pour créer une politique.

Tel qu'il est décrit dans la section précédente, un énoncé de politique doit spécifier le compartiment (ou la location) pour lequel l'accès est accordé. L'emplacement où vous créez la politique détermine qui peut mettre à jour cette politique. Si vous associez la politique au compartiment ou à son parent, il vous suffit de spécifier le nom du compartiment. Si vous associez la politique à un autre emplacement plus haut dans la hiérarchie, vous devez spécifier le chemin d'accès. Le format du chemin d'accès se compose de chaque nom de compartiment (ou OCID) dans le chemin, séparé par un deux-points :

<niveau_compartiment_1> :<niveau_compartiment_2> : . . . <niveau_compartiment_n>

Par exemple, supposons que vous disposiez d'une hiérarchie de compartiments à trois niveaux, comme présentée ci-dessous :

Vous souhaitez créer une politique pour permettre à NetworkAdmins de gérer les réseaux en nuage virtuels dans CompartmentC. Si vous voulez associer cette politique à CompartmentC ou à son parent CompartmentB, écrivez l'énoncé de politique suivant :

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

Toutefois, si vous voulez associer cette politique à CompartmentA (afin que seuls les administrateurs de CompartmentA puissent la modifier), écrivez l'énoncé suivant qui spécifie le chemin d'accès :

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

Pour associer cette politique à la location, écrivez l'énoncé suivant qui spécifie le chemin d'accès de CompartmentA à CompartmentC :

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

Il est possible que la définition d'un verbe ou d'un type de ressource change à l'avenir. Par exemple, supposons que le type de ressource virtual-network-family change pour inclure un nouveau type de ressource ajouté au service de réseau. Par défaut, vos politiques restent automatiquement en phase avec tout changement dans la définition du service. Ainsi, toute politique dont vous disposez qui donne accès à virtual-network-family inclut automatiquement l'accès à la nouvelle ressource ajoutée.

La rubrique Informations de référence sur les politiques contient les détails des types de ressource spécifiques pour chaque service, et indique quelle combinaison de verbe + type de ressource donne accès aux opérations d'API.