Deep dive into OCI with compartments, users, groups and policies

I’ve said it before and I’ll state it once more. One of the best services with Oracle Cloud Infrastructure is Identity & Access Management. Oracle has made managing your tenancy really easy with compartments and policies.

With compartments you can manage your single account without too much of complexity by restricting user access to specific compartments and giving only access for users inside that compartment.

For example you have a user who can only use network resources in a compartment so the user can launch new instances. This way you leave administration of network components to your OCI network admins.

IAM documentation can be found from here. It’s a very well structured documentation so I would give it a read when you start working with OCI IAM.

Policies

Policies are what define who can access resource in a specific way at a group or compartment level. You always allow with your policies and never deny as by default OCI access is defined by least privilege so if something isn’t allowed it is denied. There are four level of access:

• Inspect – you can list resources but not get the metadata or any confidential information (with network resources you still get all information!)
• Read – Same as Inspect but you get also the metadata and the resource itself
• Use – Includes read but has the ability so you can use the resource which varies by resource type. Includes also update of the resource apart from when update is the same as create (Updating security list for example)
• Manage – Includes all permissions to resource

Policy syntax is as follows:

Allow <subject> to <verb> <resource-type> in <location> where <conditions>

Which translates to:

Allow group network-admins to manage virtual-network-family in tenancy

Or if you would like to give compartment level network admin access to network components only:

Allow group projectx-network-admins to manage virtual-network-family in 
compartment ProjectX

Some resources such as users and groups are managed on tenancy level.

I’ve used a resource example which is type of a “family”. This has all related resources combined inside so you don’t need to go and allow access one by one to all network resources. Advantage is that if Oracle adds more components to network resources these will be automatically added to “family” and you don’t need to go and specify them.

But if you wan’t to give access only to individual resource-type this is certainly possible! Just be careful it doesn’t come too much of work in the long run. Policy reference with family resource-types are listed here.

So what if you have more requirements – for example you want to limit group access only to modify specific compartments. This is possible with conditions.

Online documentation says this about them:

**

Specify one or more conditions. Use any or all with multiple conditions for a logical OR or AND, respectively.

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

Syntax for multiple conditions: any|all {<condition>,<condition>,...}

**

Condition variable is always either relevant to the request itself or relevant on the resource which is being accessed. This comes always with a prefix of a request or a target.

You want to limit your group admins to be able to modify anything but the Admin group (example from Online documentation):

Allow group GroupAdmins to use users in tenancy where target.group.name != 
'Administrators'

And if you want to limit group access on specific resource-types you can use(example from Online documentation):

Allow group XYZ to manage groups in tenancy
 where any {request.permission='GROUP_INSPECT',
            request.permission='GROUP_CREATE',
            request.permission='GROUP_UPDATE'}

Normally when you grant the manage groups permission it has one additional individual resource-type: GROUP_DELETE. Now when you limit the permission not to include it then group XYZ does not have access to delete groups.

In conditions you can also use either string with single-quotes or a pattern match. Pattern match is used as /*OCI*/, /*OCI/ or /OCI*/.

Example case

Now for a typical case what might come up. Company has two or more different applications and you don’t want users to access other resources apart from what they should. In my case I will have Oracle EBS and Oracle BI as example applications. I want to have network admin group which manages networks in all compartments and admin groups for each different compartments with specific policies.

In addition I will have group for user management. Each group will have one user assigned.

Group policies what I will give are as follows.

For Network-Admins:

Allow group Network-Admins to manage virtual-network-family in tenancy

For User-Management:

Allow group User-Management to manage users in tenancy
Allow group User-Management to manage groups in tenancy

For Oracle-BI-Admin:

Allow group Oracle-BI-Admin to manage instance-family in 
compartment Oracle-BI

Allow group Oracle-BI-Admin to use virtual-network-family in 
compartment Oracle-BI

Allow group Oracle-BI-Admin to manage volume-family in 
compartment Oracle-BI

Allow group Oracle-BI-Admin to manage database-family in 
compartment Oracle-BI

For Oracle-EBS-Admin:

Allow group Oracle-EBS-Admin to manage instance-family in 
compartment Oracle-EBS

Allow group Oracle-EBS-Admin to use virtual-network-family in 
compartment Oracle-EBS

Allow group Oracle-EBS-Admin to manage volume-family in 
compartment Oracle-EBS

Allow group Oracle-EBS-Admin to manage database-family in
compartment Oracle-EBS

Allow group Oracle-EBS-Admin to manage file-family in
compartment Oracle-EBS

I’m giving quite wide permissions for both admins here. If you would like to you could always limit the access so users can’t create volumes but just use existing one for attaching etc. It depends on your use case!

Also both compartment admins get access to manage database-family. It might be that for some reason you wouldn’t want to create database through service but install it yourself. Then you wouldn’t need the database-family policy.

Group Oracle-EBS-Admin gets also policy to manage file-family. This is really good service for EBS customers as you can create the shared APPL_TOP mounts through file-family and then just mount on servers where you need to have it.

Deploying the compartment layout with Terraform

If you want you can always create everything manually with OCI. But I want to use automation and infrastructure as code so I will use Terraform to deploy these to my OCI tenancy.

With Terraform I have four different modules in their respective folders and one main folder which calls these reusable modules. Main folder has also variables defined specific for this case. So as an example when I create users I call the same module like this:

Few important things to remember. When you make policy statement variables they are passed as a list. So the variable will look like:

Remember to define type as a list in the module:

Also right now the modules I have are: “create users”, “create compartments”, “create groups with policy” and “create group relationship with user”.

I used to have separate modules for groups and policies but noticed that sometimes Terrafrom dependency didn’t work as expected even though I was passing some variables from group module to policy module.

To my understanding Terraform should then wait the referenced resource to be created first. To have a workaround I put both resources under same module which was a good and simple solution in this case.

Now I will just run familiar Terraform commands terraform init, terraform plan and finally terraform apply.

My example created total of 22 OCI resources:

Apply complete! Resources: 22 added, 0 changed, 0 destroyed.

And if I just check from the console I can see everything is there as required. Below you can see compartments and policies created.

Summary

In this post I wanted to show how easy it is to deploy base layout for your operations. You can start small and then think what kind of policies are required for users and how to have them setup in a most efficient way.

Unless there is a real requirement I wouldn’t want to make whole setup too complicated. On the other hand giving a wide access to all users could create some other issues in your setup.