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 |
|
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.
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 |
---|---|---|---|
|
|
Entity (OCID) |
Not available to use with |
|
|
Entity (OCID) |
Not available to use with |
|
|
Entity (OCID) |
Not available to use with work request operations. |
|
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
|
|
|
|
Entity (OCID) |
Not available to use with work request operations. |
|
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
|
|
|
|
Entity (OCID) |
Not available to use with work request operations. |
|
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.
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 |
|
none |
CATALOG_JOB_DEFINITION_INSPECT |
|
|
CATALOG_JOB_INSPECT |
|
|
CATALOG_JOB_INSPECT |
|
|
READ | ||
Permissions | APIs Fully Covered | APIs Partially Covered |
INSPECT + |
INSPECT + |
none |
CATALOG_JOB_DEFINITION_READ |
|
|
|
||
CATALOG_JOB_READ |
|
|
|
||
|
||
|
||
|
||
|
||
|
||
CATALOG_READ |
|
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
CATALOG_WORK_REQUEST_READ |
|
|
|
||
|
||
USE | ||
Permissions |
APIs Fully Covered |
APIs Partially Covered |
READ + |
READ + |
none |
CATALOG_UPDATE |
UpdateCatalog |
|
CATALOG_JOB_DEFINITION_CREATE |
|
|
CATALOG_JOB_DEFINITION_UPDATE |
|
|
CATALOG_JOB_DEFINITION_DELETE |
|
|
CATALOG_JOB_CREATE |
|
|
CATALOG_JOB_UPDATE |
|
|
CATALOG_JOB_DELETE |
|
|
CATALOG_ATTACH_CATALOG_PRIVATE_ENDPOINT |
|
|
CATALOG_DETACH_CATALOG_PRIVATE_ENDPOINT |
|
|
MANAGE | ||
Permissions |
APIs Fully Covered |
APIs Partially Covered |
USE + |
USE + |
none |
CATALOG_CREATE |
|
|
CATALOG_DELETE |
|
|
CATALOG_MOVE |
|
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 |
|
none |
READ | ||
Permissions | APIs Fully Covered | APIs Partially Covered |
INSPECT + |
INSPECT + |
none |
CATALOG_PRIVATE_ENDPOINT_READ |
|
|
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 |
|
|
CATALOG_PRIVATE_ENDPOINT_CREATE |
|
|
CATALOG_PRIVATE_ENDPOINT_DELETE |
|
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 |
|
none |
CATALOG_DATA_ASSET_TAG_INSPECT |
|
|
|
||
|
||
|
||
READ | ||
Permissions | APIs Fully Covered | APIs Partially Covered |
INSPECT + |
INSPECT + |
none |
CATALOG_DATA_ASSET_READ |
|
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
CATALOG_DATA_ASSET_TAG_READ |
|
|
|
||
|
||
|
||
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 |
|
|
|
||
|
||
|
||
CATALOG_DATA_ASSET_TAG_DELETE |
|
|
|
||
|
||
|
||
CATALOG_DATA_ASSET_TAG_UPDATE |
not used | |
MANAGE | ||
Permissions |
APIs Fully Covered |
APIs Partially Covered |
USE + |
USE + |
none |
CATALOG_DATA_ASSET_CREATE |
|
|
CATALOG_DATA_ASSET_DELETE |
|
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 |
|
none |
READ | ||
Permissions | APIs Fully Covered | APIs Partially Covered |
INSPECT + |
INSPECT + |
none |
CATALOG_GLOSSARY_READ |
|
|
|
||
|
||
|
||
|
||
|
||
|
||
USE | ||
Permissions |
APIs Fully Covered |
APIs Partially Covered |
READ + |
READ + |
none |
CATALOG_GLOSSARY_UPDATE |
|
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
MANAGE | ||
Permissions |
APIs Fully Covered |
APIs Partially Covered |
USE + |
USE + |
none |
CATALOG_GLOSSARY_CREATE |
|
|
CATALOG_GLOSSARY_DELETE |
|
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 |
|
none |
READ | ||
Permissions | APIs Fully Covered | APIs Partially Covered |
INSPECT + |
INSPECT + |
none |
CATALOG_NAMESPACE_READ |
|
|
|
||
|
||
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 |
|
|
CATALOG_NAMESPACE_DELETE |
|
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 |
|
none |
READ | ||
Permissions | APIs Fully Covered | APIs Partially Covered |
INSPECT + |
INSPECT + |
none |
CATALOG_METASTORE_READ |
|
|
USE | ||
Permissions |
APIs Fully Covered |
APIs Partially Covered |
READ + |
READ + |
none |
CATALOG_METASTORE_UPDATE |
UpdateMetastore |
|
MANAGE | ||
Permissions |
APIs Fully Covered |
APIs Partially Covered |
USE + |
USE + |
none |
CATALOG_METASTORE_CREATE |
|
|
CATALOG_METASTORE_DELETE |
|
|
CATALOG_METASTORE_MOVE |
|
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.
API Operation |
Permissions Required to Use the Operation |
---|---|
|
CATALOG_INSPECT |
|
CATALOG_READ |
|
CATALOG_UPDATE |
|
CATALOG_CREATE |
|
CATALOG_MOVE |
|
CATALOG_DELETE |
|
CATALOG_READ |
|
CATALOG_READ |
|
CATALOG_READ |
|
CATALOG_READ |
|
CATALOG_READ |
|
CATALOG_WORK_REQUEST_INSPECT |
|
CATALOG_DATA_ASSET_READ |
|
CATALOG_WORK_REQUEST_READ |
|
CATALOG_WORK_REQUEST_READ |
|
CATALOG_WORK_REQUEST_READ |
|
CATALOG_JOB_DEFINITION_INSPECT |
|
CATALOG_JOB_DEFINITION_READ |
|
CATALOG_JOB_DEFINITION_READ |
UpdateJobDefinition |
CATALOG_JOB_DEFINITION_UPDATE |
|
CATALOG_JOB_DEFINITION_CREATE |
|
CATALOG_JOB_DEFINITION_DELETE |
|
CATALOG_JOB_INSPECT |
|
CATALOG_JOB_READ |
|
CATALOG_JOB_UPDATE |
|
CATALOG_JOB_CREATE |
|
CATALOG_JOB_DELETE |
|
CATALOG_JOB_READ |
|
CATALOG_JOB_READ |
|
CATALOG_JOB_READ |
|
CATALOG_JOB_READ |
|
CATALOG_JOB_READ |
|
CATALOG_JOB_READ |
|
CATALOG_JOB_UPDATE |
|
CATALOG_JOB_UPDATE |
|
CATALOG_JOB_UPDATE |
|
CATALOG_READ |
API Operation |
Permissions Required to Use the Operation |
---|---|
|
CATALOG_ATTACH_CATALOG_PRIVATE_ENDPOINT |
|
CATALOG_DETACH_CATALOG_PRIVATE_ENDPOINT |
|
CATALOG_PRIVATE_ENDPOINT_MOVE |
|
CATALOG_PRIVATE_ENDPOINT_CREATE |
|
CATALOG_PRIVATE_ENDPOINT_DELETE |
|
CATALOG_PRIVATE_ENDPOINT_READ |
|
CATALOG_PRIVATE_ENDPOINT_INSPECT |
|
CATALOG_PRIVATE_ENDPOINT_UPDATE |
API Operation |
Permissions Required to Use the Operation |
---|---|
|
CATALOG_ATTACH_CATALOG_PRIVATE_ENDPOINT |
|
CATALOG_DETACH_CATALOG_PRIVATE_ENDPOINT |
|
CATALOG_PRIVATE_ENDPOINT_MOVE |
|
CATALOG_PRIVATE_ENDPOINT_CREATE |
|
CATALOG_PRIVATE_ENDPOINT_DELETE |
|
CATALOG_PRIVATE_ENDPOINT_READ |
|
CATALOG_PRIVATE_ENDPOINT_INSPECT |
|
CATALOG_PRIVATE_ENDPOINT_UPDATE |
|
CATALOG_INSPECT |
|
CATALOG_READ |
|
CATALOG_UPDATE |
|
CATALOG_CREATE |
|
CATALOG_MOVE |
|
CATALOG_DELETE |
|
CATALOG_READ |
|
CATALOG_READ |
|
CATALOG_READ |
|
CATALOG_READ |
|
CATALOG_READ |
|
CATALOG_WORK_REQUEST_INSPECT |
|
CATALOG_WORK_REQUEST_READ |
|
CATALOG_WORK_REQUEST_READ |
|
CATALOG_WORK_REQUEST_READ |
|
CATALOG_JOB_DEFINITION_INSPECT |
|
CATALOG_JOB_DEFINITION_READ |
|
CATALOG_JOB_DEFINITION_READ |
UpdateJobDefinition |
CATALOG_JOB_DEFINITION_UPDATE |
|
CATALOG_JOB_DEFINITION_CREATE |
|
CATALOG_JOB_DEFINITION_DELETE |
|
CATALOG_JOB_INSPECT |
|
CATALOG_JOB_READ |
|
CATALOG_JOB_UPDATE |
|
CATALOG_JOB_CREATE |
|
CATALOG_JOB_DELETE |
|
CATALOG_JOB_READ |
|
CATALOG_JOB_READ |
|
CATALOG_JOB_READ |
|
CATALOG_JOB_READ |
|
CATALOG_JOB_READ |
|
CATALOG_JOB_READ |
|
CATALOG_JOB_UPDATE |
|
CATALOG_JOB_UPDATE |
|
CATALOG_JOB_UPDATE |
|
CATALOG_DATA_ASSET_INSPECT |
|
CATALOG_DATA_ASSET_READ |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_CREATE |
|
CATALOG_DATA_ASSET_DELETE |
|
CATALOG_DATA_ASSET_READ |
|
CATALOG_DATA_ASSET_READ |
|
CATALOG_DATA_ASSET_READ |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_READ |
|
CATALOG_DATA_ASSET_READ |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_READ |
|
CATALOG_DATA_ASSET_READ |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_READ |
|
CATALOG_DATA_ASSET_READ |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_TAG_INSPECT |
|
CATALOG_DATA_ASSET_TAG_READ |
Not used. |
CATALOG_DATA_ASSET_TAG_UPDATE |
|
CATALOG_DATA_ASSET_TAG_CREATE |
|
CATALOG_DATA_ASSET_TAG_DELETE |
|
CATALOG_DATA_ASSET_TAG_INSPECT |
|
CATALOG_DATA_ASSET_TAG_READ |
Not used. |
CATALOG_DATA_ASSET_TAG_UPDATE |
|
CATALOG_DATA_ASSET_TAG_CREATE |
|
CATALOG_DATA_ASSET_TAG_DELETE |
|
CATALOG_DATA_ASSET_TAG_INSPECT |
|
CATALOG_DATA_ASSET_TAG_READ |
Not used. |
CATALOG_DATA_ASSET_TAG_UPDATE |
|
CATALOG_DATA_ASSET_TAG_CREATE |
|
CATALOG_DATA_ASSET_TAG_DELETE |
|
CATALOG_DATA_ASSET_TAG_INSPECT |
|
CATALOG_DATA_ASSET_TAG_READ |
Not used. |
CATALOG_DATA_ASSET_TAG_UPDATE |
|
CATALOG_DATA_ASSET_TAG_CREATE |
|
CATALOG_DATA_ASSET_TAG_DELETE |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_READ |
|
CATALOG_DATA_ASSET_READ |
|
CATALOG_DATA_ASSET_READ |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_UPDATE |
|
CATALOG_DATA_ASSET_READ |
API Operation |
Permissions Required to Use the Operation |
---|---|
|
CATALOG_GLOSSARY_INSPECT |
|
CATALOG_GLOSSARY_READ |
|
CATALOG_GLOSSARY_READ |
|
CATALOG_GLOSSARY_UPDATE |
|
CATALOG_GLOSSARY_UPDATE |
|
CATALOG_GLOSSARY_CREATE |
|
CATALOG_GLOSSARY_DELETE |
|
CATALOG_GLOSSARY_READ |
|
CATALOG_GLOSSARY_READ |
|
CATALOG_GLOSSARY_UPDATE |
|
CATALOG_GLOSSARY_UPDATE |
|
CATALOG_GLOSSARY_UPDATE |
|
CATALOG_GLOSSARY_READ |
|
CATALOG_GLOSSARY_READ |
|
CATALOG_GLOSSARY_UPDATE |
|
CATALOG_GLOSSARY_UPDATE |
|
CATALOG_GLOSSARY_UPDATE |
API Operation |
Permissions Required to Use the Operation |
---|---|
|
CATALOG_NAMESPACE_UPDATE |
|
CATALOG_NAMESPACE_UPDATE |
|
CATALOG_NAMESPACE_CREATE |
|
CATALOG_NAMESPACE_UPDATE |
|
CATALOG_NAMESPACE_DELETE |
|
CATALOG_NAMESPACE_UPDATE |
|
CATALOG_NAMESPACE_READ |
|
CATALOG_NAMESPACE_READ |
|
CATALOG_NAMESPACE_READ |
|
CATALOG_NAMESPACE_INSPECT |
|
CATALOG_NAMESPACE_UPDATE |
|
CATALOG_NAMESPACE_UPDATE |
API Operation |
Permissions Required to Use the Operation |
---|---|
|
CATALOG_METASTORE_INSPECT |
|
CATALOG_METASTORE_CREATE |
|
CATALOG_METASTORE_READ |
|
CATALOG_METASTORE_UPDATE |
|
CATALOG_METASTORE_DELETE |
|
CATALOG_METASTORE_MOVE |
Creating a Policy
Here's how you create a policy:
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.
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.
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
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>
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>'
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.
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>'}
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
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'}
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>
If your Data Catalog instance and Oracle Object Storage are in different tenancies, then you must create the following policies:
Define tenancy <any-name1> as <object-storage-tenancy-OCID>
Endorse dynamic-group <dynamic-group-name1> to manage object-family in tenancy <any-name1>
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
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 service datacatalog to read object-family in tenancy
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 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'}
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 service datacatalog to read object-family in compartment id <compartment_ocid>
where any {target.bucket.name='bucketA', target.bucket.name='bucketB'}
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 service datacatalog to read object-family in compartment compartmentA
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 service datacatalog to read object-family in compartment id <compartment_ocid>
For data catalog users to configure private networks, you need to create policies.
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
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
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
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'
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>'
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
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>'
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>'
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>'}
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'