Data Catalog Policies

To control who has access to Data Catalog, and the type of access for each group of users, you must create policies.

By default only the users in the Administrators group have access to all Data Catalog resources. For everyone else who's involved with Data Catalog, you must create policies that give them proper rights to Data Catalog resources.

For a complete list of Oracle Cloud Infrastructure policies, see policy reference.

Resource-Types

Data Catalog offers both aggregate and individual resource-types for writing policies.

You can use aggregate resource-types to write fewer policies. For example, instead of allowing a group to manage data-catalogs and data-catalog-data-assets, you can have a policy that allows the group to manage the aggregate resource-type, data-catalog-family.


Aggregate Resource-Type	Individual Resource-Types
`data-catalog-family`	`data-catalogs` `data-catalog-private-endpoints` `data-catalog-metastores` `data-catalog-data-assets` `data-catalog-glossaries` `data-catalog-namespaces`

The APIs covered for the aggregate data-catalog-family resource-type cover the APIs for data-catalogs, data-catalog-private-endpoints, data-catalog-metastores, data-catalog-data-assets, data-catalog-glossaries, and data-catalog-namespaces.

For example,

allow group catalog-admins to manage data-catalog-family in compartment x

is the same as writing the following policies:

allow group catalog-admins to manage data-catalogs in compartment x
allow group catalog-admins to manage data-catalog-private-endpoints in compartment x
allow group catalog-admins to manage data-catalog-metastores in compartment x
allow group catalog-admins to manage data-catalog-data-assets in compartment x
allow group catalog-admins to manage data-catalog-glossaries in compartment x
allow group catalog-admins to manage data-catalog-namespaces in compartment x

Resource-Types for Dynamic Groups

Use Dynamic Groups to group your data catalog resources. For more information, see Creating Dynamic Groups.

If you want to define a Dynamic Group for data catalog resources, use the following resource-types:

datacatalog
datacatalogprivateendpoint
datacatalogmetastore

The following example shows a matching rule which includes all catalogs in a compartment:

Any{resource.type='datacatalog', resource.compartment.id = '<OCID of data catalog compartment>'}

Supported Variables

To add conditions to your policies, you can either use Oracle Cloud Infrastructure general or service-specific variables.


Operations for This Resource Type...	Can Use These Variables...	Variable Type	Comments
`data-catalog-family`	`target.catalog.id`	Entity (OCID)	Not available to use with `CreateCatalog` or work request operations.
`data-catalogs`	`target.catalog.id`	Entity (OCID)	Not available to use with `CreateCatalog` or work request operations.
`data-catalog-data-assets`	`target.catalog.id`	Entity (OCID)	Not available to use with work request operations.
`data-catalog-data-assets`	`target.data-asset.key`	The key is the Universally Unique Identifier (UUID) for the data asset, in a string format. This ID is not an OCID.	Available to use only with data asset operations except for `CreateDataAsset`.
`data-catalog-glossaries`	`target.catalog.id`	Entity (OCID)	Not available to use with work request operations.
`data-catalog-glossaries`	`target.glossary.key`	String The key is the Universally Unique Identifier (UUID) for the glossary, in a string format. This ID is not an OCID.	Available to use only with glossary operations except for `CreateGlossary`.
`data-catalog-namespaces`	`target.catalog.id`	Entity (OCID)	Not available to use with work request operations.
`data-catalog-namespaces`	`target.namespace.key`	The key is the Universally Unique Identifier (UUID) for the namespace, in a string format. This ID is not an OCID.	Available to use only with namespace operations.

Details for Verbs + Resource-Type Combinations

The following tables show the permissions and API operations covered by each verb for Data Catalog. The level of access is cumulative as you go from inspect > read > use > manage. A plus sign (+) in a table cell indicates incremental access compared to the cell directly above it, whereas "no extra" indicates no incremental access.

data-catalogs

The APIs covered for the data-catalogs resource-type are listed here. The APIs are displayed alphabetically for each permission.


INSPECT
Permissions	APIs Fully Covered	APIs Partially Covered
CATALOG_INSPECT	`ListCatalogs`	none
CATALOG_JOB_DEFINITION_INSPECT	`ListJobDefinitions`
CATALOG_JOB_INSPECT	`ListJobs`
CATALOG_JOB_INSPECT	`ListWorkRequests`
READ
Permissions	APIs Fully Covered	APIs Partially Covered
INSPECT +	INSPECT +	none
CATALOG_JOB_DEFINITION_READ	`GetJobDefinition`
CATALOG_JOB_DEFINITION_READ	`ListJobDefinitionPermissions`
CATALOG_JOB_READ	`GetJob`
	`GetJobExecution`
	`GetJobLog`
	`GetJob`
	`GetJobExecution`
	`GetJobLog`
	`ListJobMetrics`
CATALOG_READ	`GetCatalog`
	`GetType`
	`ListCatalogPermissions`
	`ListDataAssetPermissions`
	`ListGlossaries`
	`ListTypes`
	`ListSearchResults`
	`SuggestMatches`
CATALOG_WORK_REQUEST_READ	`GetWorkRequest`
	`ListWorkRequestErrors`
	`ListWorkRequestLogs`
USE
Permissions	APIs Fully Covered	APIs Partially Covered
READ +	READ +	none
CATALOG_UPDATE	`UpdateCatalog`
CATALOG_JOB_DEFINITION_CREATE	`CreateJobDefinition`
CATALOG_JOB_DEFINITION_UPDATE	`UpdateJobDefinition`
CATALOG_JOB_DEFINITION_DELETE	`DeleteJobDefinition`
CATALOG_JOB_CREATE	`CreateJob`
CATALOG_JOB_UPDATE	`UpdateJob`
CATALOG_JOB_DELETE	`DeleteJobDefinition`
CATALOG_ATTACH_CATALOG_PRIVATE_ENDPOINT	`AttachCatalogPrivateEndpoint`
CATALOG_DETACH_CATALOG_PRIVATE_ENDPOINT	`DetachCatalogPrivateEndpoint`
MANAGE
Permissions	APIs Fully Covered	APIs Partially Covered
USE +	USE +	none
CATALOG_CREATE	`CreateCatalog`
CATALOG_DELETE	`DeleteCatalog`
CATALOG_MOVE	`ChangeCatalogCompartment`

data-catalog-private-endpoints

The APIs covered for the data-catalog-private-endpoints resource-type are listed here. The APIs are displayed alphabetically for each permission.


INSPECT
Permissions	APIs Fully Covered	APIs Partially Covered
CATALOG_PRIVATE_ENDPOINT_INSPECT	`ListCatalogPrivateEndpoints`	none
READ
Permissions	APIs Fully Covered	APIs Partially Covered
INSPECT +	INSPECT +	none
CATALOG_PRIVATE_ENDPOINT_READ	`GetCatalogPrivateEndpoint`	none
USE
Permissions	APIs Fully Covered	APIs Partially Covered
READ +	READ +	none
CATALOG_PRIVATE_ENDPOINT_MOVE	`AttachCatalogPrivateEndpoint`
	`DetachCatalogPrivateEndpoint`
	`UpdateCatalogPrivateEndpoint`
MANAGE
Permissions	APIs Fully Covered	APIs Partially Covered
USE +	USE +	none
CATALOG_PRIVATE_ENDPOINT_MOVE	`ChangeCatalogPrivateEndpointCompartment`
CATALOG_PRIVATE_ENDPOINT_CREATE	`CreateCatalogPrivateEndpoint`
CATALOG_PRIVATE_ENDPOINT_DELETE	`DeleteCatalogPrivateEndpoint`

data-catalog-data-assets

The APIs covered for the data-catalog-data-assets resource-type are listed here. The APIs are displayed alphabetically for each permission.


INSPECT
Permissions	APIs Fully Covered	APIs Partially Covered
CATALOG_DATA_ASSET_INSPECT	`ListDataAssets`	none
CATALOG_DATA_ASSET_TAG_INSPECT	`ListAttributeTags`
	`ListDataAssetTags`
	`ListEntityTags`
	`ListFolderTags`
READ
Permissions	APIs Fully Covered	APIs Partially Covered
INSPECT +	INSPECT +	none
CATALOG_DATA_ASSET_READ	`GetAttribute`
	`GetConnection`
	`GetDataAsset`
	`GetEntity`
	`GetFolder`
	`GetPattern`
	`ListAttributes`
	`ListConnections`
	`ListEntities`
	`ListDerivedLogicalEntities`
	`ListFolders`
	`ListPattern`
	`ParseConnection`
	`ValidatePattern`
CATALOG_DATA_ASSET_TAG_READ	`GetAttributeTag`
	`GetDataAssetTag`
	`GetEntityTag`
	`GetFolderTag`
USE
Permissions	APIs Fully Covered	APIs Partially Covered
READ +	READ +	none
CATALOG_DATA_ASSET_UPDATE	`AddDataSelectorPatterns`
	`CreateAttribute`
	`CreateConnection`
	`CreateEntity`
	`CreateFolder`
	`CreatePattern`
	`DeleteAttribute`
	`DeleteConnection`
	`DeleteEntity`
	`DeleteFolder`
	`DeletePattern`
	`ImportConnection`
	`RemoveDataSelectorPatterns`
	`TestConnection`
	`UpdateAttribute`
	`UpdateConnection`
	`UpdateDataAsset`
	`UpdateEntity`
	`UpdateFolder`
	`UpdatePattern`
	`ValidateConnection`
CATALOG_DATA_ASSET_TAG_CREATE	`CreateAttributeTag`
	`CreateDataAssetTag`
	`CreateEntityTag`
	`CreateFolderTag`
CATALOG_DATA_ASSET_TAG_DELETE	`DeleteDataAssetTag`
	`DeleteAttributeTag`
	`DeleteEntityTag`
	`DeleteFolderTag`
CATALOG_DATA_ASSET_TAG_UPDATE	not used
MANAGE
Permissions	APIs Fully Covered	APIs Partially Covered
USE +	USE +	none
CATALOG_DATA_ASSET_CREATE	`CreateDataAsset`
CATALOG_DATA_ASSET_DELETE	`DeleteDataAsset`

data-catalog-glossaries

The APIs covered for the data-catalog-glossaries resource-type are listed here. The APIs are displayed alphabetically for each permission.


INSPECT
Permissions	APIs Fully Covered	APIs Partially Covered
CATALOG_GLOSSARY_INSPECT	`ListGlossaries`	none
READ
Permissions	APIs Fully Covered	APIs Partially Covered
INSPECT +	INSPECT +	none
CATALOG_GLOSSARY_READ	`ExpandTreeForGlossary`
	`ExportGlossary`
	`GetGlossary`
	`GetTerm`
	`GetTermRelationship`
	`ListGlossaryTermRelationships`
	`ListGlossaryTerms`
USE
Permissions	APIs Fully Covered	APIs Partially Covered
READ +	READ +	none
CATALOG_GLOSSARY_UPDATE	`CreateTerm`
	`CreateTermRelationship`
	`UpdateTerm`
	`DeleteTerm`
	`UpdateTermRelationship`
	`DeleteTermRelationship`
	`UpdateGlossary`
	`ImportGlossary`
MANAGE
Permissions	APIs Fully Covered	APIs Partially Covered
USE +	USE +	none
CATALOG_GLOSSARY_CREATE	`CreateGlossary`
CATALOG_GLOSSARY_DELETE	`DeleteGlossary`

data-catalog-namespaces

The APIs covered for the data-catalog-namespaces resource-type are listed here. The APIs are displayed alphabetically for each permission.


INSPECT
Permissions	APIs Fully Covered	APIs Partially Covered
CATALOG_NAMESPACE_INSPECT	`ListNamespaces`	none
READ
Permissions	APIs Fully Covered	APIs Partially Covered
INSPECT +	INSPECT +	none
CATALOG_NAMESPACE_READ	`GetCustomProperty`
	`GetNamespace`
	`ListCustomProperties`
USE
Permissions	APIs Fully Covered	APIs Partially Covered
READ +	READ +	none
CATALOG_NAMESPACE_UPDATE	`AssociateCustomProperty`
	`CreateCustomProperty`
	`DeleteCustomProperty`
	`DisassociateCustomProperty`
	`UpdateCustomProperty`
	`UpdateNamespace`
MANAGE
Permissions	APIs Fully Covered	APIs Partially Covered
USE +	USE +	none
CATALOG_NAMESPACE_CREATE	`CreateNamespace`
CATALOG_NAMESPACE_DELETE	`DeleteNamespace`

data-catalog-metastores

The APIs covered for the data-catalog-metastores resource-type are listed here. The APIs are displayed alphabetically for each permission.


INSPECT
Permissions	APIs Fully Covered	APIs Partially Covered
CATALOG_METASTORE_INSPECT	`ListMetastores`	none
READ
Permissions	APIs Fully Covered	APIs Partially Covered
INSPECT +	INSPECT +	none
CATALOG_METASTORE_READ	`GetMetastore`	none
USE
Permissions	APIs Fully Covered	APIs Partially Covered
READ +	READ +	none
CATALOG_METASTORE_UPDATE	`UpdateMetastore`	none
MANAGE
Permissions	APIs Fully Covered	APIs Partially Covered
USE +	USE +	none
CATALOG_METASTORE_CREATE	`CreateMetastore`
CATALOG_METASTORE_DELETE	`DeleteMetastore`
CATALOG_METASTORE_MOVE	`ChangeMetastoreCompartment`

Permissions Required for Each API Operation

The following table lists the API operations in a logical order, grouped by resource type. The resource types are data-catalogs, data-catalog-private-endpoints, data-catalog-data-assets, data-catalog-glossaries, and data-catalog-namespaces.

For information about permissions, see permissions.

data-catalogs


API Operation	Permissions Required to Use the Operation
`ListCatalogs`	CATALOG_INSPECT
`GetCatalog`	CATALOG_READ
`UpdateCatalog`	CATALOG_UPDATE
`CreateCatalog`	CATALOG_CREATE
`ChangeCatalogCompartment`	CATALOG_MOVE
`DeleteCatalog`	CATALOG_DELETE
`GetType`	CATALOG_READ
`ListTypes`	CATALOG_READ
`ListCatalogPermissions`	CATALOG_READ
`ListDataAssetPermissions`	CATALOG_READ
`ListSearchResults`	CATALOG_READ
`ListWorkRequests`	CATALOG_WORK_REQUEST_INSPECT
`ListRules`	CATALOG_DATA_ASSET_READ
`GetWorkRequest`	CATALOG_WORK_REQUEST_READ
`ListWorkRequestLogs`	CATALOG_WORK_REQUEST_READ
`ListWorkRequestErrors`	CATALOG_WORK_REQUEST_READ
`ListJobDefinitions`	CATALOG_JOB_DEFINITION_INSPECT
`GetJobDefinition`	CATALOG_JOB_DEFINITION_READ
`ListJobDefinitionPermissions`	CATALOG_JOB_DEFINITION_READ
`UpdateJobDefinition`	CATALOG_JOB_DEFINITION_UPDATE
`CreateJobDefinition`	CATALOG_JOB_DEFINITION_CREATE
`DeleteJobDefinition`	CATALOG_JOB_DEFINITION_DELETE
`ListJobs`	CATALOG_JOB_INSPECT
`GetJob`	CATALOG_JOB_READ
`UpdateJob`	CATALOG_JOB_UPDATE
`CreateJob`	CATALOG_JOB_CREATE
`DeleteJob`	CATALOG_JOB_DELETE
`ListJobMetrics`	CATALOG_JOB_READ
`GetJobMetrics`	CATALOG_JOB_READ
`ListJobLogs`	CATALOG_JOB_READ
`GetJobLog`	CATALOG_JOB_READ
`ListJobExecutions`	CATALOG_JOB_READ
`GetJobExecution`	CATALOG_JOB_READ
`UpdateJobExecution`	CATALOG_JOB_UPDATE
`CreateJobExecution`	CATALOG_JOB_UPDATE
`DeleteJobExecution`	CATALOG_JOB_UPDATE
`SuggestMatches`	CATALOG_READ

data-catalog-private-endpoints


API Operation	Permissions Required to Use the Operation
`AttachCatalogPrivateEndpoint`	CATALOG_ATTACH_CATALOG_PRIVATE_ENDPOINT
`DetachCatalogPrivateEndpoint`	CATALOG_DETACH_CATALOG_PRIVATE_ENDPOINT
`ChangeCatalogPrivateEndpointCompartment`	CATALOG_PRIVATE_ENDPOINT_MOVE
`CreateCatalogPrivateEndpoint`	CATALOG_PRIVATE_ENDPOINT_CREATE
`DeleteCatalogPrivateEndpoint`	CATALOG_PRIVATE_ENDPOINT_DELETE
`GetCatalogPrivateEndpoint`	CATALOG_PRIVATE_ENDPOINT_READ
`ListCatalogPrivateEndpoints`	CATALOG_PRIVATE_ENDPOINT_INSPECT
`UpdateCatalogPrivateEndpoint`	CATALOG_PRIVATE_ENDPOINT_UPDATE

data-catalog-data-assets


API Operation	Permissions Required to Use the Operation
`AttachCatalogPrivateEndpoint`	CATALOG_ATTACH_CATALOG_PRIVATE_ENDPOINT
`DetachCatalogPrivateEndpoint`	CATALOG_DETACH_CATALOG_PRIVATE_ENDPOINT
`ChangeCatalogPrivateEndpointCompartment`	CATALOG_PRIVATE_ENDPOINT_MOVE
`CreateCatalogPrivateEndpoint`	CATALOG_PRIVATE_ENDPOINT_CREATE
`DeleteCatalogPrivateEndpoint`	CATALOG_PRIVATE_ENDPOINT_DELETE
`GetCatalogPrivateEndpoint`	CATALOG_PRIVATE_ENDPOINT_READ
`ListCatalogPrivateEndpoints`	CATALOG_PRIVATE_ENDPOINT_INSPECT
`UpdateCatalogPrivateEndpoint`	CATALOG_PRIVATE_ENDPOINT_UPDATE
`ListCatalogs`	CATALOG_INSPECT
`GetCatalog`	CATALOG_READ
`UpdateCatalog`	CATALOG_UPDATE
`CreateCatalog`	CATALOG_CREATE
`ChangeCatalogCompartment`	CATALOG_MOVE
`DeleteCatalog`	CATALOG_DELETE
`GetType`	CATALOG_READ
`ListTypes`	CATALOG_READ
`ListCatalogPermissions`	CATALOG_READ
`ListDataAssetPermissions`	CATALOG_READ
`ListSearchResults`	CATALOG_READ
`ListWorkRequests`	CATALOG_WORK_REQUEST_INSPECT
`GetWorkRequest`	CATALOG_WORK_REQUEST_READ
`ListWorkRequestLogs`	CATALOG_WORK_REQUEST_READ
`ListWorkRequestErrors`	CATALOG_WORK_REQUEST_READ
`ListJobDefinitions`	CATALOG_JOB_DEFINITION_INSPECT
`GetJobDefinition`	CATALOG_JOB_DEFINITION_READ
`ListJobDefinitionPermissions`	CATALOG_JOB_DEFINITION_READ
`UpdateJobDefinition`	CATALOG_JOB_DEFINITION_UPDATE
`CreateJobDefinition`	CATALOG_JOB_DEFINITION_CREATE
`DeleteJobDefinition`	CATALOG_JOB_DEFINITION_DELETE
`ListJobs`	CATALOG_JOB_INSPECT
`GetJob`	CATALOG_JOB_READ
`UpdateJob`	CATALOG_JOB_UPDATE
`CreateJob`	CATALOG_JOB_CREATE
`DeleteJob`	CATALOG_JOB_DELETE
`ListJobMetrics`	CATALOG_JOB_READ
`GetJobMetrics`	CATALOG_JOB_READ
`ListJobLogs`	CATALOG_JOB_READ
`GetJobLog`	CATALOG_JOB_READ
`ListJobExecutions`	CATALOG_JOB_READ
`GetJobExecution`	CATALOG_JOB_READ
`UpdateJobExecution`	CATALOG_JOB_UPDATE
`CreateJobExecution`	CATALOG_JOB_UPDATE
`DeleteJobExecution`	CATALOG_JOB_UPDATE
`ListDataAssets`	CATALOG_DATA_ASSET_INSPECT
`GetDataAsset`	CATALOG_DATA_ASSET_READ
`UpdateDataAsset`	CATALOG_DATA_ASSET_UPDATE
`CreateDataAsset`	CATALOG_DATA_ASSET_CREATE
`DeleteDataAsset`	CATALOG_DATA_ASSET_DELETE
`ListConnections`	CATALOG_DATA_ASSET_READ
`GetConnection`	CATALOG_DATA_ASSET_READ
`ParseConnection`	CATALOG_DATA_ASSET_READ
`UpdateConnection`	CATALOG_DATA_ASSET_UPDATE
`ImportConnection`	CATALOG_DATA_ASSET_UPDATE
`ValidateConnection`	CATALOG_DATA_ASSET_UPDATE
`TestConnection`	CATALOG_DATA_ASSET_UPDATE
`CreateConnection`	CATALOG_DATA_ASSET_UPDATE
`DeleteConnection`	CATALOG_DATA_ASSET_UPDATE
`ListFolders`	CATALOG_DATA_ASSET_READ
`GetFolder`	CATALOG_DATA_ASSET_READ
`UpdateFolder`	CATALOG_DATA_ASSET_UPDATE
`CreateFolder`	CATALOG_DATA_ASSET_UPDATE
`DeleteFolder`	CATALOG_DATA_ASSET_UPDATE
`ListEntities`	CATALOG_DATA_ASSET_READ
`GetEntity`	CATALOG_DATA_ASSET_READ
`UpdateEntity`	CATALOG_DATA_ASSET_UPDATE
`CreateEntity`	CATALOG_DATA_ASSET_UPDATE
`DeleteEntity`	CATALOG_DATA_ASSET_UPDATE
`ListAttributes`	CATALOG_DATA_ASSET_READ
`GetAttribute`	CATALOG_DATA_ASSET_READ
`UpdateAttribute`	CATALOG_DATA_ASSET_UPDATE
`CreateAttribute`	CATALOG_DATA_ASSET_UPDATE
`DeleteAttribute`	CATALOG_DATA_ASSET_UPDATE
`ListDataAssetTags`	CATALOG_DATA_ASSET_TAG_INSPECT
`GetDataAssetTag`	CATALOG_DATA_ASSET_TAG_READ
Not used.	CATALOG_DATA_ASSET_TAG_UPDATE
`CreateDataAssetTag`	CATALOG_DATA_ASSET_TAG_CREATE
`DeleteDataAssetTag`	CATALOG_DATA_ASSET_TAG_DELETE
`ListEntityTags`	CATALOG_DATA_ASSET_TAG_INSPECT
`GetEntityTag`	CATALOG_DATA_ASSET_TAG_READ
Not used.	CATALOG_DATA_ASSET_TAG_UPDATE
`CreateEntityTag`	CATALOG_DATA_ASSET_TAG_CREATE
`DeleteEntityTag`	CATALOG_DATA_ASSET_TAG_DELETE
`ListAttributeTags`	CATALOG_DATA_ASSET_TAG_INSPECT
`GetAttributeTag`	CATALOG_DATA_ASSET_TAG_READ
Not used.	CATALOG_DATA_ASSET_TAG_UPDATE
`CreateAttributeTag`	CATALOG_DATA_ASSET_TAG_CREATE
`DeleteAttributeTag`	CATALOG_DATA_ASSET_TAG_DELETE
`ListFolderTags`	CATALOG_DATA_ASSET_TAG_INSPECT
`GetFolderTag`	CATALOG_DATA_ASSET_TAG_READ
Not used.	CATALOG_DATA_ASSET_TAG_UPDATE
`CreateFolderTag`	CATALOG_DATA_ASSET_TAG_CREATE
`DeleteFolderTag`	CATALOG_DATA_ASSET_TAG_DELETE
`AddDataSelectorPatterns`	CATALOG_DATA_ASSET_UPDATE
`CreatePattern`	CATALOG_DATA_ASSET_UPDATE
`DeletePattern`	CATALOG_DATA_ASSET_UPDATE
`GetPattern`	CATALOG_DATA_ASSET_READ
`ListDerivedLogicalEntities`	CATALOG_DATA_ASSET_READ
`ListPattern`	CATALOG_DATA_ASSET_READ
`RemoveDataSelectorPatterns`	CATALOG_DATA_ASSET_UPDATE
`UpdatePattern`	CATALOG_DATA_ASSET_UPDATE
`ValidatePattern`	CATALOG_DATA_ASSET_READ

data-catalog-glossaries


API Operation	Permissions Required to Use the Operation
`ListGlossaries`	CATALOG_GLOSSARY_INSPECT
`GetGlossary`	CATALOG_GLOSSARY_READ
`ExportGlossary`	CATALOG_GLOSSARY_READ
`UpdateGlossary`	CATALOG_GLOSSARY_UPDATE
`ImportGlossary`	CATALOG_GLOSSARY_UPDATE
`CreateGlossary`	CATALOG_GLOSSARY_CREATE
`DeleteGlossary`	CATALOG_GLOSSARY_DELETE
`ListGlossaryTerms`	CATALOG_GLOSSARY_READ
`GetTerm`	CATALOG_GLOSSARY_READ
`UpdateTerm`	CATALOG_GLOSSARY_UPDATE
`CreateTerm`	CATALOG_GLOSSARY_UPDATE
`DeleteTerm`	CATALOG_GLOSSARY_UPDATE
`ListGlossaryTermRelationships`	CATALOG_GLOSSARY_READ
`GetTermRelationship`	CATALOG_GLOSSARY_READ
`UpdateTermRelationship`	CATALOG_GLOSSARY_UPDATE
`CreateTermRelationship`	CATALOG_GLOSSARY_UPDATE
`DeleteTermRelationship`	CATALOG_GLOSSARY_UPDATE

data-catalog-namespaces


API Operation	Permissions Required to Use the Operation
`AssociateCustomProperty`	CATALOG_NAMESPACE_UPDATE
`CreateCustomProperty`	CATALOG_NAMESPACE_UPDATE
`CreateNamespace`	CATALOG_NAMESPACE_CREATE
`DeleteCustomProperty`	CATALOG_NAMESPACE_UPDATE
`DeleteNamespace`	CATALOG_NAMESPACE_DELETE
`DisassociateCustomProperty`	CATALOG_NAMESPACE_UPDATE
`GetCustomProperty`	CATALOG_NAMESPACE_READ
`GetNamespace`	CATALOG_NAMESPACE_READ
`ListCustomProperties`	CATALOG_NAMESPACE_READ
`ListNamespaces`	CATALOG_NAMESPACE_INSPECT
`UpdateCustomProperty`	CATALOG_NAMESPACE_UPDATE
`UpdateNamespace`	CATALOG_NAMESPACE_UPDATE

data-catalog-metastores


API Operation	Permissions Required to Use the Operation
`ListMetastores`	CATALOG_METASTORE_INSPECT
`CreateMetastore`	CATALOG_METASTORE_CREATE
`GetMetastore`	CATALOG_METASTORE_READ
`UpdateMetastore`	CATALOG_METASTORE_UPDATE
`DeleteMetastore`	CATALOG_METASTORE_DELETE
`ChangeMetastoreCompartment`	CATALOG_METASTORE_MOVE

Creating a Policy

Here's how you create a policy:

Open the navigation menu and click Identity & Security. Under Identity, click Policies.
In the Policies page, click Create Policy.
In the Create Policy panel, enter the following details:
- Name: Enter a unique name for the policy. The name must be unique across all policies in your tenancy. You can't change the name later. For example, catalog_read_only.
- Description: Enter a description, such as Allow only catalog read access to group <group name>.
- Compartment: Select a compartment in which you want to create the policy.
- Policy Builder: In this section, move the slider to Show manual editor, and enter a policy rule in the following format:
  allow group <group name> to read data-catalogs in compartment <compartment name>
Click Create.

For more information on creating policies, see how policies work and policy reference.

Policy Examples

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

Create this policy to allow access to any object, in any bucket, in any compartment within the tenancy where the policy is created. When you harvest an Object Storage data asset, data entities from all the buckets that your data catalog instance has access to are listed. You can then select the data objects across these buckets for harvesting.

Create this policy only for the root_compartment. Since 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

You can create policies to allow access to any object in bucketA or bucketB in any compartment within the tenancy where the policy is created, or to an object in bucketA or bucketB in a compartment such as compartmentA. When you harvest an Object Storage data asset, data entities from bucketA and bucketB are listed. You can then select the data objects from these buckets for harvesting.

Here, condition matching of the bucket names is case insensitive. For example, if you have a bucket BucketA and a bucket bucketA, the condition target.bucket.name='BucketA' applies to both. To avoid potential issues with resource names in policies, give your resources distinct names.

To allow access to any object, in bucketA or bucketB, in any compartment within the tenancy where the policy is created, create the following policy:

allow dynamic group to read object-family in tenancy 
where any {target.bucket.name='bucketA', target.bucket.name='bucketB'}

To allow access to any object from bucketA or bucketB in compartmentA, create the following policy:

allow dynamic group to read object-family in compartment compartmentA
 where any {target.bucket.name='bucketA', target.bucket.name='bucketB'}

You can also create a policy to allow access to any object from bucketA or bucketB within a compartment using the compartment OCID. To view the compartment OCID in the Console, navigate to Identity → Compartments. Click the compartment link for your Object Storage resource. From the Compartment Details page, copy the OCID under Compartment Information.

allow dynamic group to read object-family in compartment id <compartment_ocid>
 where any {target.bucket.name='bucketA', target.bucket.name='bucketB'}

Allow Access to a Specific Compartment

You can enable access to a specific compartment in your tenancy using the compartment name or compartment OCID.

Create this policy to allow access to any object in any bucket within compartmentA. When you harvest an Object Storage data asset, data entities from all the buckets in compartmentA are listed. You can then select the data objects across these buckets for harvesting.

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

You can also create a policy to allow access to any object in any bucket within a compartment using the compartment OCID. To view the compartment OCID in the Console, navigate to Identity → Compartments. Click the compartment link for your Object Storage resource. From the Compartment Details page, copy the OCID under Compartment Information.

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

Allow Access to a Different Tenancy

If your Data Catalog instance and Oracle Object Storage are in different tenancies, then you must create the following policies:

Create this policy in the tenancy that has the Data Catalog instance:

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


Endorse dynamic-group <dynamic-group-name1> to manage object-family in tenancy <any-name1>

Create this policy in the tenancy that has the object storage:

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


Define dynamic-group <any-name3> as <dynamic-group-name1-OCID>


Admit dynamic-group <any-name3> of tenancy <any-name2> to manage object-family in tenancy

Service to Service Policy Examples

Allow Access to Tenancy

Create this policy only for the root_compartment. Since the scope of this policy is the whole tenancy, a child compartment will not have access to the root or the parent compartments.

allow service datacatalog to read object-family in tenancy

Allow Access to Specific Buckets

To allow access to any object, in bucketA or bucketB, in any compartment within the tenancy where the policy is created, create the following policy:

allow service datacatalog to read object-family in tenancy 
where any {target.bucket.name='bucketA', target.bucket.name='bucketB'}

To allow access to any object from bucketA or bucketB in compartmentA, create the following policy:

allow service datacatalog to read object-family in compartment compartmentA
 where any {target.bucket.name='bucketA', target.bucket.name='bucketB'}

allow service datacatalog to read object-family in compartment id <compartment_ocid>
 where any {target.bucket.name='bucketA', target.bucket.name='bucketB'}

Allow Access to a Specific Compartment

You can enable access to a specific compartment in your tenancy using the compartment name or compartment OCID.

allow service datacatalog to read object-family in compartment compartmentA

allow service datacatalog to read object-family in compartment id <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 are able to 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>'

Create this policy if you want to import and export glossaries. While exporting, Data Catalog connects to IAM to get the user name details. While importing, Data Catalog connects to IAM to validate the OCID in the imported file.

allow service datacatalog to inspect users in tenancy

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>'

Metastore Policy Examples

You can add policies to grant Metastore S2S Principal access to storage locations.

Note

Support for S2S Principal type connection is available only till April 2022.

ALLOW service datacatalog to read buckets in tenancy where any{ all {target.bucket.name='<managed-table-location-bucket>', request.region='<managed-table-location-bucket-region>'}, all {target.bucket.name='<external-table-location-bucket>', request.region='<external-table-location-bucket-region>'}}

ALLOW service datacatalog to manage objects in tenancy where all {target.bucket.name='<managed-table-location-bucket>', request.region='<managed-table-location-bucket-region>'}

ALLOW service datacatalog to read objects in tenancy where all {target.bucket.name='<external-table-location-bucket>', request.region='<external-table-location-bucket-region>'}

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'

Oracle Cloud Infrastructure Documentation