Configuring OCI Object Storage access control policies

Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) policies are powerful tools used to control access to OCI resources, including data in the OCI Object Storage service. Because OCI IAM policies aren't always intuitive to configure, this blog post covers how to use OCI IAM policies to control access to OCI Object Storage buckets and objects. We provide sample policies and tips to help you set up accurate policies. Get started with foundational knowledge by reading the post on using policies to secure OCI Object storage. This post is a more focused look, covering specific access control policy settings to secure OCI Object storage.

Overview

OCI IAM policies allow secure access to OCI cloud resources. An OCI IAM policy allows some action to happen. Cloud resources have an implicit deny setting, which means that no actions are allowed by default until policies are applied to a resource. The following basic policy syntax allows an action:

Allow  to  in  where

^{Figure 1: Policy format}

Subject

The subject specifies who can perform the action described in the verb. A policy subject must be a group. It can't be a security principal or a user. So, the subject must be one of the following items:

• The name of a group or dynamic group

• The OCID of a group or dynamic group

• The special "any-user" group (any security principal)

The subject in the policy statement can be one or more comma-separated groups specified using the group's name or OCID, or specify "any-user" to cover all users in the tenancy.

Syntax: group | group id | dynamic-group | dynamic-group id | any-user

If you're using domains, the policy syntax uses the following form:

Allow / to  in  where

The domain name must be specified with the subject.

Syntax: group ''/'' | group id | dynamic-group ''/'' | dynamic-group id | any-user | service ''

Verb

The verb specifies the action allowed by the policy to be performed by the subject. The verb can be "inspect," "read," "use," or "manage" in order of least amount of ability to most. The exact meaning of each verb depends on which resource-type it's paired with.

Resource type

The resource type specifies the OCI resource that the policy applies to. The resource type defines the family of resources, such as cluster family, instance family, and object family. The resource type "object-family" covers buckets and objects. For details on verb and resource types for Object Storage, refer to Resource-Types.

Location

The location can specify the tenancy or compartment specified using the compartment's name or OCID that the policy applies to.

Syntax: [ tenancy | compartment | compartment id ]

Conditions

The conditions can specify one or more conditions. Use "any" or "all" with multiple conditions for a logical OR or AND.

• Syntax for a single condition: variable = | != value

• Syntax for multiple conditions: any | all {,,...}

You can apply conditions to a specific region. To create a policy that gives access to a specific region or availability domain, use the request.region or request.ad variable with a condition. Multiple variables are supported when adding conditions to a policy.

For more information, refer to General Variables for All Requests. For information specific to object and archive storage, see Details for Object Storage, Archive Storage, and Data Transfer.

Setting up policies

You can use the Policy Builder in Oracle Cloud Console by navigating to Identity and selecting Policies and then Policy Details to configure IAM policies.

^{Figure 2: Create IAM policy in the Oracle Cloud Console}

^{Figure 3: OCI Policy Builder}

For examples on how to scope access in a policy by using granular permissions, source IP address, and restricting access by time, see Advanced Policy Features.

Object Storage policy examples

The following example policies demonstrate how policies work, examples of common policies and policy reference for object storage:

Generic tenancy-wide policies

The following examples show high-level policies to get you started with Object Storage.

/* Allow admins to manage buckets & objects in tenancy */

Allow group ObjectAdmins to manage buckets in tenancy

Allow group ObjectAdmins to manage objects in tenancy

/* Service policy to allow object storage service to act on behalf of user */

    Allow service objectstorage- to manage object-family in compartment 

/* To allow OS service to use customer keys in encrypted buckets.*

    Allow service objectstorage- to use keys in tenancy 

/* To allow object storage service in multiple regions to use keys */

    allow service objectstorage-us-ashburn-1, objectstorage-us-phoenix-1to use keys in compartment ABC

Compartment-wide policies for specific users

Use the following examples to set policies on buckets and objects at a compartment level or through a specific bucket tag or specific operations.

/* Let group of users read or write to a particular bucket in a compartment*/

    Allow group ObjectWriters to read buckets in compartment ABC

    Allow group ObjectWriters to manage objects in compartment ABC

    where all {target.bucket.name= 'BucketA', any {request.permission= 'OBJECT_CREATE', request.permission='OBJECT_INSPECT'}}

/* Limit write access by bucket tag */

    Allow group ObjectWriters to read buckets in compartment ABC

    Allow group ObjectWriters to manage objects in compartment ABC

    where all {target.bucket.tag.MyTagNamespace.TagKey= 'MyTagValue' , any {request.permission= 'OBJECT_CREATE' , request.permission= 'OBJECT_INSPECT' }}

/* Let users download from particular bucket */

    Allow group ObjectReaders to read buckets in compartment ABC 

    Allow group ObjectReaders to read objects in compartment ABC where target.bucket.name= 'BucketA' 

/* Limit read access by bucket tag */ 

    Allow group ObjectReaders to read buckets in compartment ABC 

    Allow group ObjectReaders to read objects in compartment ABC where target.bucket.tag.MyTagNamespace.TagKey= 'MyTagValue'

Policies for using customer-managed keys

The following examples show how you can set up policies to use your own encryption keys:

/* Let users access customer data in object storage encrypted with customer managed key in any region */ 

    allow group  to manage vaults in compartment  

    allow group  to manage keys in compartment  

    allow group  to manage key-delegate in compartment  

    allow group  to use object-family in compartment  

    allow any-user to use keys in compartment  where 

    all {request.principal.type =  'service' , request.service.name = /objectstorage-*/} 


/* Let object storage service in a region use keys */ 

    Allow service objectstorage- to use keys in compartment ABC where target.key.id =  '' 


/* Let object storage service use keys in the vault */ 

    allow service objectstorage- to use keys in compartment Compartments where target.key.id = ocid1.key.oc1........

Restrictive bucket-level policies

OCI recommends that you set up policies at a fine granularity to adhere to the principal of least privilege. You can set up more IAM policies to restrict access even further, as shown in the following example:

/* Restrict group access to specific buckets by name or pattern */ 

    Allow group BucketUsers to use buckets in tenancy where target.bucket.name= 'BucketFoo' 

    Allow group BucketUsers to use buckets in tenancy where target.bucket.name=/ProjectA_*/ 

/* Restrict group access to read or write objects in specific buckets */ 

    Allow group BucketUsers to read buckets in tenancy 

    Allow group BucketUsers to manage objects in tenancy 

    where all {target.bucket.name= 'BucketFoo' ,  

               any {request.permission= 'OBJECT_INSPECT' ,  

                    request.permission= 'OBJECT_READ' }} 

    Allow group BucketUsers to read buckets in tenancy  

    Allow group BucketUsers to manage objects in tenancy 

        where all {target.bucket.name= 'BucketFoo' ,  

                    any {request.permission= 'OBJECT_INSPECT' ,  

                         request.permission= 'OBJECT_CREATE' }} 

/* Restrict group access to read or write objects in specific buckets based on tags */ 

    Allow group BucketUsers to read buckets in tenancy 

    Allow group BucketUsers to manage objects in tenancy 

          where all {target.bucket.tag.MyTagNamespace.TagKey= 'MyTagValue' ,  

                     any {request.permission= 'OBJECT_INSPECT' ,  

                          request.permission= 'OBJECT_READ' }} 

    Allow group BucketUsers to read buckets in tenancy  

    Allow group BucketUsers to manage objects in tenancy 

        where all {request.principal.group.tag.MyTagNamespace.TagKey=target.bucket.tag.MyTagNamespace.TagKey,  

                    any {request.permission= 'OBJECT_INSPECT' ,  

                         request.permission= 'OBJECT_CREATE' }}

Restrictive object-level policies

OCI Object Storage now supports object-level access control. The following examples use granular policies that apply to individual objects or group of objects by object-prefix or pattern:

/* Restrict access to read or write objects or groups of objects by prefix or pattern */ 

    ALLOW GROUP object-authZ-op-group-ost-object TO manage objects IN TENANCY where 

    any {target.object.name =  'ost-object-*' , request.operation =  'GetObject' } 

/* Restrict access to objects by prefix */ 

    ALLOW group test-group TO manage objects IN TENANCY where all {target.bucket.name =  'test-bucket' , target.object.name =  'prod/*' }  

/* Restrict access to a group to read only  forobjects */ 

    ALLOW group test-group TO manage objects IN TENANCY where 

        all {target.bucket.name =  'test-bucket' , target.object.name =  'prod/*' , any{request.permission= 'OBJECT_INSPECT' , request.permission= 'OBJECT_READ' }} 

/* Restrict access to a particular user to a group of objects by pattern */ 

    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..exampleuniqueID' } 

/* Restrict resource access to a particular user */ 

    Allow any-user to read object-family in compartment ObjectStorage where request.user.id = 'ocid1.user.oc1..'

Restrict access from a network source

OCI supports the creation of a network source. A single network source can include IP addresses from a specific virtual cloud network (VCN), public IP addresses, or both. To specify the VCN, you need the VCN OCID and the subnet IP ranges that you want to allow, such as the following examples. To allow any IP address from a specific VCN, use 0.0.0.0/0.

• Public IP addresses or CIDR blocks: 192.0.2.143 or 192.0.2.0/24

• VCN OCID: ocid1.vcn.oc1.iad.aaaaaaaaexampleuniqueID

• Subnet IP addresses or CIDR blocks: 10.0.0.4, 10.0.0.0/16

After creating a network source, input "corpnet" through the Console or API. You can set up a policy to allow access from it to Object Storage by using the network source variable in a condition.

/* Restrict access from allowed IP address (by creating a Network source) */ 

    Allow group CorporateUsers to manage object-family in tenancy where request.networkSource.name= 'corpnet'

Prevent accidental deletions

The following example shows policies to avoid issues because of accidental or unintentional operations:

/* Prevent delete of buckets & objects */ 

    Allow group BucketUsers to manage objects in tenancy 

        where request.permission!= 'OBJECT_DELETE' 

    Allow group BucketUsers to manage buckets in tenancy 

        where request.permission!= 'BUCKET_DELETE' 

/* Prevent delete of buckets & objects for specific bucket */ 

    Allow group BucketUsers to manage objects in tenancy 

        where any {target.bucket.name!= 'BucketFoo' ,  

                    all {target.bucket.name= 'BucketFoo' , 

                         request.permission!= 'OBJECT_DELETE' }}

Lifecycle management

Object lifecycle management allows OCI Object Storage to perform actions like archiving or deleting objects on behalf of the user. The service must be given the access permissions to be able to automatically perform these actions.

/* Service permission for OLM */ 

    Allow service objectstorage- to manage object-family in compartment  

/* More restrictive permissions */ 

    Allow service objectstorage- to manage object-family in compartment  

    where any {request.permission='BUCKET_INSPECT', request.permission= 'BUCKET_READ' , request.permission= 'OBJECT_INSPECT' , request.permission= 'OBJECT_UPDATE_TIER' , request.permission= 'OBJECT_DELETE' , request.permission= 'OBJECT_VERSION_DELETE' }

Cross-tenancy access

Users in one tenancy can access Object Storage in a different tenancy using cross-tenancy access policies. To access and share resources, the administrators of both tenancies must create special policy statements that explicitly state the resources that can be accessed and shared. These special statements use the words "define," "endorse," and "admit."

/* Source Tenancy Policy statements */ 

    Define tenancy DestinationTenancy as ocid1.tenancy.oc1.. 

    Endorse group StorageAdmins to manage object-family in tenancy DestinationTenancy 


/* Destination Tenancy Policy statements */ 

    Define tenancy SourceTenancy as ocid1.tenancy.oc1.. 

    Define group StorageAdmins as ocid1.group.oc1.. 

    Admit group StorageAdmins of tenancy SourceTenancy to manage object-family in tenancy  

/* More restrictive policy  for compartment within tenancy */ 

    Define tenancy SourceTenancy as ocid1.tenancy.oc1.. 

    Define group StorageAdmins as ocid1.group.oc1.. 

    Admit group StorageAdmins of tenancy SourceTenancy to manage object-family in compartment SharedBuckets

Tips

Consider the following tips as you work with IAM policies in OCI:

• OCI IAM policies don't support a "deny" action. Only the "allow" action is supported. By default, everything is denied.

• Use "any-user" as the subject for policies that apply to all users in all groups only.

• Some policies allow using name or ocid, but the keyword must be different. For example, you can use "group" with and "group id" with the . Don't use group and provide an OCID, which produces an error.

• If a user has access problems, ensure that the user is a part of the group that has been given access in the policy.

• Sometimes, the compartment names mentioned in the policy are incorrect or have incorrect case. Review the policy statements to ensure that the correct names are being used.

• OCI buckets are regional. A common mistake is to attempt access to a bucket in another region. Verify that you're subscribed to the OCI region where the bucket exists.

Conclusion

Use the examples in this blog post as guidance to set OCI IAM policies correctly to use and protect OCI Object Storage resources. Use the links to the OCI documentation embedded in the post or linked at the end for details on specific aspects of policy syntax. Use the Policy Builder in the Oracle Cloud Console to create polices and resolve errors.

To understand OCI IAM policies, syntax, Object Storage Policies, common policy examples, and more, see the following resources in the following Oracle Cloud Infrastructure documentation resources:

• How policies work

• IAM policy syntax

• Policy verbs and resource-types

• General policy reference

• Advanced policy features

• Object Storage policies

• Object Storage verb and resource-type combinations

• Managing bucket permissions

• Managing object permissions

• Common policies examples

• Securing Object Storage with IAM policies

• Required policies for object lifecycle management

• Using object lifecycle management policies with filters

• Object lifecycle policies

• Cross-tenancy policy

• Policies overview blog

Public link

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