Managing access to resources in OCI
In this article, we discuss how to set up a simple organization structure with OCI Identity services with multiple administrators and multiple groups. Also included are the common methods of ongoing management of users and groups after the initial setup is complete.
Organization Setup
Shown below is a common Org setup that are applicable to most organizations. Key points are:
- Two tenancy administrator having the same level of access
- Multiple groups - each able to create and manage objects they own
Resource access components
Oracle cloud recommends accessing resources through the Identity services (IDCS) account (Single-sign-on SSO based) as opposed to native login The key access components are described below.
- Compartments: A sub-folder in OCI tenancy that holds the objects (i,e instances, databases etc)
- Groups: An Oracle tenancy group that is geared to perform actions based on the assigned policies
- Policies: Set of privileges associated with a compartment (set of resources) and group (set of user / group)
- Identity service Group: Group of Identity service (IDCS) users
- Group Mappings: Mapping between IDCS groups and Oracle tenancy groups to inherit resource access through policies
Org setup workflow
The key recommendations for org structure management are:
- Manage access to resources with policies
- Assign policies to one or multiple groups requiring access to resources
The diagram below shows the workflow steps for creating the user configuration. Setting up users in Oracle cloud can be used along with the diagram below to implement the solution.
Accessing shared resources
- Sharing Block (BV) volumes or file system shares (FSS) volumes
- Typically, you would create a shared compartment for the block volumes and file system shares and would add or edit individual policies (shown below) to give access to the groups of user who manage or access the shared resources
- Sharing Object store buckets
- Sharing of object store buckets and files can be performed in the following ways
- Creating a pre-authenticated request on the object or the bucket and distributing directly to users
- Minimal administrative overhead but changes to object require generation of another pre-authenticated URL
- Buckets can be assigned to a shared compartment and can be made public or private for content visibility
- Creating a pre-authenticated request on the object or the bucket and distributing directly to users
- Sharing of object store buckets and files can be performed in the following ways
- Sharing running instances and databases
- Sharing a running compute instance or a database is outside the scope of OCI console.
- Any compute instance can be accessed through SSH as long as you have the private key and the public IP for the instance.
- Any databases can be accessed if you have the database credentials available
Object store buckets and access
Following are the most common use-cases for managing access to Object store buckets
- Setup private buckets for the group
- Create the bucket logging as the administrator managing the group in the compartment
- This ensures object store buckets be seen by the users belong the group or having access to the compartment
- You can change bucket visibility to public or private.
- Public buckets give direct access to bucket, its contents and metadata and should be used carefully
- Setup shared buckets
- Create the bucket as part of the shared compartment
- Either the PI admin or anyone having create resource privilege in the shared compartment can create the bucket
- You may set up pre-authenticated requests at bucket level to give access to other infrequent users / groups needing access to the shared bucket objects
- Third party tools access to object store buckets
- Create Customer API keys from the console
- For details, please refer to
- You may test your implementation with rclone
Adding and deleting users
It is recommended to follow the guidelines below for a streamlined managed environment.
- Never change the original tenancy admninistrator account.
- If you need to add administrator, preferably add them as identity service user and assign the administrator group to them.
- Groups and policies should be created and mapped to Identity services (IDCS) groups.
- Users should be created as IDCS users and mapped only to IDCS groups
- When deleting a user, the IDCS user only needs to be deleted.
The advantage of the above process is:
- More efficient user management - takes only a few seconds.
- All resource permissions are preserved at group level
- No resources need to be destroyed because of user deletion
- Access control is multi-layered i,e in policies, groups and users