Utilisation des marqueurs pour gérer l'accès
Cette rubrique décrit comment utiliser des marqueurs dans la politique pour définir la portée de l'accès basé sur des marqueurs appliqués au demandeur ou à la cible d'un appel d'autorisation.
À propos du contrôle d'accès basé sur des marqueurs
À l'aide des conditions et d'un jeu de variables de marqueur, vous pouvez écrire une politique pour définir la portée de l'accès basé sur des marqueurs qui ont été appliqués à une ressource. L'accès peut être contrôlé en fonction d'un marqueur qui existe sur la ressource à l'origine de la demande (groupe, groupe dynamique ou compartiment) ou sur la cible de la demande (ressource ou compartiment). Le contrôle d'accès basé sur des marqueurs offre une flexibilité supplémentaire à vos politiques en vous permettant de définir des politiques d'accès à l'aide de marqueurs couvrant des compartiments, des groupes et des ressources.
Si votre organisation choisit de créer des politiques qui utilisent des marqueurs pour gérer l'accès, assurez-vous que les contrôles appropriés sont en place pour régir les utilisateurs autorisés à appliquer des marqueurs. D'autre part, lorsque des politiques sont en place, gardez à l'esprit que l'application de marqueurs à un groupe, à un utilisateur ou à une ressource peut potentiellement accorder l'accès aux ressources.
Avant de créer une politique qui spécifie une cible ou un demandeur, assurez-vous d'avoir pris en compte :
- Tous les demandeurs potentiels (utilisateurs, groupes, groupes dynamiques) qui portent le marqueur
- Toutes les ressources qui portent le marqueur
Avant d'appliquer un marqueur à une ressource, assurez-vous de connaître les politiques en place qui incluent le marqueur et pourraient avoir une incidence sur l'utilisateur ou le groupe ayant accès à la ressource.
Gestion de l'accès à l'aide de marqueurs appliqués à la ressource à l'origine de la demande
Vous pouvez contrôler l'accès en fonction de la valeur d'un marqueur appliqué à :
- Un groupe (d'utilisateurs) demandant l'accès
- Un groupe dynamique (d'instances) demandant l'accès
- Un compartiment dans lequel réside une ressource d'un groupe dynamique
En utilisant des marqueurs dans vos énoncés de politique pour indiquer la portée de l'accès, vous pouvez définir l'accès pour plusieurs groupes au moyen d'un seul énoncé de politique. Vous pouvez également octroyer et révoquer l'accès à des groupes en appliquant ou en supprimant des marqueurs, sans modifier les politiques initiales.
La syntaxe de base de chaque variable est présentée dans le tableau suivant. Notez que la syntaxe est la même pour les marqueurs group et dynamic group, mais que chacun est présenté dans une rangée différente. Pour d'autres exemples d'utilisation, voir Opérateurs pris en charge.
| Marqueur appliqué au demandeur | Syntaxe de variable | Description |
|---|---|---|
|
group |
request.principal.group.tag.{tagNamespace}.{tagKeyDefinition}= '<value>'
Exemple de politique pour le groupe d'utilisateurs :
Tout utilisateur qui appartient à un groupe ayant été marqué avec Operations.Project='Prod' peut gérer des instances dans le compartiment HR. |
Les marqueurs appliqués aux groupes auxquels appartient l'utilisateur sont évalués pour une correspondance. |
|
dynamic group |
request.principal.group.tag.{tagNamespace}.{tagKeyDefinition}= '<value>'
Exemple de politique pour le groupe dynamique :
Les instances qui sont membres du groupe dynamique InstancesA et qui sont également membres d'un groupe dynamique marqué avec Operations.Project='Prod' peuvent gérer les instances dans le compartiment HR. |
Les marqueurs appliqués aux groupes dynamiques auxquels appartient l'instance sont évalués pour une correspondance. |
|
compartment |
request.principal.compartment.tag.{tagNamespace}.{tagKeyDefinition}= '<value>'
Exemple de politique :
Les instances qui sont membres du groupe dynamique InstancesA et qui se trouvent également dans un compartiment marqué avec Operations.Project='Prod' peuvent gérer les instances dans la location. |
Les marqueurs appliqués au compartiment auquel appartient la ressource à l'origine de la demande sont évalués. |
Comme les utilisateurs se trouvent dans le compartiment racine de votre location, les marqueurs doivent être appliqués au compartiment racine pour que ces énoncés de politique fonctionnent.
Gestion de l'accès à l'aide de marqueurs appliqués à la ressource cible
Vous pouvez contrôler l'accès en fonction de la valeur d'un marqueur appliqué à :
- Une ressource
- Un compartiment dans lequel se trouve la ressource cible
La syntaxe de base de ces variables est présentée dans le tableau suivant. Pour d'autres exemples d'utilisation, voir Opérateurs pris en charge.
| Marqueur appliqué à la cible | Syntaxe de variable | Description |
|---|---|---|
|
resource |
target.resource.tag.{tagNamespace}.{tagKeyDefinition}='<value>'
Exemple de politique :
|
Le marqueur appliqué à la ressource cible de la demande est évalué. Des limites s'appliquent aux autorisations pouvant être accordées dans ce type de politique. Pour plus de détails, consultez les sections suivantes de cette rubrique. |
|
compartment |
target.resource.compartment.tag.{tagNamespace}.{tagKeyDefinition}='<value>'
Exemple de politique :
|
Le marqueur appliqué au compartiment cible de la demande est évalué. Pour plus de détails sur la façon dont l'accès est autorisé dans les compartiments imbriqués, voir Hiérarchies de compartiments. |
Les autorisations pour lister une ressource doivent être accordées de façon distincte
Les politiques qui définissent la portée de l'accès en fonction du marqueur appliqué à la ressource cible ne peuvent pas accorder les autorisations vous permettant de retourner une liste de ressources. Par conséquent, les autorisations permettant de lister une ressource doivent être accordées au moyen d'un énoncé de politique supplémentaire. Cela signifie que si vous avez défini une politique telle que :
allow group GroupA to manage all-resources in compartment Operations where target.resource.tag.Operations.Project= 'Prod'
GroupA ne pourra pas lister les ressources qu'il est autorisé à gérer autrement. Les membres de GroupA ne pourront pas utiliser la console pour interagir avec ces ressources et les utilisateurs devront connaître l'OCID de la ressource qu'ils tentent de gérer, ce qui rend également fastidieux l'utilisation de la trousse SDK et de l'interface de ligne de commande.
Pour autoriser GroupA à lister ces ressources, vous devez ajouter un autre énoncé de politique tel que :
allow group GroupA to inspect all-resources in compartment Operations
Cette approche améliore la politique basée sur les marqueurs, car elle permet aux utilisateurs d'utiliser la console plus facilement (en les autorisant à voir la ressource qu'ils veulent gérer), mais limite toujours les autorisations à l'inspection uniquement. Les membres de GroupA ne peuvent effectuer aucune action sur ces ressources, à moins qu'elles ne soient marquées de façon appropriée. Gardez à l'esprit que lors de l'utilisation du contrôle d'accès basé sur des marqueurs, vous devrez probablement étendre l'accès pour profiter de cette flexibilité accrue.
Une autre approche permet d'éviter cette limite consiste à marquer les compartiments contenant les ressources auxquelles vous voulez accorder l'accès. Voici un exemple de politique :
allow group GroupA to manage all-resources in tenancy where target.resource.compartment.tag.Operations.Project= 'Prod'Cette politique permet aux membres de GroupA de gérer toutes les ressources de la location qui sont dans des compartiments comportant le marqueur Operations.Project='Prod'
Les politiques nécessitant un marqueur dans la ressource cible ne peuvent pas octroyer des autorisations de création
Lorsque vous écrivez une politique pour définir la portée de l'accès en fonction de la valeur d'un marqueur sur la ressource, gardez à l'esprit que la politique ne peut pas accorder des autorisations de création. Une demande de création d'une instance échouerait, car la ressource cible n'a pas encore été créée et ne comporte donc pas le marqueur approprié à évaluer. Donc, une politique comme :
allow group GroupA to manage instances in compartment Operations where target.resource.tag.Operations.Project='Prod'
permet aux membres de GroupA d'utiliser et de supprimer des instances marquées avec Operations.Project='Prod', mais pas de créer des instances.
Opérateurs pris en charge
Une politique utilisant ces variables de marqueur peut inclure les opérateurs et types de correspondance suivants :
| Opérateur | Type | Exemple | Description |
|---|---|---|---|
| = | Chaîne |
request.principal.group.tag.MyTagNamespace.MyTag='sample'
|
S'évalue à Vrai si un des groupes auxquels appartient le demandeur est marqué avec la valeur correspondante "sample" pour MyTagNamespace.MyTag. (La valeur est non sensible à la casse.) |
| Modèle |
request.principal.group.tag.MyTagNamespace.MyTag=/*sample/
|
S'évalue à Vrai si l'une des valeurs de MyTagNamespace.MyTag se termine par "sample". (Correspondance de modèle simple non sensible à la casse.) | |
| Variable de politique |
request.principal.group.tag.mytagnamespace.mytag = target.resource.tag.mytagnamespace.mytag
|
S'évalue à Vrai lorsque la ressource spécifiée mytagnamespace.mytag a une valeur qui correspond à la cible spécifiée mytagnamespace.tag. | |
| != | Chaîne |
request.principal.group.tag.MyTagNamespace.MyTag !='sample'
|
S'évalue à Vrai si aucune des valeurs de chaîne de la variable de politique n'est égale à "sample". (Comparaison de chaîne simple non sensible à la casse.) |
| Modèle |
request.principal.group.tag.MyTagNamespace.MyTag !=/*sample/
|
S'évalue à Vrai si aucune valeur de MyTagNamespace.MyTag ne se termine par "sample". (Correspondance de modèle simple non sensible à la casse.) | |
| Variable de politique |
request.principal.group.tag.mytagnamespace.mytag != target.resource.tag.mytagnamespace.mytag
|
S'évalue à Vrai si ni l'un ni l'autre n'est un sous-jeu de l'autre. |
In / Not In
| Opérateur | Type | Exemple | Description |
|---|---|---|---|
| in | Chaîne |
request.principal.group.tag.MyTagNamespace.MyTag in ('sample', 'sample1')
|
La clause est évaluée à Vrai si l'une des valeurs de MyTagNamespace.MyTag pour n'importe quel groupe du principal demandeur courant est égal à "sample" ou "sample1". |
| Modèle |
request.principal.group.tag.MyTagNamespace.MyTag in (/*sample/, /sample1*/)
|
La clause est évaluée à Vrai si l'une des valeurs de MyTagNamespace.MyTag pour tout groupe du principal demandeur courant se termine par "sample" ou commence par "sample1". | |
| Variable de politique |
request.principal.group.tag.MyTagNamespace.MyTag in (target.resource.tag.mytagnamespace.mytag, 'sample')
|
La clause est évaluée à Vrai si l'une des conditions suivantes est remplie : 1 request.principal.group.tag.MyTagNamespace.MyTag ou target.resource.tag.mytagnamespace.mytag est un sous-jeu de l'autre. 2. Toutes les valeurs de chaîne de request.principal.group.tag.MyTagNamespace.MyTag sont égales à "sample". |
|
| not in | Chaîne |
request.principal.group.tag.MyTagNamespace.MyTag not in ('sample', 'sample1')
|
La clause est évaluée à Vrai si aucune des valeurs de MyTagNamespace.MyTag pour aucun groupe du principal demandeur courant n'est égale à "sample" ou "sample1". |
| Modèle |
request.principal.group.tag.MyTagNamespace.MyTag not in (/*sample/, /sample1*/)
|
La clause est évaluée à Vrai si aucune des valeurs de MyTagNamespace.MyTag pour aucun groupe du principal demandeur courant ne se termine par "sample" ou ne commence par "sample1". | |
| Variable de politique |
request.principal.group.tag.MyTagNamespace.MyTag not in (target.resource.tag.mytagnamespace.mytag, 'sample')
|
La clause est évaluée à Vrai si toutes les conditions suivantes sont satisfaites : 1. Ni request.principal.group.tag.MyTagNamespace.MyTag ni target.resource.tag.mytagnamespace.my tag n'est un sous-jeu de l'autre. 2. Aucune des valeurs de chaîne de request.principal.group.tag.MyTagNamespace.MyTag n'est égale à "sample". |
Prise en charge des caractères génériques
Vous pouvez utiliser le caractère * pour faire correspondre toutes les occurrences de {tagNamespace}. {tagKeyDefinition}, quelle que soit la valeur. Dans la politique, vous pouvez placer * entre des guillemets simples '*' ou entre des barres obliques /*/. Par exemple,
allow group GroupA to use all-resources in compartment HR where target.resource.tag.HR.Project= '*'
Dans cet exemple, GroupA peut utiliser toutes les ressources du compartiment HR qui sont marquées avec l'espace de noms et la clé de marqueur : HR.Project avec n'importe quelle valeur.
Limites relatives aux caractères dans les espaces de noms de marqueur et les définitions de clé de marqueur utilisés dans les variables de politique
Les espaces de noms de marqueur et les définitions de clé de marqueur prennent en charge un jeu de caractères plus large que celui autorisé dans les variables de politique. Par conséquent, si vous utilisez des espaces de noms de marqueur et des définitions de clé de marqueur dans des variables, assurez-vous qu'ils incluent uniquement les caractères également pris en charge par les variables de politique. Les caractères pris en charge sont :
a-z, A-Z, 0-9, _, @, -, :
Si des espaces de noms de marqueur ou des clés de marqueur comportent des caractères autres que ceux-ci, vous ne pouvez pas les utiliser dans des variables de politique. Les espaces de nom et les clés de marqueur ne peuvent pas être renommés; vous devez donc créer de nouveaux espaces de nom et définitions de clé de marqueur.
Considérations relatives à la casse
Lorsque vous utilisez des marqueurs dans des politiques, tenez compte du fait que leurs valeurs sont sensibles à la casse. Par exemple :
request.principal.group.tag.MyTagNamespace.MyTag='sample'
est identique à
request.principal.group.tag.MyTagNamespace.MyTag='Sample'
Hiérarchies de compartiments
Lorsque vous écrivez une condition pour permettre l'accès en fonction du marqueur appliqué à un compartiment cible, gardez à l'esprit que cette politique autorise également l'accès à tous les compartiments imbriqués au sein du compartiment marqué. Tous les sous-compartiments du compartiment marqué étant des ressources du compartiment marqué, la politique autorise l'accès.
Par exemple, dans ce scénario :
La politique :
allow group GroupA to use all-resources in tenancy where target.resource.compartment.Operations.Project='ProjectA'permet à GroupA d'utiliser toutes les ressources de CompartmentA, CompartmentA1 et CompartmentA1.1, même si la balise est appliquée uniquement à CompartmentA.
Services pris en charge
Tous les services Oracle Cloud Infrastructure prennent en charge les variables de politique request.principal.compartment, request.principal.group et target.resource.compartment.tag.
Tous les services ne prennent pas en charge la variable de politique target.resource.tag. Le tableau suivant répertorie les services pris en charge. Si le service n'est pas répertorié dans le tableau, c'est qu'il n'est pas pris en charge pour l'instant.
Certains services ont des limites. Consultez le lien approprié dans le tableau.
| Services pris en charge | Informations supplémentaires |
|---|---|
| Passerelle d'API | Voir Limites du service de passerelle d'API. |
| Service de mégadonnées | Voir Limites du service de mégadonnées. |
| Blockchain Platform | Entièrement pris en charge, aucune limite. |
| Volume par blocs | Voir Limites du service de volumes par blocs. |
| Certificats | Entièrement pris en charge, aucune limite. |
| Calculer | Voir Limites du service de calcul. |
| Gestion du calcul | Voir Limites de gestion du service de calcul. |
| Content Management | Voir Limites du service de gestion du contenu. |
| Catalogue de données | Voir Limites du service de catalogue de données. |
| Flux de données | Entièrement pris en charge, aucune limite. |
| Science des données | Voir Limites du service de science des données. |
| Base de données | Voir Limites du service de base de données. |
| Assistant numérique | Voir Limites de Digital Assistant. |
| DNS | Voir Limites du DNS public. |
| Transmission de messages | Entièrement pris en charge, aucune limite. |
| FastConnect | Entièrement pris en charge, aucune limite. |
| Fonctions | Entièrement pris en charge, aucune limite. |
| Vérifications d'état | Entièrement pris en charge, aucune limite. |
| Service IAM | Les ressources prises en charge sont les suivantes : users, groups, policies, dynamic-groups, network-sources et identity-providers
|
| équilibreur de charge; | Voir Limites du service d'équilibrage de charge. |
| MySQL HeatWave | Entièrement pris en charge, aucune limite. |
| Réseau | Voir Limites du service de réseau. |
| NoSQL Database Cloud | Voir Limites du service de réseau. |
| Avis | Entièrement pris en charge, aucune limite. |
| Stockage d'objets | Voir Limites du service de stockage d'objets. |
| Service des quotas | Entièrement pris en charge, aucune limite. |
| Espace de noms de marquage | Voir Limites de l'espace de noms de marquage. |
| Chambre forte | Chiffrement non pris en charge. |
| WAF | Voir Limites du service de pare-feu d'application Web. |
Limites et politiques supplémentaires nécessaires pour des scénarios propres à Target.Resource.Tag
Pour certains services, les autorisations ou types de ressource ne sont pas tous pris en charge. Lorsqu'une autorisation n'est pas prise en charge, cela signifie que même si la ressource est marquée et que l'autorisation est incluse dans le verbe accordant l'accès, cette autorisation n'est pas permise et échoue pour l'opération qu'elle régit. Par exemple, la ressource du service Volumes par blocs volume-backups ne prend pas en charge le contrôle d'accès basé sur des marqueurs pour l'autorisation VOLUME_BACKUP_COPY. Par conséquent, cette politique :
allow group TestGroup to manage volume-backups in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'ne permet pas aux membres du groupe TestGroup d'effectuer l'opération CopyVolumeBackup. Pour accorder cette autorisation à TestGroup, vous devez ajouter un autre énoncé de politique.
En outre, certains scénarios opérationnels ont besoin d'une autorisation pour accéder à plusieurs ressources. Lors de la définition de la portée de l'accès aux marqueurs qui sont appliqués à la ressource cible, vous devez inclure une politique distincte pour chaque ressource concernée par l'opération. De plus, en raison des limites relatives à la liste des ressources et à d'autres autorisations propres au service, des politiques supplémentaires (non définies par la portée du marqueur) sont requises.
Limites du service de passerelle d'API
En plus de la politique de contrôle d'accès basé sur des marqueurs attendue pour les ressources du service de passerelle d'API, vous aurez besoin d'une politique permettant de gérer les autorisations pour api-workrequests.
Voici un exemple de politique avec les autorisations supplémentaires :
allow group TestGroup to manage api-workrequests in compartment Compartment1Limites du service de mégadonnées
En plus de la politique de contrôle d'accès basé sur des marqueurs attendue pour les ressources du service de mégadonnées, vous aurez besoin d'une politique permettant de gérer les autorisations pour cluster-work-requests.
Voici un exemple de politique avec les autorisations supplémentaires :
allow group TestGroup to manage cluster-work-requests in compartment Compartment1Limites du service de volumes par blocs
| Service | Type de ressource avec limites | Autorisations non prises en charge avec la variable de politique target.resource.tag |
|---|---|---|
| Volume par blocs |
backup-policy-assignments
|
BACKUP_POLICY_ASSIGNMENT_DELETE |
volume-backups
|
VOLUME_BACKUP_COPY |
Scénarios nécessitant une politique supplémentaire :
Attacher un volume par blocs à une instance de calcul :
Pour attacher un volume par blocs à une instance de calcul, en plus de la politique de contrôle d'accès basé sur des marqueurs autorisant l'utilisation (verbe use) sur des volumes et des instances, vous aurez besoin d'autorisations supplémentaires.
Par exemple :
allow group TestGroup to use volumes in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
allow group TestGroup to use instances in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'Ces deux politiques permettent aux membres de TestGroup d'utiliser des volumes et des instances de Compartment1, lorsque les ressources ont le marqueur approprié. Pour permettre aux membres d'attacher un volume par blocs à une instance, vous aurez également besoin des politiques accordant les autorisations affichées dans les énoncés suivants :
allow group TestGroup to read instances in compartment Compartment1
allow group TestGroup to manage volume-attachments in compartment Compartment1 where any {request.permission='VOLUME_ATTACHMENT_CREATE', request.permission='VOLUME_ATTACHMENT_DELETE'}Limites du service de calcul
| Service | Type de ressource | Autorisations non prises en charge avec la variable de politique target.resource.tag |
|---|---|---|
| Service de calcul |
instance-console-connection
|
INSTANCE_CONSOLE _CONNECTION_DELETE |
instances
|
INSTANCE_POWER_ACTIONS |
Scénarios nécessitant une politique supplémentaire :
Attacher une instance de calcul à un sous-réseau :
Pour gérer l'attachement du sous-réseau d'une instance de calcul, en plus de la politique de contrôle d'accès basé sur des marqueurs attendue pour instances et subnets, affichée ici :
allow group TestGroup to use subnets in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
allow group TestGroup to manage instances in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'Vous aurez besoin d'autorisations supplémentaires sur vnics :
allow group TestGroup to use vnics in compartment Compartment1 where ANY{request.permission='VNIC_ATTACH', request.permission='VNIC_CREATE'}Supprimer une carte vNIC d'une instance de calcul :
Pour supprimer une carte vNIC d'une instance de calcul, en plus de la politique de contrôle d'accès basé sur des marqueurs attendue pour instances et subnets affichée ici :
allow group TestGroup to manage instances in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
allow group TestGroup to use subnets in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'Vous aurez besoin de la politique vous accordant des autorisations sur vnics :
allow group TestGroup to use vnics in compartment Compartment1 where ANY {request.permission='VNIC_DELETE', request.permission='VNIC_DETACH'}Limites de gestion du service de calcul
| Service | Type de ressource | Autorisations non prises en charge avec la variable de politique target.resource.tag | Notes |
|---|---|---|---|
| Gestion du calcul |
instance-pools
|
Toutes les autorisations | Le type de ressource instance-pools n'est pas pris en charge. |
auto-scaling-configurations
|
AUTO_SCALING_CONFIGURATION_UPDATE | . |
Limites de la gestion de contenu
En plus de la politique de contrôle d'accès basé sur des marqueurs attendue pour les ressources Content Management, vous aurez besoin d'une politique permettant de gérer les autorisations pour oce-work-requests.
Voici un exemple de politique avec les autorisations supplémentaires :
allow group TestGroup to manage oce-requests in compartment Compartment1Limites du service de base de données
| Service | Type de ressource | Autorisations non prises en charge avec la variable de politique target.resource.tag |
|---|---|---|
| Base de données |
all
|
DATABASE_DELETE |
Mettre à jour les marqueurs pour ExaData Infrastructure :
Non pris en charge pour le moment à l'aide de politiques de contrôle d'accès basé sur des marqueurs.
Scénarios nécessitant une politique supplémentaire :
Supprimer un système de base de données :
Pour supprimer ou mettre à jour un système de base de données, en plus de la politique de contrôle d'accès basé sur des marqueurs attendue pour db-systems, affichée ici :
allow group TestGroup to manage db-systems in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Vous aurez besoin de la politique vous accordant des autorisations pour db-backups, db-homes, vnics, subnets et databases. Voici un exemple de politique présentant les autorisations supplémentaires :
allow group TestGroup to manage db-backups in compartment Compartment1 where ANY {request.permission='DB_BACKUP_DELETE', request.permission='DB_BACKUP_INSPECT'}
allow group TestGroup to manage db-homes in compartment Compartment1 where request.permission='DB_HOME_DELETE'
allow group TestGroup to manage vnics in compartment Compartment1 where ANY {request.permission='VNIC_DELETE', request.permission='VNIC_DETACH'}
allow group TestGroup to manage subnets in compartment Compartment1 where request.permission='SUBNET_DETACH'
allow group TestGroup to manage databases in compartment compartment1Déplacer un système de base de données vers un autre compartiment :
Pour déplacer un système de base de données vers un autre compartiment, en plus de la politique de contrôle d'accès basé sur des marqueurs attendue pour db-systems affichée ici :
allow group TestGroup to manage db-systems in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Vous aurez besoin de la politique vous accordant des autorisations pour databases, db-homes et db-backups. Voici un exemple de politique avec les autorisations supplémentaires :
allow group TestGroup to use databases in compartment Compartment1 where request.permission='DATABASE_UPDATE'
allow group TestGroup to manage db-backups in compartment Compartment1 where request.permission='DB_BACKUP_INSPECT'
allow group TestGroup to manage db-homes in compartment Compartment1 where request.permission='DB_HOME_UPDATE'Supprimer une base de données pour un système de base de données Exadata :
Pour supprimer une ressource de base de données pour un système de base de données Exadata, vous devez disposer de la politique de contrôle d'accès basé sur des marqueurs attendue pour db-systems et databases affichée ici :
allow group TestGroup to manage db-systems in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
allow group TestGroup to manage databases in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Vous devez également disposer des autorisations pour db-homes et db-backups. Voici un exemple de politique avec les autorisations supplémentaires :
allow group TestGroup to manage db-homes in compartment Compartment1 where request.permision='DB_HOME_UPDATE'
allow group TestGroup to manage db-backups in compartment Compartment1 where ANY {request.permission='DB_BACKUP_DELETE', request.permission='DB_BACKUP_INSPECT'}Supprimer une base de données :
La suppression d'une base de données pour un système de base de données sur machine virtuelle ou sans système d'exploitation n'est pas prise en charge à l'aide de politiques basées sur des marqueurs pour la ressource cible.
Créer une sauvegarde de base de données :
Pour créer une sauvegarde de base de données, vous aurez besoin de la politique de contrôle d'accès basé sur des marqueurs attendue pour databases :
allow group TestGroup to manage databases in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Vous devrez également disposer des autorisations pour db-backups. Voici un exemple de politique avec les autorisations supplémentaires :
allow group TestGroup to manage db-backups in compartment Compartment1 where request.permission='DB_BACKUP_CREATE'Restaurer une base de données :
Pour restaurer une sauvegarde de base de données, vous avez besoin de la politique de contrôle d'accès basé sur des marqueurs attendue pour databases :
allow group TestGroup to manage databases in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Vous avez également besoin d'autorisations pour backups, comme celle affichée ici :
allow group TestGroup to manage db-backups in compartment Compartment1 where ANY {request.permission='DB_BACKUP_INSPECT', request.permission='DB_BACKUP_CONTENT_READ'}Créer une association Data Guard :
La création d'une association Data Guard n'est pas prise en charge à l'aide des politiques basées sur des marqueurs pour la ressource cible.
Limites du service de catalogue de données
En plus de la politique de contrôle d'accès basé sur des marqueurs attendue pour les ressources du service de catalogue de données, vous aurez besoin des politiques supplémentaires suivantes pour data-catalog-family :
allow group resource_managers to read data-catalog-family in tenancy where request.operation = 'GetWorkRequest'
allow group resource_managers to read data-catalog-family in tenancy where request.operation = 'ListWorkRequestErrors'
allow group resource_managers to read data-catalog-family in tenancy where request.operation = 'listworkrequestlogs'Limites du service de science des données
En plus de la politique de contrôle d'accès basé sur des marqueurs attendue pour les ressources du service de science des données, vous aurez besoin d'une politique permettant de gérer les autorisations pour data-science-work-requests.
Voici un exemple de politique avec les autorisations supplémentaires :
allow group TestGroup to manage data-science-work-requests in compartment Compartment1Limites de Digital Assistant
| Service | Type de ressource | Autorisations non prises en charge avec la variable de politique target.resource.tag |
|---|---|---|
| Assistant numérique |
oda-design
|
Toutes les autorisations |
oda-insights
|
Toutes les autorisations |
En plus de la politique de contrôle d'accès basé sur des marqueurs attendue pour les ressources Oracle Digital Assistant, vous aurez besoin des politiques supplémentaires suivantes pour oda-instances :
allow group TestGroup to inspect oda-instances in compartment Compartment1
allow group TestGroup to read oda-instances in compartment Compartment1 request.operation = 'GetWorkRequest'
allow group TestGroup to read oda-instances in compartment Compartment1 request.operation = 'ListWorkRequestErrors'
allow group TestGroup to read oda-instances in compartment Compartment1 request.operation = 'listworkrequestlogs'Limites du service d'équilibrage de charge
Scénarios nécessitant une politique supplémentaire :
Mettre à jour un équilibreur de charge :
Pour effectuer une mise à jour des équilibreurs de charge, en plus de la politique de contrôle d'accès basé sur des marqueurs attendue pour load-balancers :
allow group TestGroup to manage load-balancers in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Vous avez besoin d'une politique qui autorise l'opération d'API GetWorkRequest. Voici un exemple de politique avec l'autorisation supplémentaire :
allow group TestGroup to read load-balancers in compartment Compartment1 where request.operation = 'GetWorkRequest'
network-security-groupSupprimer un équilibreur de charge :
Pour supprimer un équilibreur de charge, en plus de la politique de contrôle d'accès basé sur des marqueurs attendue pour load-balancers, subnets et network-security-group :
allow group TestGroup to manage load-balancers in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
allow group TestGroup to use subnets in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
allow group TestGroup to use network-security-group in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Vous aurez besoin de ces autorisations supplémentaires pour vnics :
allow group TestGroup to use vnics in compartment Compartment1 where ANY {request.permission = 'VNIC_DETACH', request.permission = 'VNIC_DELETE', request.permission='VNIC_DISASSOCIATE_NETWORK_SECURITY_GROUP'}Limites du service de réseau
| Service | Type de ressource | Autorisations non prises en charge avec la variable de politique target.resource.tag | Notes |
|---|---|---|---|
| Service de réseau |
private-ips
|
PRIVATE_IP_UPDATE PRIVATE_IP_DELETE VNIC_UNASSIGN SUBNET_DETACH |
|
route-tables
|
UPDATE (INTERNET_GATEWAY_DETACH) | La suppression d'une règle de routage n'est pas prise en charge. | |
vnics
|
VNIC_UPDATE VNIC_DELETE |
Attacher une passerelle de service ou une passerelle NAT à une table de routage :
L'attachement d'une passerelle de service ou d'une passerelle NAT à une table de routage n'est pas pris en charge à l'aide de politiques basées sur des marqueurs pour la ressource cible.
Scénarios nécessitant une politique supplémentaire :
Attacher une passerelle de routage dynamique à un réseau en nuage virtuel :
Pour attacher une passerelle de routage dynamique à un réseau en nuage virtuel, en plus de la politique de contrôle d'accès basé sur des marqueurs attendue pour virtual-network-family et vcns :
allow group TestGroup to use virtual-network-family in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
Vous avez besoin de la politique vous accordant des autorisations manage pour drgs. Voici un exemple de politique avec les autorisations supplémentaires :
allow group TestGroup to manage drgs in compartment Compartment1
Limites du service Oracle NoSQL Database Cloud
Les ressources prises en charge sont : nosql-tables, nosql-rows et nosql-indexes.
En plus de la politique de contrôle d'accès basé sur des marqueurs attendue pour les ressources NoSQL Database Cloud, vous aurez besoin des politiques supplémentaires suivantes :
allow group TestGroup to read nosql-tables in compartment Compartment1 where request.operation='ListWorkRequests'allow group TestGroup to read nosql-tables in compartment Compartment1 where request.operation='ListWorkRequestErrors'allow group TestGroup to read nosql-tables in compartment Compartment1 where request.operation='ListWorkRequestLogs'Notez que les politiques précédentes sont requises pour naviguer dans les ressources NoSQL Database Cloud dans la console.
Limites du service de stockage d'objets
| Service | Type de ressource | Autorisations non prises en charge avec la variable de politique target.resource.tag | Notes |
|---|---|---|---|
| Stockage d'objets |
objects
|
Toutes les autorisations liées à l'accès à objects
|
Les objets ne peuvent pas être marqués. |
L'accès aux objets peut être géré à l'aide des marqueurs du seau auquel appartiennent les objets. Utilisez la variable de politique
target.bucket.tag. Voir Autoriser les utilisateurs à écrire des objets dans les seaux de stockage d'objets.Limites du DNS public
En plus de la politique de contrôle d'accès basé sur des marqueurs attendue pour les ressources de dns, vous aurez besoin d'une politique permettant de gérer (manage) les autorisations pour dns-records. Voici un exemple de politique avec les autorisations supplémentaires :
allow group TestGroup to manage dns-records in compartment Compartment1Limites de l'espace de noms de marquage
La politique qui permet à un utilisateur d'accéder à un espace de noms de marqueur basé sur un marqueur de l'espace de noms ne permet pas à l'utilisateur de créer ou de supprimer des définitions de clés de marqueur dans cet espace de noms de marqueur.
Par exemple, la politique :
allow group TestGroup to manage tag-namespaces in compartment Compartment1 where target.resource.tag.TagNS.TagKey='test'Ne permet pas aux utilisateurs de TestGroup de créer ou de supprimer des définitions de clés de marqueur dans les espaces de noms de marqueur marqués avec TagNS.TagKey=' test'.
Limites du service de pare-feu d'application Web
En plus de la politique de contrôle d'accès basé sur des marqueurs attendue pour les ressources du service de pare-feu d'application Web, vous aurez besoin d'une politique permettant de gérer waas-work-request. Voici un exemple de politique avec les autorisations supplémentaires :
allow group TestGroup to manage waas-work-request in compartment Compartment1Exemples illustrés
Exemple d'utilisation de marqueurs appliqués à un groupe
Vous trouverez ci-dessous un exemple illustrant comment utiliser des marqueurs appliqués aux groupes d'utilisateurs pour gérer l'accès aux ressources d'un compartiment.
Supposons que vous ayez trois compartiments : ProjectA, ProjectB et ProjectC
Pour chaque compartiment, il existe une configuration de groupe d'administrateurs : A-Admins, B-Admins et C-Admins.
Chaque groupe d'administrateurs dispose d'un accès complet sur son compartiment au moyen des politiques suivantes :
-
allow group A-Admins to manage all-resources in compartment ProjectA -
allow group B-Admins to manage all-resources in compartment ProjectB -
allow group C-Admins to manage all-resources in compartment ProjectC
Votre organisation a configuré l'espace de noms de marqueur et la clé ci-après pour marquer chaque groupe en fonction de son rôle :
- EmployeeGroup.Role
Certaines valeurs pour ce marqueur sont 'Admin', 'Developer' et 'Test-Engineer'.
Tous vos groupes d'administrateurs sont marqués avec EmployeeGroup.Role='Admin'
Vous voulez maintenant configurer un compartiment Test que les membres des trois projets doivent se partager. Vous voulez donner à Admin l'accès aux trois groupes d'administrateurs existants. Pour ce faire, vous pouvez écrire une politique de ce type :
allow any-user to manage all-resources in compartment Test where request.principal.group.tag.EmployeeGroup.Role='Admin'
Avec cette politique, tous vos groupes d'administration existants ayant ce marqueur ont accès au compartiment Test. De plus, les nouveaux groupes ou groupes existants que vous marquerez avec EmployeeGroup.Role='Admin' dans le futur auront accès au compartiment Test, sans qu'il soit nécessaire de mettre à jour les énoncés de la politique.
Exemple d'utilisation de marqueurs appliqués à une ressource cible
Dans cet exemple, chaque compartiment de projet de votre organisation contient deux compartiments enfants : Test et production. Vous voulez donner à vos ingénieurs de test l'accès aux compartiments Test pour les trois projets. Pour ce faire, créez un marqueur :
ResourceGroup.Role='Test'
puis appliquez-le aux compartiments Test dans chacun de vos compartiments de projet.
Vous pouvez alors utiliser une politique comme :
allow group Testers to use all-resources in tenancy where target.resource.compartment.tag.ResourceGroup.Role='Test'
pour permettre à votre groupe de testeurs d'accéder aux ressources des trois compartiments Test.