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.
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:
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
Create an IAM group,
opctl-prod-pci-operators.
Grant members of that group privileges to grant or revoke access
requests on the prod-pci compartment.
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