Working with identity and access management (IAM) in Oracle Cloud Infrastructure

September 22, 2020 | 5 minute read
Text Size 100%:

In our previous post, we talked about Oracle Cloud Infrastructure (OCI) tenancies, compartments, and regions. We also mentioned access policies, specifically in relation to compartments. This post provides more details about the Identity and Access Management (IAM) and IAM policies, and introduces the concepts of users, groups, and dynamic groups.

Identity and Access Management

IAM has multiple parts, as shown in the following figure.

Figure 1: Parts of Identity and Access Management


Let’s consider a scenario in which you create a virtual machine (VM) that resides in a compartment and want to control access to that VM. How can you give access permissions to that VM to a group of users?


The first thing you do is create a group you can put the users in. If you’re the person who created the cloud account, you should be a part of the Administrators group by default.

Let’s create a group called Developers

  1. In the OCI Console, open the navigation menu, select Identity, and then select Groups.
  2. Click Create Group.
  3. In the dialog box, name the group Developers, enter a description, and then click Create.
Figure 2: Developers Group Details Page


After the group is created, you can add users to it.

  1. On the group’s details page, click Add User to Group.

Tip: To create new users, open the navigation menu, select Identity, and then select Users.

Groups can have multiple users, and these users can be part of multiple groups.

Dynamic Groups

Dynamic groups contain cloud resources instead of users. The resources in dynamic groups (most typically, but not exclusively, compute instances) are given access to make API calls against other Oracle Cloud Infrastructure services.

  1. To create a dynamic group, open the navigation menu, select Identity, and then Dynamic Groups.
  2. Like with user groups, provide a name and description.
  3. To select the resources that belong to the dynamic group, write matching rules. For example, to match all instances with a specific OCID, you could write the following rule:
All { = 'ocid1.instance.oci1.iad..example'}

After you define your groups and dynamic groups, you can define policies.


Access to compartments (and subsequently to any resources within a compartment) is controlled through policies that the tenancy administrator creates.

A policy is a collection of one or more statements that follow this syntax:

Allow group <group_name> to <verb><resource_type> in compartment <compartment_name> where <condition>

According to this syntax, a policy specifies who (a group) can access which resources (resource type in a compartment) and how (verb) and under what condition (condition is optional). Policy statements always begin with the word Allow, which means that by default users can do nothing, except change their password and manage API signing keys and other credentials. Users must always be explicitly granted access to resources through policies.

For example, the following policy statement allows a group called Developers access to manage all resources in the Project-A compartment:

Allow group Developers to manage all-resources in compartment Project-A

With this statement, any user in the Developers group can manage all the resources in the compartment. The “manage” verb gives the group all permissions to the resources. This policy example might be too broad for the permissions assigned to a group called Developers. The “manage” verb is more appropriate for administrators.

A better approach for a Developers group might be to use a verb that grants fewer permissions - for example, use. The use verb is more appropriate for the end-users of the resource. There are two other verbs: inspect and read. To read more about verbs and the types of access they cover, see the Policy Reference.

Policy Granularity

Another way to write more granular policies is to give groups access to the following kinds of resources:

  • A family of resources that are managed together - for example, an instance-family that contains instances, images, volume attachment, and so on
  • Individual resource types - for example instances
  • A single resource type, where you use the condition to target a specific resource with an OCID

You can read more about different resource types in the Policy Reference.

The following policy statement allows the Developers group to manage VMs within the Project-A compartment:

Allow group Developers to manage instances in compartment Project-A

You can also refer to the compartment and groups by their OCIDs, by adding the word id. For example:

Allow group Developers to manage instances in compartment id ocid1.compartment.oc1..example

If you want to get even more granular, you can use the where clause and specify the instance OCID:

Allow group Developers to manage instances in compartment Project-A where'ocid1.instance.oc1..'

For more details about the variables that you can use in the conditions, see the Policy Reference.

Create a Policy

  1. In the OCI Console, open the navigation menu, select Identity, and then select Policies

  2. Click Create Policy to open the Create Policy dialog box.

Figure 3: Create Policy Dialog Box

Note that you can have multiple policy statements in one policy, which lets you create fine-grained policies for your groups. For a more detailed explanation of the policy syntax, see the documentation.


In this post, we explained the basics of IAM in Oracle Cloud Infrastructure. You have learned how to create new groups and dynamic groups, and write policy rules that give permissions to access different resources in compartments.

Additional resources

Every use case is different. The only way to know if Oracle Cloud Infrastructure is right for you is to try it. You can select either the Oracle Cloud Free Tier or a 30-day free trial, which includes US$300 in credit to get you started with a range of services, including compute, storage, and networking.

Peter Jausovec

Peter Jausovec is a Consulting Solution Architect at Oracle working on cloud-native solutions. He has more than a decade of experience in the field of software development and tech, in various roles such as QA (test), software engineering and leading tech teams. He's been working in the cloud-native space for the past couple of years, and delivering talks and workshops around the world. He authored and co-authored a couple of books, latest being Cloud Native: Using Containers, Functions, and Data to Build Next-Generation Applications.

Previous Post

Introduction to the key concepts of Oracle Cloud Infrastructure

Peter Jausovec | 6 min read

Next Post

Accessing the Oracle Cloud Infrastructure API Using Instance Principals

Prasenjit Sarkar | 6 min read