Fonctionnement des stratégies

Admettons que l'administrateur crée un groupe appelé HelpDesk dont le travail consiste à gérer les utilisateurs et leurs informations d'identification. Voici une stratégie qui permet cela :

Allow group HelpDesk to manage users in tenancy

Dans la mesure où les utilisateurs résident dans la location (compartiment racine), la stratégie indique simplement le mot tenancy, sans le mot compartment devant lui.

Ensuite, supposons que vous disposez d'un compartiment appelé Project-A et d'un groupe appelé A-Admins dont le travail consiste à gérer toutes les ressources Oracle Cloud Infrastructure du compartiment. Voici un exemple de stratégie qui permet cela :

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

Sachez que la stratégie ci-dessus offre la possibilité d'écrire des stratégies pour ce compartiment, ce qui signifie que le groupe A-Admins peut contrôler l'accès aux ressources du compartiment. Pour plus d'informations, reportez-vous à Attachement de stratégie.

Si vous souhaitez limiter l'accès d'A-Admins au lancement et à la gestion des instances de calcul et des volumes de stockage de blocs (volumes et leurs sauvegardes) dans le compartiment Project-A, mais que le réseau lui-même réside dans le compartiment Networks, la stratégie peut être la suivante :

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 troisième instruction avec le type de ressource virtual-network-family active le processus de lancement de l'instance car le réseau cloud est impliqué. Plus précisément, le processus de lancement crée une carte d'interface réseau virtuelle et l'attache au sous-réseau dans lequel réside l'instance.

Pour obtenir d'autres exemples, reportez-vous à Stratégies courantes.

En général, vous indiquez un groupe ou un compartiment en utilisant son nom dans la stratégie. Cependant, vous pouvez utiliser l'OCID à la place. Veillez simplement à ajouter "id" avant l'OCID. Par exemple :

Allow group

 id ocid1.group.oc1..aaaaaaaaqjihfhvxmumrl3isyrjw3n6c4rzwskaawuc7i5xwe6s7qmnsbc6a

 to manage instance-family in compartment Project-A

Vous pouvez indiquer plusieurs groupes en les séparant par une virgule :

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 stratégies. Voici un récapitulatif des verbes, de celui qui octroie le moins d'accès à celui qui en octroie le plus :

Le verbe fournit un certain type d'accès général (par exemple, inspect vous permet de répertorier et d'obtenir des ressources). Lorsque vous associez ensuite un type d'accès à un type de ressource particulier dans une stratégie (par exemple, Allow group XYZ to inspect compartments in the tenancy), vous octroyez à ce groupe l'accès à un ensemble spécifique de droits d'accès et d'opérations d'API (par exemple, ListCompartments, GetCompartment). Pour obtenir d'autres exemples, reportez-vous à Détails des combinaisons de verbe et de type de ressource. La référence de stratégie comprend un tableau similaire pour chaque service, vous donnant la liste des opérations d'API couvertes pour chaque combinaison de verbe et de type de ressource.

Il existe des exceptions ou des nuances spéciales pour certains types de ressource.

Utilisateurs : l'accès à manage users et à manage groups vous permet d'effectuer n'importe quelle opération sur les utilisateurs et les groupes, y compris créer et supprimer des utilisateurs et des groupes, et ajouter des utilisateurs à des groupes ou en enlever. Pour ajouter des utilisateurs à des groupes ou en enlever sans disposer des droits d'accès de création ou de suppression d'utilisateurs et de groupes, vous avez seulement besoin de use users et use groups. Reportez-vous à Stratégies courantes.

Stratégies : la possibilité de mettre à jour une stratégie n'est disponible que par le biais de manage policies, et non de use policies, car l'effet de la mise à jour est semblable à celui de la création d'une stratégie (vous pouvez écraser les instructions de stratégie existantes). En outre, inspect policies permet d'obtenir tout le contenu des stratégies.

Objets Object Storage : inspect objects vous permet de répertorier tous les objets d'un bucket ainsi que d'effectuer une opération HEAD pour un objet particulier. En comparaison, read objects vous permet de télécharger l'objet lui-même.

Ressources Load Balancer : inspect load-balancers vous permet d'obtenir toutes les informations concernant vos équilibreurs de charge et les composants associés (ensembles de back-ends, etc.).

Ressources Networking :

Oracle définit également les types de ressource que vous pouvez utiliser dans les stratégies. D'abord, il existe des types individuels. Chaque type individuel représente un type spécifique de ressource. Par exemple, le type de ressource vcns concerne spécifiquement les réseaux cloud virtuels.

Pour faciliter l'écriture des stratégies, il existe des types de famille incluant plusieurs types individuels de ressource qui sont souvent gérés ensemble. Par exemple, le type virtual-network-family regroupe différents types liés à la gestion des réseaux cloud virtuels (par exemple, vcns, subnets, route-tables, security-lists, etc.). Si vous devez écrire une stratégie plus granulaire qui donne accès à un seul type individuel de ressource, vous pouvez le faire. Vous pouvez aussi facilement écrire une stratégie pour accorder l'accès à un vaste éventail de ressources.

Dans un autre exemple, Block Volume contient des éléments volumes, volume-attachments et volume-backups. Si vous devez accorder l'accès uniquement à la création de sauvegardes de volumes, vous pouvez spécifier le type de ressource volume-backups dans votre stratégie. Toutefois, si vous devez accorder un accès étendu à toutes les ressources Block Volume, vous pouvez spécifier le type de famille volume-family. Pour obtenir la liste complète des types de ressource de famille, reportez-vous à Types de ressource.

Il existe d'autres méthodes pour définir des stratégies plus précises, comme indiquer des conditions sous lesquelles l'accès est accordé. Pour plus d'informations, reportez-vous à Fonctionnalités de stratégie avancées.

Certaines opérations d'API nécessitent l'accès à plusieurs types de ressource. Par exemple, LaunchInstance nécessite de pouvoir créer des instances et d'utiliser un réseau cloud. L'opération CreateVolumeBackup nécessite un accès au volume et à la sauvegarde de volume. Autrement dit, vous disposerez d'instructions distinctes pour donner accès à chaque type de ressource (pour consulter un exemple, reportez-vous à Autoriser les administrateurs de sauvegarde de volume à gérer uniquement des sauvegardes). Ces instructions individuelles n'ont pas besoin de se trouver dans la même stratégie. De plus, un utilisateur peut obtenir l'accès requis en étant dans différents groupes. Par exemple, George peut se trouver dans un groupe accordant le niveau d'accès requis au type de ressource volumes et dans un autre donnant l'accès requis au type de ressource volume-backups. La somme des instructions individuelles, quel que soit leur emplacement dans l'ensemble global des stratégies, donne à George l'accès à CreateVolumeBackup.

Le concept d'héritage est une fonctionnalité de base des stratégies : les compartiments héritent de toutes les stratégies de leur compartiment parent. L'exemple le plus simple est le groupe d'administrateurs, qui est automatiquement fourni avec votre location (reportez-vous à Stratégie et groupe d'administrateurs). Il existe une stratégie intégrée permettant au groupe d'administrateurs d'effectuer n'importe quelle action dans la location :

Allow group Administrators to manage all-resources in tenancy

En raison de l'héritage de stratégie, le groupe d'administrateurs peut également effectuer n'importe quelle action dans tous les compartiments de la location.

Pour illustrer plus précisément ce concept, imaginez une location avec trois niveaux de compartiments : CompartmentA, CompartmentB et ComparmentC, représentés ci-dessous :

Les stratégies qui s'appliquent aux ressources dans CompartmentA s'appliquent également à celles dans CompartmentB et CompartmentC. La stratégie suivante :

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

permet au groupe NetworkAdmins de gérer les réseaux cloud virtuels dans CompartmentA, CompartmentB et CompartmentC.

Le concept d'attachement est une autre fonctionnalité de base des stratégies. Lorsque vous créez une stratégie, vous devez l'attacher à un compartiment (ou à la location, qui est le compartiment racine). Le compartiment auquel vous l'attachez détermine les personnes pouvant la modifier ou la supprimer. Si vous l'attachez à la location (en d'autres termes, si la stratégie se trouve dans le compartiment racine), tout utilisateur autorisé à gérer les stratégies dans la location peut la modifier ou la supprimer. En règle générale, il s'agit du groupe d'administrateurs ou de tout autre groupe similaire que vous créez et auquel vous accordez un accès étendu. Toute personne ayant uniquement accès à un compartiment enfant ne peut pas modifier ni supprimer cette stratégie.

En revanche, si vous attachez la stratégie à un compartiment enfant, tout utilisateur disposant d'un accès permettant de gérer les stratégies dans ce compartiment peut la modifier ou la supprimer. Dans la pratique, cela signifie qu'il est simple d'accorder des droits d'accès aux administrateurs de compartiment (à savoir, un groupe ayant accès à manage all-resources dans le compartiment) pour qu'ils puissent gérer les stratégies de leur propre compartiment, sans pour autant les autoriser à gérer les stratégies comprises dans le compte. Pour obtenir un exemple qui utilise ce type de conception administrateur de compartiment, reportez-vous à Exemple de scénario. (Rappelez-vous que, en raison de l'héritage de stratégie, les utilisateurs autorisés à gérer les stratégies dans la location peuvent automatiquement gérer celles des compartiments à l'intérieur de la location.)

Le processus d'attachement de la stratégie est simple (que vous l'attachiez à un compartiment ou à la location) : si vous utilisez la console, lorsque vous ajoutez la stratégie à IAM, assurez-vous que vous êtes dans le compartiment souhaité lors de la création de la stratégie. Si vous utilisez l'API, vous indiquez l'OCID du compartiment souhaité (la location ou un autre compartiment) dans le cadre de la demande de création de la stratégie.

Lorsque vous attachez une stratégie à un compartiment, vous devez vous trouver dans ce compartiment et indiquer directement dans l'instruction à quel compartiment elle s'applique. Si vous n'êtes pas dans le compartiment, vous obtiendrez une erreur lorsque vous essayerez d'attacher la stratégie à un autre compartiment. L'attachement a lieu lors de la création de la stratégie, ce qui signifie qu'une stratégie ne peut être attachée qu'à un seul compartiment. Pour savoir comment attacher une stratégie à un compartiment, reportez-vous à Procédure de création d'une stratégie.

Comme décrit dans la section précédente, une instruction de stratégie doit indiquer le compartiment (ou la location) pour lequel l'accès est accordé. L'emplacement de création de la stratégie détermine les utilisateurs qui peuvent la mettre à jour. Si vous attachez la stratégie au compartiment ou à son parent, vous pouvez simplement indiquer le nom du compartiment. Si vous attachez la stratégie plus haut dans la hiérarchie, vous devez indiquer le chemin. Le format du chemin correspond au nom (ou à l'OCID) de chaque compartiment dans le chemin, séparés par le signe deux-points :

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

Par exemple, supposons que vous disposez d'une hiérarchie de compartiment à trois niveaux, présentée ici :

Vous souhaitez créer une stratégie permettant à NetworkAdmins de gérer des réseaux cloud virtuels dans CompartmentC. Si vous voulez attacher cette stratégie à CompartmentC ou à son parent, CompartmentB, écrivez l'instruction de stratégie suivante :

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

Cependant, si vous souhaitez attacher cette stratégie à CompartmentA (afin que seuls les administrateurs de CompartmentA puissent la modifier), écrivez l'instruction de stratégie suivante qui indique le chemin :

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

Pour attacher cette stratégie à la location, écrivez l'instruction de stratégie ci-dessous, qui indique le chemin de CompartmentA vers 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 puisse être modifiée ultérieurement. Par exemple, imaginons que le type de ressource virtual-network-family change afin d'inclure un nouveau type de ressource qui a été ajouté au service Networking. Par défaut, vos stratégies restent automatiquement à jour en tenant compte des modifications apportées à la définition de service. Ainsi, toute stratégie autorisant l'accès à virtual-network-family inclura automatiquement l'accès à la nouvelle ressource.

La référence de stratégie inclut les détails des types spécifiques de ressource pour chaque service, ainsi que les combinaisons de verbe et de type de ressource donnant accès à chaque opération d'API.