Policy Examples

Here are a few examples of the policies for Data Catalog.

A policy syntax goes like this:

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

For complete details, see policy syntax. For more information on creating policies, see how policies work, policy reference, and policy details for Object Storage.

Data Catalog Policy Examples

You can create policies to define how you want your users to access the data catalog resources. View the data catalog verb to permission mapping to decide which verb meets our access requirements.

The read verb for data-catalogs covers the same permissions and API operations as the inspect verb plus the CATALOG_READ, CATALOG_JOB_DEFINITION_READ, CATALOG_JOB_READ, and CATALOG_WORK_REQUEST_READ permissions and the API operations that they cover such as ListGlossaries, GetCatalog, and so on.

Allow Access to View Data Catalogs in Tenancy

Create this policy to allow a group to view the list of all the data catalogs in the tenancy:

allow group <group-name> to inspect data-catalogs in tenancy
Allow Access in a Specified Compartment

Create this policy to allow a group to perform all the operations listed for CATALOG_READ in a specified compartment:

allow group <group-name> to read data-catalogs in compartment <x>
Allow Access to Manage Data Catalogs

The manage verb includes the same permissions and API operations as the use verb, plus the CATALOG_CREATE, CATALOG_DELETE, and CATALOG_MOVE permissions, which include API operations CreateCatalog, DeleteCatalog, and MoveCatalog respectively.

Create this policy to allow a group to manage all the data catalogs in a specific compartment:

allow group <group-name> to manage data-catalog-family in compartment <x>

Create this policy to allow a group to manage all the data catalogs, except for deleting the data catalogs:

allow group <group-name> to manage data-catalog-family in compartment <x>
 where request.permission !='CATALOG_DELETE'

Create this policy to allow a group to manage all resources in a specified data catalog:

allow group <group-name> to manage data-catalog-family in tenancy
 where target.catalog.id = 'ocid.datacatalog.oc1..<unique_ID>'
Oracle Object Storage Policy Examples

Before you create Oracle Object Storage data assets, you create policies to enable access to the required data objects. After creating these policies, when you harvest the Object Storage data asset, only those data entities that your data catalog instance has access to are listed. You can select the data objects you want to harvest from the displayed list.

At the least, you must have READ permission for all the individual resource types objectstorage-namespaces, buckets, and objects, or for the Object Storage aggregate resource type object-family. For step-by-step instructions, see tutorial Harvesting from Oracle Object Storage.

Resource Principal Policy Examples

As a prerequisite, create a dynamic group that includes the specific data catalog OCID as a resource in the group.

Example:

Any {resource.id = 'ocid.datacatalog.oc1..<unique_ID>'}
Allow Access to Tenancy

Use the following polices if your Data Catalog instance and Object Storage are in the same tenancy:

Allow access to tenancy

  • Create this policy only for the root_compartment to allow access to any object, in any bucket, in any compartment within the tenancy. Because the scope of this policy is the whole tenancy, a child compartment will not have access to the root or the parent compartments.
    allow dynamic-group <dynamic-group-name> to read object-family in tenancy

Allow access to specific buckets

  • Access any object in bucketA or bucketB within a tenancy
    allow dynamic group <dynamic-group-name> to read object-family in tenancy 
    where any {target.bucket.name='bucketA', target.bucket.name='bucketB'}
  • Access any object in bucketA or bucketB within any compartment
    allow dynamic group <dynamic-group-name> to read object-family in compartment <compartment-name>
    where any {target.bucket.name='bucketA', target.bucket.name='bucketB'}
  • Access any object in bucketA or bucketB within any compartment using the compartment OCID
    allow dynamic group <dynamic-group-name> to read object-family in compartment id <compartment_ocid>
    where any {target.bucket.name='bucketA', target.bucket.name='bucketB'}

    To view the compartment OCID in the Console, open the navigation menu, click Identity & Security. Under Identity, click Compartments. Click the compartment link for your Object Storage resource. From the Compartment Details page, copy the OCID under Compartment Information.

Allow access to specific compartment

  • Access any bucket within a specific compartment

    allow dynamic-group <dynamic-group-name> to read object-family in compartment <compartment-name>

    When you harvest an Object Storage data asset, data entities from all the buckets in the specified compartment are listed. You can then select the data objects across these buckets for harvesting.

  • Access any bucket within a compartment using the compartment OCID
    allow dynamic-group <dynamic-group-name> to read object-family in compartment id <compartment_ocid>

    To view the compartment OCID in the Console, open the navigation menu, click Identity & Security. Under Identity, click Compartments. Click the compartment link for your Object Storage resource. From the Compartment Details page, copy the OCID under Compartment Information.

Allow Access to a Different Tenancy

Create the following policies as a prerequisite if your Data Catalog instance and Object Storage are in different tenancies.

In catalog tenancy:

  • Define a tenancy tenancy-name1 to identify the Object Storage OCID, and then endorse the dynamic group dynamic-group-name1 to manage object-family in <tenancy-name1>.
    Define tenancy <tenancy-name1> as <object-storage-tenancy-OCID>
    Endorse dynamic-group <dynamic-group-name1> to manage object-family in tenancy <tenancy-name1>

In Object Storage tenancy:

  • Define a tenancy tenancy-name2 with catalog tenancy OCID. Define dynamic-group-name2 with the OCID of dynamic-group-name1 created in the catalog tenancy, and then admit the dynamic-group-name2 to manage object-family in the Object Storage tenancy.
    Define tenancy <tenancy-name2> as <catalog-tenancy-OCID>
    Define dynamic-group <dynamic-group-name2> as <dynamic-group-name1-OCID>
    Admit dynamic-group <dynamic-group-name2> of tenancy <tenancy-name2> to manage object-family in tenancy

Allow access to specific buckets

Access to specific buckets such BucketA or BucketB in a compartment.

In catalog tenancy:

Define tenancy <tenancy-name2> as <object-storage-tenancy-OCID>
Endorse dynamic group <dynamic-group-name1> to manage object-family in compartment <compartmentA> where any {target.bucket.name='bucketA', target.bucket.name='bucketB'}

In Object Storage tenancy:

Define tenancy <tenancy-name1> as <catalog-tenancy-OCID>
Define dynamic-group <dynamic-group-name2> as <dynamic-group-name1-OCID>
Admit dynamic group <dynamic-group-name2> of tenancy <tenancy-name1> to manage object-family in compartment compartmentA where any {target.bucket.name='bucketA', target.bucket.name='bucketB'}

Similarly, you can also access buckets in a compartment using compartment ID.

Allow access to a specific compartment

Access any bucket within a specific compartment using compartment name.

In catalog tenancy:
Define tenancy <tenancy-name2> as <object-storage-tenancy-OCID>
Endorse dynamic group <dynamic-group-name1> to manage object-family in compartment <compartment-name>
In Object Storage tenancy:
Define tenancy <tenancy-name1> as <catalog-tenancy-OCID>
Define dynamic group <dynamic-group-name2> as <dynamic-group-name1-OCID>
admit dynamic group <dynamic-group-name2> of tenancy <tenancy-name1> to manage object-family in compartment <compartment-name>

Simiarly, you can access any bucket within a specific compartment using compartment OCID.

Private Endpoint Policy Examples

For data catalog users to configure private networks, you need to create policies.

Allow Users to Manage Data Catalog Private Endpoints

Create this policy to allow a group to perform all actions on data catalog private endpoints.

allow group <group-name> to manage data-catalog-private-endpoints in tenancy
Allow Users to Manage Networking Resources

Create this policy to allow a group to perform all networking-related operations in tenancy.

allow group <group-name> to manage virtual-network-family in tenancy
Allow Users to View Private Endpoint Error Messages

If you are managing the data catalog private endpoints resource, we recommend that you also have the manage work requests permission. This ensures that you can view the logs and error messages that are encountered while working with private endpoints.

allow group <group-name> to manage work-requests in tenancy
Prevent Users from Deleting Data Catalog Private Endpoints

Create this policy to allow a group to perform all actions on data catalog private endpoints, except deleting them.

allow group <group-name> to manage data-catalog-private-endpoints in tenancy
 where request.permission!='CATALOG_PRIVATE_ENDPOINT_DELETE'
Glossary Policy Examples

You can create policies to define how you want your users to access the glossary resources. View the glossary verb to permission mapping to decide which verb meets our access requirements. For example, INSPECT allows users to view the list of available glossaries and READ allows users to view the details of the glossary and also export the glossary.

Create this policy to allow a group to perform all operations on all the glossaries, categories, and terms available in the tenancy:

allow group <group-name> to manage data-catalog-glossaries in tenancy

Create this policy to allow a group to create, update, and delete terms, categories, and relationships within a specific glossary:

allow group <group-name> to use data-catalog-glossaries in tenancy where target.glossary.key = '<glossary-key>'
Note

You can copy the glossary key for the required glossary from the glossary details page of the user interface.

Create this policy to allow a group to view glossaries and glossary details in a specific compartment:

allow group <group-name> to read data-catalog-glossaries in compartment <x>

Create this policy to allow a group to view the list of all the glossaries available in a specific data catalog in the tenancy:

allow group <group-name> to inspect data-catalog-glossaries in tenancy where target.catalog.id = 'ocid.datacatalog.oc1..<unique_ID>'
Data Asset Policy Examples

You can create policies to define how you want your users to access the data asset resources. View the data asset verb to permission mapping to decide which verb meets our access requirements. For example, INSPECT allows users to view the list of available data assets and READ allows users to view details of the data assets.

Create this policy to allow a group to perform all operations on all the data assets available in a tenancy:

allow group <group-name> to manage data-catalog-data-assets in tenancy

Create this policy to allow a group to use a specific data asset in a tenancy:

allow group <group-name> to use data-catalog-data-assets in tenancy where target.data-asset.key='<data-asset-key>'
Note

You can copy the data asset key for the required data asset from the data asset details page of the user interface.

Create this policy to allow a group to view data asset details (such as connections, folders, data entities, attributes and so on) of all the data assets available in a specific compartment:

allow group <group-name> to read data-catalog-data-assets in compartment <x>

Create this policy to allow a group to view the list of the data assets available in a specific data catalog in a specific compartment:

allow group <group-name> to inspect data-catalog-data-assets in compartment <x> where target.catalog.id = 'ocid.datacatalog.oc1..<unique_ID>'
Security Policy Examples

Prevent Users from Deleting Data Catalog Instances

Create this policy to allow group DataCatalogUsers to perform all actions on data catalogs, except deleting them.

allow group DataCatalogUsers to manage data-catalog-family in tenancy
 where request.permission!='CATALOG_DELETE'