Break New Ground
-
Cloud
September 22, 2020
Working with identity and access management (IAM) in Oracle Cloud Infrastructure
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.
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?
Groups
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
- In the OCI Console, open the navigation menu, select Identity, and then select Groups.
- Click Create Group.
- In the dialog box, name the group Developers, enter a description, and then click Create.
After the group is created, you can add users to it.
- 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.
- To create a dynamic group, open the navigation menu, select Identity, and then Dynamic Groups.
- Like with user groups, provide a name and description.
- 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 {instance.id = 'ocid1.instance.oci1.iad..example'}
After you define your groups and dynamic groups, you can define policies.
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 target.instance.id='ocid1.instance.oc1..'
For more details about the variables that you can use in the conditions, see the Policy Reference.
Create a Policy
-
In the OCI Console, open the navigation menu, select Identity, and then select Policies
-
Click Create Policy to open the 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.
Conclusion
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.