OCI Security: Manage Access to Thousands of OCI Resources With a Single Policy

A customer recently raised a requirement to have thousands of Oracle Cloud Infrastructure (OCI) Object Storage buckets, each having a different set of users who should be allowed to manage objects within it. They assumed they’d need to create a group associated to each bucket and then to write an access policy for each of those buckets. This would result in thousands of access policies and the customer asked about best practices for managing thousands of policies. The reality is that thousands of access policies can be quite difficult to manage, and that approach is almost never recommended.

A better approach for this scenario is to leverage Tag-Based Access Control (TBAC). This can be achieved using OCI resource tags, which allow you to consolidate policies. Using this process, you would still create a group for each bucket. To assign permissions to manage bucket resources, you’d add users to the associated group. Each group in OCI has a unique identifier known as an OCID. So, the critical step in this approach is to create a policy that only allows members of the associated group to manage the objects in the specific bucket. But instead of creating thousands of policies (one for each bucket), you can write one policy that enforces the access requirement across all of them.

To do that, you’d first assign a tag to each bucket resource that maps the bucket instance to its associated group. The value of the tag would match the group OCID and would look something like:

target.bucket.tag.allowed-group.group-id

In this example, the tag namespace is “allowed-group” while the tag key is “group-id”. This associates the bucket with the specific group. You can enforce tag assignments on all newly created resources in a compartment via tag defaults. This ensures that administrators can’t create buckets without assigning a tag value.

The next step would be to write a policy that allows access to all the in-scope buckets for each of their associated groups. For this policy, you’d use a where clause condition which validates that the user is a member of the group that is associated to the resource. This would look something like:

ALLOW any-user to MANAGE object-family in COMPARTMENT Storage-Compartment where ALL
{
target.bucket.tag.allowed-group.group-id  = request.groups.id
}

In this example, referencing request.groups.id allows us to validate the tag key value against the unique identifier for each group that the requestor is a member. If the requestor is a member of the group which has its ID assigned to the bucket tag, the condition will return true. Optionally, if you wanted to tag groups as well and use an indicator other than the group identifier, you could do that by implementing the where condition as:

target.bucket.tag.[tag namespace].[tag value] = request.principal.group.tag.[tag namespace].[tag value]

You can further restrict what type of access is allowed with an additional where clause condition. For example, you could add the following:

ALLOW any-user to MANAGE object-family in COMPARTMENT Storage-Compartment where ALL
{
        target.bucket.tag.allowed-group.group-id  = request.groups.id,
        ANY {
        request. operation='PutObject',
        request. operation='ListObjects',
        request. operation='HeadObject',
        request. operation='GetObject',
        request. operation='RenameObject',
        request. operation='ReencryptObject',
        request. operation='RestoreObjects'
        }
}

This condition limits the scope of what members of the associated group can do. In this case, they can view, create, or modify objects in the bucket but cannot delete objects or previous versions of those objects.

Using resource tagging, the single access policy described above allows you to enforce strong security practices across thousands of storage resources. You would also want to enforce separation of duties in this scenario so that the administrator who assigns tags to the object resources is not a member of groups established to manage access to the buckets. This ensures that resource administrators cannot simply tag their resources with their own group OCID to grant themselves unauthorized access.

For more information, see Using Tags to Manage Access. 

To learn more about OCI Identity and Access Management, please visit our website or take a product tour.