A Operator Access Control Reference

To find out more about Operator Access Control, refer to these topics.

Example of Using Operator Access Control

As an administrator, see how you can set up operator access controls that define the actions an Oracle operator can perform on a set of resources on your Exadata systems.

Suppose an administrator has completed a review of administrative policy requirements and divided the Exadata systems into the following Operator Controls:

Example A-1 Creating Operator Policies for Containers on Exadata Cloud

Table A-1 Example of Operator Controls Configuration

Exadata Systems Compartment Compliance Regime Administrator User Group Operator Control User Group
Exadata Systems E1-E10 prod-pci PCI pci_admin, pci_admin_2 top-security-users
Exadata Systems E11-E15 prod-hipaa HIPAA hipaa_admin top-security-users
Exadata Systems E16-E20 prod-soc SOC-2 soc_admin top-security-users
Exadata Systems E21-E25 devops None devops_admin devops_admin
Exadata Systems E26-E30 func-qa None qa_admin qa_admin
Exadata Systems E31-40 perf-qa None perf_admin psr-admin

In this hypothetical case, there are six compartments, and five user groups that administer the compartments.

Since the Payment Card Industry (PCI), Service Organization Control 2 (SOC-2), and Health Insurance Portability and Accountability Act (HIPAA) compliance systems are governed by different compliance regimes, there are two ways to create Operator Controls governing them. One way is to create a distinct Operator Control for each compliance regime. The other way is to create the strictest Operator Control required, and have all three compliance categories of systems be governed by the same Operator Control. In this scenario, since the Functional-QA (func-qa) and Performance-QA (perf-qa) compartments are not under the governance of any compliance regime, and the compartments are administered by the same user group, we can have a single Operator Control governing both of them.

Suppose you are the policy administrator for these systems. To create the Operator Policy controls for this configuration, you create one policy to govern all systems under compliance regimes, one policy for development operations (devops) deployment, and one option for quality assurance (QA) systems. The controls themselves are placed in a compartment named "policies", which is manageable only by the "top-security-users" group. The following CLI commands are indicative and adjusted for readability, for examples names are used in place of OCIDs. For more information, refer to the CLI guide.

/* Ensure only the top_security group has permission on the policies compartment */
allow group top_security to manage operator-control in compartment policies

/* create operator controls */
oci opctl operator-control create --operator-control-name "prod-opctl-policy" --pre-approved-op-action-list ‘[“INFRA_DIAG”]’ --approver-groups-list '["top_security_group"]' --is-fully-pre-approved false --description “Production Operator Control” --compartment-id “policies"
oci opctl operator-control create --operator-control-name "devops-opctl-policy" --pre-approved-op-action-list ‘[“INFRA_DIAG”, "INFRA_UPDATE_RESTART"] --approver-groups-list '["devops-admin"]' --is-fully-pre-approved false --description “Devops Operator Control” --compartment-id “policies"
oci opctl operator-control create --operator-control-name "qa-opctl-policy" --is-fully-pre-approved true --approver-groups-list '["qa-admin, psr-admin"]' --description “QA/Test Operator Control” --compartment-id “policies"

/* Ensure users have assignment permissions on the target Exadata. They also need read privileges on the policies. An example for pci-admin is given below*/
allow group pci-admin to manage operator-control-assignment in compartment prod-pci;

/* Ensure the user groups have manage operator control request privileges in there respective compartments */
allow group pci-sec-controller to manage operator-control-access-request in compartment prod-pci
allow group hipaa-sec-controller to manage operator-control-access-request in compartment prod-hipaa
allow group soc-sec-controller to manage operator-control-access-request in compartment prod-soc
allow group devops-sec-controller to manage operator-control-access-request in compartment devops
allow group qa-sec-controller to manage operator-control-access-request in compartment func-qa
allow group perf-sec-controller to manage operator-control-access-request in compartment perf-qa
allow group pci-admin to read operator-control in compartment policies;

Now that we have created the relevant user groups and given permissions. Users from these user groups can go ahead and bring the respective Exadata systems under control. The exadata systems should be assigned with the respective controls. The assignments themselves reside on the same compartments as the exadata systems. As mentioned earlier the following commands are indicative and adapted for readability. For more information, refer to the CLI guide.

Next, you create the relevant Operator Control policy user groups, and grant them read access to the compartments containing the operator controls that these group members administer:

oci opctl operator-control-assignment create --operator-control-id "prod-opctl-policy" --compartment-id "prod-pci" --resource-compartment-id "prod-pci" --resource-id "exadata-OCID..E1..E10" --resource-name "Exadata E1-E10" --is-enforced-always true
oci opctl operator-control-assignment create --operator-control-id "prod-opctl-policy" --compartment-id "prod-hipaa" --resource-compartment-id "prod-hipaa" --resource-id "exadata-OCID..E11..E15" --resource-name "Exadata E11-E15" --is-enforced-always true
oci opctl operator-control-assignment create --operator-control-id "prod-opctl-policy" --compartment-id "prod-soc" --resource-compartment-id "prod-soc" --resource-id "exadata-OCID..E16..E20" --resource-name "Exadata E16-E20" --is-enforced-always true
oci opctl operator-control-assignment create --operator-control-id "devops-opctl-policy" --compartment-id "devops" --resource-compartment-id "devops" --resource-id "exadata-OCID..E21..E25" --resource-name "Exadata E21-E25" --is-enforced-always true
oci opctl operator-control-assignment create --operator-control-id "qa-opctl-policy" --compartment-id "func-qa" --resource-compartment-id "func-qa" --resource-id "exadata-OCID..E26..E30" --resource-name "Exadata E26-E30" --is-enforced-always true
oci opctl operator-control-assignment create --operator-control-id "qa-opctl-policy" --compartment-id "perf-qa" --resource-compartment-id "perf-qa" --resource-id "exadata-OCID..E31..E40" --resource-name "Exadata E31-E40" --is-enforced-always true

You then approve, reject, or revoke the access request permissions for each Operator Control with the groups created above.

Example A-2 Granting an Operator DBA Privileges to Approve Access Requests

Suppose you have granted the group top-security-users the Operator Control User Group on several systems, but you decide you want to grant a subset of users in your tenancy to approve or revoke operator access control requests, without making that subset of users members of the top-security-users group, which would grant privileges to other tenancy, and other management privileges. To achieve that goal, complete the following steps

  1. Create an IAM group, opctl-prod-pci-operators.
  2. Grant members of that group privileges to grant or revoke access requests on the prod-pci compartment.
  3. Add the users to whom you want to have these privileges to the opctl-prod-pci-operators group.

For example, the following is a list of IAM Policies required for the group to grant or revoke access requests:

Allow group opctl-prod-pci-operators to use operator-control-accessrequest in compartment prod-pci
Allow group opctl-prod-pci-operators to inspect identity-providers in tenancy 
Allow group opctl-prod-pci-operators to inspect groups in tenancy
Allow group opctl-prod-pci-operators to inspect users in tenancy