X

Identity and Access Management: Intro to "Compartments"

Hello there, I’m Zach Okun, a Product Manager on the Oracle Bare Metal Cloud Services (BMCS) team, and I’d like to talk about our Identity and Access Management (IAM) Service. Specifically, I’d like to talk about our approach to IAM and introduce a concept called compartments.

Because we are building a cloud for enterprises who have strict requirements for security, governance, and control, Identity and Access Management is a fundamental component of BMCS. Our mission is to build an infrastructure-as-a-service offering that retains the best characteristics of the public cloud—pay for what you use, elasticity, scalability, self-service—while adding what has traditionally been missing—flexibility, security, consistency, reliability, governance and control.

One place where we saw a great deal of opportunity to differentiate was with Identity and Access Management. Our enterprise customers consistently talk about their struggle with “Shadow IT”, where employees are building IT solutions that don’t adhere to the company’s strict (and crucially important) requirements for control, security, reliability, etc. In speaking with these customers, we have learned that existing cloud offerings have frequently caused or enabled these problems. One especially unwieldy manifestation of this is when a company finds itself with multiple accounts with no central visibility or control. This is because there is no easy way for a company to have a single account in the cloud and then allow Line Of Business (LOB) users access to the benefits of the cloud and still retain the controls required to meet various compliance and security needs.

So we started with the premise that a single BMCS account should scale to meet the needs of enterprises of any size. By having a single account, our customer can not only put all the necessary controls in place in a single account but also easily get the type of overarching visibility they need. At the same time, any individual employee should be able to log in and feel as if they are in their own account, not bothered by the tens, hundreds, or thousands of other people sharing that account.

To achieve this goal, we introduced a concept we call compartments. Customers use compartments to organize and isolate their cloud resources in whatever way makes sense for them. Every cloud resource belongs to one and only one compartment. And policies grant permission to access specific resources inside specific compartments.

Given this construct, here are some ways you might choose to use compartments to organize your resources:

  • By Project – A single project can have all of its resources within a single compartment. This allows the administrators to easily get information about that project, and control the access and expenditure on the project.
  • By Resource – Some customers want a single resource to be managed by a single group. For example, they may want all of their networks to be administered by the NetworkAdmins group. Only allowing internet gateways to be created in one compartment, and only allowing the NetworkAdmins access to that compartment is an easy way to achieve this.
  • By Organization – For example, there could be a compartment called Finance that only finance team members have access to.
  • By Use – For example, there could be compartments for Dev, Test and Prod, to manage the resources for each of these environments separately from each other. Or, similarly, there could be Blue/Green Compartments for deploying individually.
  • By User (or Sandbox) – Compartments could be created for each developer to allow them access to resources for a specific project, or for their own use as a sandbox.
  • Combination of the above – You may choose more than one of these principles to organize your cloud resources.

The diagram below shows a combination of compartment use cases.

  • There are separate compartments for Project A and Project B.
  • And these may use the network resources that are managed in the Networking Compartment.
  • There is a compartment for the Finance department.
  • And there are compartments for: a specific developer, and a shared Sandbox environment

IAM Image.png

And this is what that might look like for an administrator in the BMCS Console—note the list of compartments down the left side; also note that the view is currently scoped to show instances only in the Project A compartment.

In short, compartments enable our enterprise customers to easily organize and isolate their resources, restrict permissions, and achieve the levels of governance, control, and visibility they need as they move to the cloud.

In my next blog post, I will discuss policies and our unique policy language that makes it easy to manage access to your cloud resources.

Join the discussion

Comments ( 1 )
  • Harpreet Singh Friday, March 1, 2019
    Really nice article. Could you please explain the meaning when u say project A and B can use network resources in network compartment; You mean to say resources can be shared among compartments?
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.