Permissions Required for Each API Operation Review the list of API operations for Oracle Exadata Database Service on Cloud@Customer resources in a logical order, grouped by resource type.
Learn about resource-types you can use in your policies.
An aggregate resource-type covers the list of individual resource-types that directly
follow.
For example, writing one policy to allow a group to have access to the
database-family is equivalent to writing eight separate policies
for the group that would grant access to the exadata-infrastructures,
vmcluster-networks,
vmclusters, backup-destinations,
db-nodes, dbnode-console-connection, and the rest
of the individual resource-types.
For example, writing one policy to allow a group to have access to the
autonomous-database-family is equivalent to writing four separate
policies for the group that would grant access to the
autonomous-databases, autonomous-backups,
autonomous-container-databases, and
cloud-autonomous-vmclusters resource-types.
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.
For example, the read verb for the vmclusters
resource-type covers no extra permissions or API operations compared to the
inspect verb. However, the use verb includes one
more permission, fully covers one more operation, and partially covers another
additional operation.
Permissions and API operation details for VM Cluster Networks 🔗
vmcluster-network resources inherit permissions from the exadata-infrastructure resources with which they are associated. You cannot grant permissions to vmcluster-network resources explicitly.
The table below lists permissions and API operations for vmcluster-networks.
Permissions and API operation details for VM Clusters 🔗
The table below lists permissions and API operations for vmclusters.
Verbs
Permissions
APIs Fully Covered
APIs Partially Covered
INSPECT
VM_CLUSTER_INSPECT
ListVmClusters
GetVmCluster
ListVmClusterPatches
ListVmClusterPatchHistoryEntries
GetVmClusterPatch
GetVmClusterPatchHistoryEntry
ListVmClusterUpdates
ListVmClusterUpdateHistoryEntries
GetVmClusterUpdate
GetVmClusterUpdateHistoryEntry
none
READ
No extra
No extra
No extra
USE
READ +
VM_CLUSTER_UPDATE
VM_CLUSTER_UPDATE_TAGS
VM_CLUSTER_UPDATE_COMPARTMENT
VM_CLUSTER_UPDATE_SSH_KEY
VM_CLUSTER_UPDATE_LICENSE
VM_CLUSTER_UPDATE_CPU
VM_CLUSTER_UPDATE_MEMORY
VM_CLUSTER_UPDATE_LOCAL_STORAGE
VM_CLUSTER_UPDATE_EXADATA_STORAGE
VM_CLUSTER_UPDATE_GI_SOFTWARE
VM_CLUSTER_UPDATE_FILE_SYSTEM
ChangeVmClusterCompartment
UpdateVmCluster (also needs use exadata-infrastructures)
CreateDbHome, (also needs manage db-homes and manage databases). If automatic backups are enabled on the default database, also needs manage backups
DeleteDbHome, (also needs manage db-homes and manage databases. If automatic backups are enabled on the default database, also needs manage backups
MANAGE
USE +
VM_CLUSTER_CREATE
VM_CLUSTER_DELETE
No extra
CreateVmCluster (also needs use exadata-infrastructures)
DeleteVmCluster (also needs use exadata-infrastructures)
Note
The VM_CLUSTER_UPDATE_SSH_KEY permission is a highly privileged permission that allows the user to be a root user on the guest VM and gives them the ability to run other cluster update operations on the guest VM using dbaascli.
Using fine-grained permissions, you can write policies as follows:
To allow any update operations:
allow group abc to use vmclusters in compartment comp1
To allow only scale CPU:
allow group abc to use vmclusters in compartment comp1 where request.permission = 'VM_CLUSTER_UPDATE_CPU'
To allow GI update and any scale operations:
allow group abc to use vmclusters in compartment comp1
where any
{ request.permission = 'VM_CLUSTER_UPDATE_CPU', request.permission = 'VM_CLUSTER_UPDATE_EXADATA_STORAGE',
request.permission = 'VM_CLUSTER_UPDATE_MEMORY', request.permission = 'VM_CLUSTER_UPDATE_LOCAL_STORAGE', request.permission = 'VM_CLUSTER_UPDATE_GI_SOFTWARE'}
To allow any operations except add SSH key:
allow group abc to use vmclusters in compartment comp1 where all { request.permission != 'VM_CLUSTER_UPDATE_SSH_KEY' , request.permission != 'VM_CLUSTER_UPDATE' }
Permissions and API operation details for DB Homes 🔗
The table below lists permissions and API operations for db-homes.
Verbs
Permissions
APIs Fully Covered
APIs Partially Covered
INSPECT
DB_HOME_INSPECT
ListDBHome
GetDBHome
ListDbHomePatches
ListDbHomePatchHistoryEntries
GetDbHomePatch
GetDbHomePatchHistoryEntry
none
READ
No extra
No extra
none
USE
DB_HOME_UPDATE
UpdateDBHome
none
MANAGE
USE +
DB_HOME_CREATE
DB_HOME_DELETE
No extra
CreateDbHome, (also needs manage db-homes, manage backups, manage db-nodes, read vmclusters, read work-requests, and inspect exadata-infrastructures). If automatic backups are enabled on the default database, also needs manage backups.
DeleteDbHome, (also needs manage db-homes, manage backups, manage db-nodes, read vmclusters, read work-requests, and inspect exadata-infrastructures). If automatic backups are enabled on the default database, also needs manage backups.
Permissions and API operation details for Scheduling Plan 🔗
scheduling-plan resources inherit permissions from the exadata-infrastructure resources with which they are associated. You cannot grant permissions to scheduling-plan resources explicitly.
The table below lists permissions and API operations for scheduling-plan.
Permissions and API operation details for Scheduled Action 🔗
scheduled-action resources inherit permissions from the exadata-infrastructure resources with which they are associated. You cannot grant permissions to scheduled-action resources explicitly.
The table below lists permissions and API operations for scheduled-action.
Permissions and API operation details for Execution Windows 🔗
execution-windows resources inherit permissions from the exadata-infrastructure resources with which they are associated. You cannot grant permissions to execution-windows resources explicitly.
The table below lists permissions and API operations for execution-windows.
Permissions and API operation details for Execution Action 🔗
execution-action resources inherit permissions from the exadata-infrastructure resources with which they are associated. You cannot grant permissions to execution-action resources explicitly.
The table below lists permissions and API operations for execution-action.