This article presents an OCI security architecture that promotes a Least Privileged security posture by allowing an OCI administrator to assume different "personas" to manage OCI resources in a tenancy.
Each individual persona, that a particular OCI user can assume, distills the OCI permissions associated with the user down to the minimum permissions needed to accomplish a particular subset of OCI administrative tasks, that the tenancy implementers chose to associate with the assumed persona.
Least privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. ~ Saltzer and Schroeder [Saltzer 75] in Basic Principles of Information Protection, page 9
Consider the following, common, requirement in OCI :
An OCI user has associated OCI IAM policies that allows the user to manage the resources associated with a number of separate Deployment Environments within an OCI tenancy (e.g. Production, Test, Development). Administrative segregation between the environments is implemented using OCI compartments, groups and IAM policies that grant users, who are members of certain entitlement groups, permissions to manage, use & read specific kinds of resources in the environments.
An example is presented in the following diagram that illustrates a slice of OCI DB resources partitioned across the mentioned environments' compartments together with associated entitlement groups and IAM policies.
In our example three entitlement groups are created and referenced in policy statements that:
Imagine that JDoe is a database resource administrator who has to manage DB resources in all the environments and is therefore a member of all the mentioned entitlement groups.
This situation is a burden since when JDoe has to manage these DB resources (be it via the console, CLI , API / tools such as Terraform) a simple mistake can have far reaching consequences in an environment that JDoe did not intend to make changes in. The OCI policy enforcement layer will not provide any protections around the environments since, from OCI's point of view, JDoe has the necessary entitlements to work in all the mentioned environments.
The obvious solution will be to allow JDoe to wear only one hat at a time as well as to switch between available hats as needed to match the environment being worked on.
This is what the proposed architecture will accomplish by utilizing two existing OCI features:
Every new Oracle Universal Cloud Credit (UCC) account has one default / primary Oracle Identity Cloud Service (IDCS) instance that comes pre-integrated with the account's associated OCI tenancy. This instance serves as the primordial user store for the tenancy and is the recommended route to federate 3rd Party IDPs with the account & OCI.
In addition to this primary IDCS instance OCI allows a user with the “Identity Instance Creation” Cloud Account role to create secondary IDCS Instances within the UCC account. An OCI Administrator and IDCS Administrator ( for these secondary instances ) can in turn integrate these instances with OCI to provide additional federated sign-on routes into OCI .
When OCI users want to authenticate they will have an option to select the preferred IDCS instances to use for federated sign-on.
The second OCI feature that the proposed solution will rely on is the ability to configure a group mapping ,from an IDCS instance's groups to one or more OCI "native" groups ( groups that are referenced in OCI IAM Policies. ProdDBAdmin,TestDBAdmin,DevDBAdmin in our example).
Putting the pieces together the proposed security architecture will configure, in the OCI tenancy, an IDCS instance per deployment environment. Furthermore, each IDCS instance will in turn have a unique group mapping within OCI that maps a generic IDCS entitlement group (DB Admin in our example) over to an environment/persona specific OCI native group representation of that generic entitlement.
The end result of this is that if our user logs into the OCI tenancy via, for example, the Test IDCS instance then the user will end up with only the Test persona (hat) since none of the OCI entitlement groups associated with the other environments will be mapped over to the user. The user can now go ahead and work on the Test environment with the confidence that the OCI IAM policy engine will help ensure that a mistake or misconfiguration will not cause a spillover into the Development and Production environments, in our example. When the user wants to switch personas and work in the Production environment the user will remove the Test hat by logging out of his/her current OCI session and assume the production persona by logging in using the Production IDCS instance. The IDCS instance you choose to login to OCI will determine the "persona" you assume .
There are many options for managing the users and entitlement groups in the environments' associated IDCS instances. One such option, that is practical in situations where IDCS groups are generic (not environment specific) entitlements that should be mirrored between all the environments, is illustrated in the following diagram.
In terms of our example the members of the DB Admin group are first added to the production instance using any of the supported methods that IDCS provides to provision users and groups. Next the appropriate IDCS users and groups are copied from the Production instance down to the “lower environments” ( Test and Development).
To avoid the need to re-authenticate when a user switches between personas the IDCS instances can all be federated with the same upstream SAML IDP. If we do not configure SAML Single Logout (SLO) between the IDCS instances and the shared upstream IDP then we can conveniently switch between the personas without needing to re-authenticate the user because the logout from the OCI console will not log the user out of any existing session in the shared upstream IDP .
The final architectural picture is shown in the following illustration
In the second blog post in this series we will look at the detailed steps to implement this architecture.