Exemples de politique

Utilisez les exemples suivants pour en savoir plus sur les politiques IAM dans le service d'intégration de données.

La syntaxe globale d'un énoncé de politique est la suivante :

allow <subject> to <verb> <resource-type> in <location> where <condition>

Pour une description de chaque variable, voir Syntaxe de politique.

Note

Après avoir ajouté des composants IAM (par exemple, des groupes dynamiques et des énoncés de politique), n'essayez pas d'effectuer les tâches associées immédiatement. Les nouvelles politiques IAM nécessitent environ cinq à 10 minutes pour entrer en vigueur.

Pour exporter et importer des objets, voir Activer l'exportation et l'importation d'espace de travail et d'objets dans l'espace de travail.

Consultez également les politiques du service d'intégration de données pour Oracle Cloud Infrastructure (OCI) du blogue pour identifier les politiques dont vous avez besoin.

Exemples de politique pour activer l'accès au service d'intégration de données et utiliser des espaces de travail

Pour utiliser les espaces de travail du service d'intégration de données, vous devez créer des politiques.

Activer l'utilisation de réseaux privés dans les espaces de travail

Pour utiliser des connexions réseau privées aux sources de données, vous devez autoriser le service d'intégration de données à gérer les réseaux virtuels que vous avez configurés pour l'intégration.

Sans la politique suivante, l'intégration des données échoue.

allow service dataintegration to use virtual-network-family in compartment <compartment-name>

Pour autoriser un groupe à gérer les ressources de réseau d'un compartiment :

allow group <group-name> to manage virtual-network-family in compartment <compartment-name>

Pour les utilisateurs non administrateurs :

allow group <group-name> to use virtual-network-family in compartment <compartment-name>

allow group <group-name> to inspect instance-family in compartment <compartment-name>

Activer l'accès pour lister les utilisateurs et les compartiments

Pour permettre au service d'intégration de données de lister les utilisateurs et les compartiments, vous pouvez utiliser inspect.

allow service dataintegration to inspect users in tenancy

allow group <group-name> to inspect compartments in compartment <target-compartment-name>

Accès permettant de voir les espaces de travail

Pour permettre à un groupe de voir la liste de tous les espaces de travail du service d'intégration de données, vous pouvez utiliser inspect.

Pour voir les espaces de travail dans un compartiment particulier :

allow group <group-name> to inspect dis-workspaces in compartment <compartment-name>

Accès permettant d'obtenir les détails de l'espace de travail

Pour permettre à un groupe de voir la liste de tous les espaces de travail du service d'intégration de données, vous pouvez utiliser inspect.

Le verbe, read, pour dis-workspaces comprend les mêmes autorisations et opérations d'API que inspect, plus l'autorisation DIS_WORKSPACE_READ, et les opérations d'API qu'elle couvre.

Pour permettre à un groupe d'afficher une liste et d'obtenir des détails pour dis-workspaces dans un compartiment particulier, vous pouvez utiliser le verbe, read:

allow group <group-name> to read dis-workspaces in compartment <compartment-name>

Pour permettre à un groupe d'afficher une liste et d'obtenir des détails pour dis-workspaces et les objets qu'il contient dans la location, vous pouvez utiliser :

allow group <group-name> to read dis-workspaces in tenancy

Accès permettant de mettre à jour des espaces de travail

Pour permettre à un groupe de mettre à jour les espaces de travail et les objets qu'ils contiennent, vous pouvez utiliser le verbe use.

Le verbe, use, pour dis-workspaces, comprend les mêmes autorisations et opérations d'API que read et inspect, plus l'autorisation DIS_WORKSPACE_UPDATE et les opérations d'API qu'elle couvre.

Pour permettre à un groupe de mettre à jour dis-workspaces dans un compartiment particulier, vous pouvez utiliser :

allow group <group-name> to use dis-workspaces in compartment <compartment-name>

Pour permettre à un groupe de mettre à jour dis-workspaces et les objets qu'il contient dans la location, vous pouvez utiliser :

allow group <group-name> to use dis-workspaces in tenancy

Pour permettre à un groupe de mettre à jour un espace de travail particulier et aucun autre espace de travail :

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where target.workspace.id = '<workspace-ocid>'

Pour permettre à un groupe de mettre à jour un jeu d'espaces de travail spécifiés :

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where ANY (target.workspace.id = '<workspace-1-ocid>', target.workspace.id = '<workspace-2-ocid>')

Note

Vous pouvez copier l'OCID de l'espace de travail à partir de la console.

Accès permettant de gérer les espaces de travail

Pour permettre à un groupe de gérer les espaces de travail et les objets qu'ils contiennent, vous pouvez utiliser le verbe manage.

Le verbe, manage, pour dis-workspaces, comprend les mêmes autorisations et opérations d'API que inspect, read et use, plus les autorisations DIS_WORKSPACE_CREATE et DIS_WORKSPACE_DELETE, ainsi que les opérations d'API qu'elles couvrent.

Pour permettre à un groupe de gérer dis-workspaces dans un compartiment particulier, vous pouvez utiliser :

allow group <group-name> to manage dis-workspaces in compartment <compartment-name>

Pour permettre à un groupe de gérer dis-workspaces et les objets qu'il contient dans la location, vous pouvez utiliser :

allow group <group-name> to manage dis-workspaces in tenancy

Pour permettre à un groupe de gérer un espace de travail particulier et aucun autre espace de travail :

allow group <group-name> to manage dis-workspaces in compartment <compartment-name> where target.workspace.id = '<workspace-ocid>'

Pour permettre à un groupe de gérer un jeu d'espaces de travail spécifiés :

allow group <group-name> to manage dis-workspaces in compartment <compartment-name> where ANY (target.workspace.id = '<workspace-1-ocid>', target.workspace.id = '<workspace-2-ocid>')

Note

Vous pouvez copier l'OCID de l'espace de travail à partir de la console.

Autoriser la recherche dans les espaces de travail

Pour permettre au service d'intégration de données d'effectuer des recherches dans les espaces de travail d'une location, définissez les politiques suivantes dans le compartiment racine de la location.

allow service dataintegration to {TENANCY_INSPECT} in tenancy
allow service dataintegration to {DIS_METADATA_INSPECT} in tenancy

Autoriser l'exportation et l'importation d'objets dans les espaces de travail

Le service d'intégration de données a besoin de politiques spécifiques pour utiliser l'exportation et l'importation. Voir Configuration et politiques requises dans la rubrique Exportation et importation d'objets.

Le service d'intégration de données doit également accéder aux ressources du stockage d'objets pour l'exportation et l'importation. Voir Exemples de politiques pour activer l'accès au service de stockage d'objets pour OCI.

Exemples de politiques pour configurer l'accès interlocation pour la copie de projet et la copie d'application

Pour créer une application ou un projet dans une location (cible) en copiant des ressources à partir d'une application ou d'un projet existant qui se trouve dans une location différente (source), certaines politiques doivent être configurées dans les locations source et cible.

Pour écrire des énoncés de politique interlocation, vous devez disposer des éléments suivants :

Nom et OCID de la location cible
Nom et OCID de la location source
OCID du groupe d'utilisateurs d'un groupe dont les utilisateurs disposent d'autorisations de lecture et d'écriture sur les espaces de travail source et cible

Dans la location cible :

La location cible est l'endroit où la nouvelle application ou copie de projet doit être créée.

Créer un groupe d'utilisateurs et ajouter des utilisateurs au groupe.

Définissez une politique à l'aide des énoncés suivants :

define tenancy <source-tenancy-name> as <source-tenancy-OCID>

endorse group <group-name> to manage dis-family in tenancy <source-tenancy-name>

endorse group <group-name> to manage dis-workspaces in tenancy <source-tenancy-name>

endorse group <group-name> to read compartments in tenancy <source-tenancy-name>

endorse any-user to read compartments in tenancy <source-tenancy-name> where ALL {request.principal.type = 'disworkspace'}

endorse any-user to manage dis-workspaces in tenancy <source-tenancy-name> where ALL {request.principal.type = 'disworkspace'}

Dans la location source :

La location source dispose de l'espace de travail avec l'application ou le projet existant à copier.

Définissez une politique à l'aide des énoncés suivants :

define tenancy <target-tenancy-name> as <target-tenancy-OCID>

define group <group-name> as <group-OCID>

Pour un accès générique à tous les espaces de travail :

admit group <group-name> of tenancy <target-tenancy-name> to read compartments in tenancy

admit group <group-name> of tenancy <target-tenancy-name> to manage dis-workspaces in tenancy

admit any-user of tenancy <target-tenancy-name> to read compartments in tenancy  where ALL {request.principal.type = 'disworkspace'}

admit any-user of tenancy <target-tenancy-name> to manage dis-workspaces in tenancy where ALL {request.principal.type = 'disworkspace'}

Au lieu d'un accès générique, vous pouvez fournir une autorisation plus détaillée basée sur l'OCID de l'espace de travail source ou la clé d'application source :

admit group <group-name> of tenancy <target-tenancy-name> to manage dis-workspaces in tenancy where source.workspace.id  = '<source-tenancy-workspace-OCID>'

admit group <group-name> of tenancy <target-tenancy-name> to manage dis-workspaces in tenancy where source.application.key = '<source-existing-application-key>'

Exemples d'utilisation d'autorisations et d'API dans une politique

Voici quelques exemples d'utilisation d'autorisations dans une condition :

allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.permission = 'DIS_WORKSPACE_READ'

allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.permission = 'DIS_WORKSPACE_UPDATE'

Voici quelques exemples d'utilisation d'opérations d'API dans une condition :

allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.operation = 'GetWorkspace'

allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.operation = 'UpdateWorkspace'

Note

Plusieurs API peuvent être associées à une même autorisation. Si vous utilisez une autorisation et non une API spécifique dans une politique, vérifiez les autorisations requises pour chaque opération d'API pour vous assurer que la politique couvre les API que vous avez l'intention d'utiliser.

Exemples de politique avec des énoncés conditionnels

Note

Vous pouvez copier l'OCID de l'espace de travail à partir de la console.

Vous utilisez des variables lors de l'ajout de conditions à une politique. Voir Variables générales pour toutes les demandes.

Les politiques comportant des énoncés conditionnels ont une clause where. Par exemple, pour permettre à un groupe de mettre à jour un espace de travail particulier et aucun autre espace de travail :

allow group <group-name> to use dis-workspace in compartment <compartment-name> where target.workspace.id = '<workspace-ocid>'

Pour permettre l'utilisation d'un espace de travail au seul groupe qui l'a créé :

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where target.workspace.createdBy = request.user.id

Pour permettre à un groupe de gérer toutes les ressources du service d'intégration de données, sauf supprimer les espaces de travail :

allow group <group-name> to manage dis-family in compartment <compartment-name> where request.permission != 'DIS_WORKSPACE_DELETE'

Les énoncés de politique qui utilisent une clé dans une clause where permettent aux utilisateurs d'un groupe d'utiliser des espaces de travail dans un compartiment pour lequel cette clé particulière se trouve dans la demande. Par exemple, vous pouvez autoriser un groupe à utiliser uniquement une application spécifique.

Pour restreindre un groupe à exécuter uniquement des tâches dans une application spécifique :

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where any {target.application.key='<application-key>'}

Pour permettre à un groupe de créer des objets (tels que des tâches et des flux de données) uniquement dans un dossier :

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where any {target.folder.key='<folder-key>'}

Pour permettre à un groupe de mettre à jour ou de supprimer un objet particulier, comme un flux de données :

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where any {target.object.key='<object-key>'}

Exemples de politique d'accès au service de stockage d'objets pour OCI

Le service d'intégration de données nécessite une autorisation propre au service de stockage d'objets pour Oracle Cloud Infrastructure pour accéder aux métadonnées et lire et écrire des données.

Pour créer une ressource de données de stockage d'objets et parcourir ses schémas, vous devez appartenir à un groupe d'utilisateurs autorisé à lire le stockage d'objets. Voir Exemples de politique Au nom de.

Pour tester une connexion au service de stockage d'objets, assurez-vous que l'espace de travail ou le compartiment du service d'intégration de données dispose, au minimum, d'un accès READ à objectstorage-namespaces. Voir Exemples de politique principale de ressource.

Pour créer et exécuter un flux de données à l'aide du stockage d'objets en tant que source ou cible, l'espace de travail ou le compartiment doit avoir toutes les politiques mentionnées dans Exemples de politique principale de ressource.

Note

Le contenu de la clause WHERE est facultatif mais requis pour limiter les ressources qui accèdent au service Oracle Cloud Infrastructure Object Storage. Vous pouvez l'utiliser pour affiner l'accès en fonction de besoins spécifiques. Pour appliquer un énoncé de politique à :

Tous les espaces de travail, utilisez WHERE ALL {request.principal.type='disworkspace'}
Un espace de travail particulier, utilisez WHERE ALL {request.principal.id='<workspace-OCID>'}
Vous pouvez copier l'OCD de l'espace de travail à partir de la console.
Tous les espaces de travail d'un compartiment particulier, utilisez WHERE ALL {request.resource.compartment.id = '<<compartment-OCID>'}

Pour des détails complets sur l'écriture de politiques pour contrôler l'accès au service de stockage d'objets, voir Informations détaillées sur le service de stockage d'objets.

Politique principale de ressource

Ces politiques permettent à un espace de travail du service d'intégration de données ou à son compartiment de valider les connexions au service de stockage d'objets pour Oracle Cloud Infrastructure et de lire et écrire des données.

Les politiques requises dépendent du fait que la ressource de données de stockage d'objets et l'espace de travail du service d'intégration de données se trouvent dans la même location ou dans des locations différentes.

Dans la même location

Si l'espace de travail d'intégration de données et la source de données de stockage d'objets sont dans la même location, vous devez créer les politiques suivantes :

allow any-user to read buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>', request.operation = 'GetBucket'}

allow any-user to manage objects in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}

Dans des locations différentes

Si l'espace de travail d'intégration de données et la source de données de stockage d'objets se trouvent dans des locations différentes, vous devez créer les politiques suivantes :

Dans la location de l'espace de travail :


Endorse any-user to read buckets in tenancy <tenancy-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.operation = 'GetBucket'}


Endorse any-user to manage objects in tenancy <tenancy-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>'}


Endorse any-user to manage buckets in tenancy <tenancy-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.permission = 'PAR_MANAGE'}


Endorse any-user to inspect compartments in tenancy <tenancy-name> where ALL {request.principal.type = 'disworkspace'}

Dans la location du stockage d'objets :

Admit any-user of tenancy <tenancy-name> to read buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.operation = 'GetBucket'}


Admit any-user of tenancy <tenancy-name> to manage objects in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>'}


Admit any-user of tenancy <tenancy-name> to manage buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.permission = 'PAR_MANAGE'}


Admit any-user of tenancy <tenancy-name> to inspect compartments in tenancy

Exemples de politique Au nom de

Ces politiques permettent à l'utilisateur connecté de lister et de parcourir les compartiments, les seaux de stockage d'objets et les objets en fonction des autorisations qui lui ont déjà été affectées.

Dans la même location

Si l'espace de travail d'intégration de données et la ressource de données de stockage d'objets appartiennent à la même location, l'utilisateur (ou le groupe auquel appartient l'utilisateur) doit avoir accès au stockage d'objets :

allow group <group-name> to use object-family in compartment <compartment-name>

Dans des locations différentes

Si l'espace de travail d'intégration de données et la ressource de données de stockage d'objets se trouvent dans des locations différentes, vous devez créer les politiques suivantes :

Dans la location de l'espace de travail :

Define tenancy <any-name1> as <object-storage-tenancy-OCID>

Endorse group <group-name> to inspect compartments in tenancy <any-name1>

Endorse group <group-name> to use object-family in tenancy <any-name1>

Dans la location du stockage d'objets :

Define tenancy <any-name2> as <workspace-tenancy-OCID>

Define group <workspace-tenancy-group-name> as <workspace-tenancy-group-OCID>

Admit group <group-name> of tenancy <any-name2> to inspect compartments in tenancy

Admit group <group-name> of tenancy <any-name2> to use object-family in compartment <compartment-name>

Exemples de politique pour utiliser des bases de données autonomes comme cibles

Lorsque vous utilisez des bases de données Autonomous Data Warehouse ou Autonomous Transaction Processing en tant que base de données cible dans le service d'intégration de données, le stockage d'objets pour OCI est utilisé comme emplacement temporaire pour les données et pour effectuer des opérations. En plus des politiques de stockage d'objets requises, vous devez également créer la politique suivante pour autoriser la préauthentification pour de telles demandes :

allow any-user to manage buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>', request.permission = 'PAR_MANAGE'}

Exemples de politique pour la publication dans le service de flux de données OCI

Pour pouvoir publier des tâches depuis le service d'intégration de données OCI vers le service de flux de données OCI avec des points d'extrémité privés, assurez-vous d'avoir les politiques suivantes.

allow any-user to manage dataflow-application in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}

allow any-user to manage dataflow-run in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}

allow group <group-name> to read dataflow-application in compartment <compartment-name>

allow group <group-name> to manage dataflow-run in compartment <compartment-name>

allow any-user to read dataflow-private-endpoint in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}

allow any-user to read secret-bundles in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}

Pour les utilisateurs non administrateurs, ces politiques sont requises :

allow group <group-name> to inspect dataflow-private-endpoint in compartment <compartment-name>

allow group <group-name> to read secret-bundles in compartment <compartment-name>

Exemples de politique pour accéder au point d'extrémité REST du service d'intelligence artificielle OCI

Pour authentifier l'exécution d'une tâche REST à l'aide du principal de ressource d'application, ajoutez ce qui suit pour obtenir le principal de ressource OCI.

allow any-user to use ai-service-language-family in tenancy where ALL {request.principal.type = 'disapplication', request.principal.id = '<disapplication-ocid>'}

Documentation sur Oracle Cloud Infrastructure

Exemples de politique

Dans la même location

Dans des locations différentes

Dans la même location

Dans des locations différentes