How to Restrict Root Access to VMs with Exadata Database Service

Oracle has recently made some slight changes to the permissions required to manage resources with Exadata Database Service. These changes will now allow you to provide more fine-grained access control to various resources in the service. Let’s take a look at what has changed.

There are plenty of blogs and documents that explain how permissions are granted via policies in Oracle Cloud, so we won’t cover that topic in detail here. To sum it up, you assign users to groups, and using policies you assign permissions to those groups enabling users in the group to access resources.

A policy statement takes the form:

Allow <subject> to <verb> <resource type> in <location> where <conditions>

The graphic below provides more details on the policy statement:

While easier to use aggregate resource types, the key to providing fine-grained access to resources is to use individual resource types as opposed to aggregate resource types. You also may want to limit access to a certain group to specific compartments (location) and can restrict the permission even more using the where conditions.

Exadata Database Service has a multi-level parent-child resource hierarchy. At the top level, we have infrastructures, with VM Clusters as children. Databases (CDBs) are children of VM Clusters, and PDBs are children of CDBs. These relationships are important as they help you understand the implications of changes to parent resources on child resources. To MANAGE (ability to perform create/update/delete operations) child resources, we required you have the ability to USE (ability to perform read/update operations) the parent resource. This type of relationship is common for many types of resources both inside and outside Oracle Cloud. For example, you cannot create or delete a file in a file system unless you can read and update the file system. So, as a convenience to users, when you grant MANAGE to a child resource, we automatically grant USE to the parent resource.

While this makes perfect sense for some customers, other who are trying to implement stricter separation of duties find it too generous. For example, they would like to have a group of DBAs have the ability to MANAGE the databases, including creating, patching, and deleting databases, but don’t want those users to have USE access to all the resources of the cluster. Specifically, they do not want those users to have root access to the VMs in the cluster. Granting the DBA group the MANAGE permission on databases also grants the USE permission on VM Clusters, and with those permissions, a customer can inject a key for the opc user and sudo to root.

The solution to granting the necessary permissions to DBAs without giving them root permissions is to qualify the policy statement granting permission with a where clause and narrow the permission context. Review this policy for instance.

Allow group DBAdmins to MANAGE databases in compartment <xyz>

It will implicitly grant USE permissions on VM Clusters, which includes the permissions to INSPECT the VM Cluster (VM_CLUSTER_INSPECT) and to USE the VM Cluster (VM_CLUSTER_UPDATE). VM_CLUSTER_UPDATE enables users to provision new SSH keys for the opc user. Using the where clause, you can choose to give the DBA group only specific permissions omitting VM_CLUSTER_UPDATE, or you can block VM_CLUSTER_UPDATE. The examples below show both alternatives.

Now what has recently changed? As mentioned earlier, the control plane has previously checked for USE permission on the parent when you perform an operation that requires MANAGE on the child. This meant that it checked for VM_CLUSTER_UPDATE when a DBA attempted to manage the database. In other words, you couldn’t exclude the VM_CLUSTER_UPDATE permission and still manage the databases. What’s changed is we have relaxed that check and now only require the user have INSPECT permission on the cluster, and that permission does not enable the user to provision new SSH keys. So, now you are free to write a policy statement for DBAs that will allow them to manage the databases, but not have root access to the VM Cluster.

Source: oracle.com