Announcing object level granular access control for OCI Object Storage

Today, we're announcing the general availability of object-level granular access controls for the Oracle Cloud Infrastructure (OCI) Object Storage service in all commercial regions. With Object Identity and Access Management (IAM), you can now set access control policies at an object level and enable workloads, such as Hadoop, data lakes, and internet of things (IoT), that share a single bucket with millions of objects with multiple applications.

You can create access control policies at the bucket level and manage access controls to all objects in the bucket. However, workloads like Hadoop often write millions of objects into a few large buckets that are then accessed and processed by dozens to hundreds of higher-level applications and users. Each of these applications and users require a unique set of access privileges for individual objects. Now, with Object IAM, you can create access control policies that govern permissions at the granularity of a single object and specify which operations are allowed by each user or application.

Object IAM enables the following features:

• Granular control: provides granular control over individual object or a group of objects.
• Enhanced security: Using object-level access control, you can restrict user access to a particular set of operations, such as Get, Create, Delete, Rename, and Copy.

A large data lake customer can use this functionality with the following strategy. For example, you have three different datasets (directories or object names with a common pattern) in a shared bucket and the users and groups need to be given different levels of access to the data, which can change over time:

• Dataset 1: Active data from a current project
  • Group 1 is given read and write access to the dataset 1 within the bucket because this group generates the data as and processes it for trend analysis.
  • Group 2 is given read and copy access to dataset 1 because they use the data for machine learning (ML).
  • Group 3 is given read-only access to process data across multiple datasets.
• Dataset 2: Data from a previously completed project.
  • Group 3 is given read-only access to process data across multiple datasets.
  • No users have write or delete access to dataset 2.
• Dataset 3: Active data from another project.
  • User Y has full access to the dataset, including list, read, write, delete, or copy.

Configuring Object IAM Policies

Object Storage administrators can now set up object-level policies for a bucket from the Oracle Cloud Console or by using the CLI, API or Terraform. The process to create object-level policies is the same as that for bucket-level policies. The new IAM policy variable target.object.nameenables you to apply authorization and permissions to objects.

Policies only allow access; they can't deny access. Denial of access is implicit, which means that by default, users can do nothing and must be granted access through policies. If no Object IAM policies exist, users have access based on policies set at the compartment or bucket level. The policies are cumulative and inherited down: Compartment, Bucket, then Object.

To create a new policy or manage an existing policy, use the following steps:

1. In the Console, go to the Identity & Security menu and choose Policies - a list of the policies is displayed.
2. Either create a policyor select an existing policyto view its details.
3. Use the Policy Builderor click Edit Policy Statementsto add rules.

In addition to viewing and editing an existing policy, you can also delete it.

Policy statements always begin with the word Allow. See the following examples:

• Example 1: Allow full access to a group for a folder 'prod' in a bucket 'test-bucket':
  • Allow group test-group TO manage objects IN TENANCY where all {target.bucket.name = 'test-bucket', target.object.name = 'prod/*'}
• Example 2: Allow read-only access to a group for a folder 'dev' in a bucket 'test-bucket':
  • Allow group test-group TO manage objects IN TENANCY where all {target.bucket.name = 'test-bucket', target.object.name = 'dev/*', any{request.permission='OBJECT_INSPECT', request.permission='OBJECT_READ'}}
• Example 3: Allow write-once (no overwrites) and no read or delete access to a group for a folder 'prod' in a bucket 'test-bucket':
  • Allow group test-group TO manage objects IN TENANCY where all {target.bucket.name = 'test-bucket', target.object.name = 'prod/*', any{request.permission='OBJECT_CREATE'}}
• Example 4: Read and write access to a group for a folder 'dev' in a bucket 'test-bucket' (no listing or overwriting):
  • Allow group test-group TO manage objects IN TENANCY where all {target.bucket.name = 'test-bucket', target.object.name = 'dev/*', any{request.permission='OBJECT_CREATE', request.permission='OBJECT_READ'}}
• Example 5: Granting all access for a specific user for an object pattern '*.pdf' in the bucket 'test-bucket':
  • Allow any-user TO manage objects IN TENANCY where all {target.bucket.name = 'test-bucket', target.object.name = '*.pdf', request.user.id='ocid1.user.oc1..aaaaaaaaasdasdasdasdssltbz7dwqb2h3qd4lrf6enng4mtfu5gio6il57a'}

After a policy is configured, it enables object-level access control. In most cases, policies become active within five minutes. Policy authorization is evaluated when a request arrives for an object, so a policy change applies after the policy has been propagated. Object IAM policies apply to both existing and new objects.

Conclusion

Public link

Please use the above public link if you want to share this noodl on another website.