Minimize the number of OCI IAM Policy Statements required to implement your OCI Authorization Model - Part 1

May 6, 2024 | 8 minute read
Gordon Trevorrow
Principal Cloud Architect
Text Size 100%:

Consolidation

Introduction

In Oracle Cloud Infrastructure (OCI), Identity and Access Management (IAM) policies are evaluated for every API call to determine if the request is authorized. To prevent latency and scalability problems, OCI has set limits on the number of policy documents and statements per document in an OCI account. As an OCI administrator, one of our objectives should therefore be to minimize the number of policy documents and statements required to implement our OCI access model. Furthermore, regardless of any limitations set by OCI, it is important to optimize policies for effective management of a least-privileged OCI access model.

This article will not cover every possible strategy for optimizing policies in OCI. Instead, it focuses on some easily implementable techniques that can be applied to refactor existing IAM policies within an account. Many of these techniques can be considered temporary workarounds that are primarily useful when approaching or reaching the policy limits in your account. Please note that this blog post will not cover the OCI tag-based policy approach. This approach is the preferred long-term strategy for providing a more permanent solution for an account that is nearing or has already reached its policy service limits.

Eliminate Exact Duplicates

In OCI, policy administrators can duplicate policy statements within an OCI account. A common cause of duplicate policies occurs when different groups manage policies within the same scope without proper coordination. Eliminating exact duplicate policy statements is a straightforward optimization. However, addressing the root cause of uncoordinated management of account policies within an organization can be challenging due to the organizational factors that initially caused the issue. Figure 1 illustrates exact duplicate statements attached to the same compartment.

Figure-1
Figure-1

 

Figure-2 illustrates a variation of the duplicate policy scenario. It shows that the duplicate policy is attached to a child compartment of a containing parent compartment where the same policy, in terms of the permissions granted, is already attached. The duplicate policy attached to the child compartment B , is unnecessary because OCI IAM policy inheritance ensures that compartments inherit all policies from their parent compartments in the compartment family tree, all the way up to the root compartment of the tenancy.

Figure-2
Figure-2

Remove less-permissive policies that are being superceded by more permissive policies.

When creating a policy that grants subjects the ability to inspectreaduse, or manage a specific OCI resource type, you are essentially granting them a predefined set of permissions associated with the verb-resource combination. The range of available verbs, starting with inspect and progressing to readuse and manage grants increasingly higher levels of permission. Each higher level of permission also includes the permissions associated with the lower levels. For example, manage encompasses the permissions associated with useread, and inspect.

 

Keep this in mind, along with policy inheritance, when examining the scenario shown in Figure 3. The policy attached to compartment A includes a reference to manage virtual-network-family .This reference assigns permissions at the compartment A level, which includes the permissions granted by the policy attached to compartment B, since manage virtual-network-family includes all the permissions granted by use virtual-network-family . Therefore, we can remove the policy attached to compartment B since those permissions are inherited at compartment B from the policy attached to compartment A.

Figure-3
Figure-3

There are several slight variations of the scenario mentioned above. In Figure 4, we can observe a case where some of the permissions given by the manage verb in the previous example are explicitly mentioned in the policy statement attached to compartment B. As with the previous scenario, the policy attached to compartment A has already granted these permissions in compartment B, rendering the policy attached to compartment B redundant.

Figure-4
Figure-4

 

More nuanced examples

Up to this point, we have discussed examples that are easy to understand when we keep in mind how policies use verbs and inheritance to grant permissions. Figure 5 presents the same scenario as in Figure 4 but expressed in terms of policy conditions:

where any {request.permission = SECURITY_LIST_UPDATE, request.permission = SECURITY_LIST_MOVE}

 

The common intuition, when a condition is added to an inherited privilege, is that the policy statement attached to compartment B, in this example, will have higher priority within compartment B and all its sub-compartments. This means that the condition attached in compartment B will further restrict or modify the inherited privilege within that scope. This intuition is incorrect. If multiple policies are in scope for a specific required permission, the policy that grants the permission will always take precedence, regardless of where it is attached in the compartment hierarchy. (*)

Specifically, when the NetworkAdmin group attempts to perform an operation in compartment B that requires a virtual-network-family permission other than the SECURITY_LIST_UPDATE and/or SECURITY_LIST_MOVE permissions, referenced in the condition, the OCI policy engine will find two policy statements that are in scope. The one attached to compartment A, through policy inheritance, and the one attached to compartment B. The policy engine will then evaluate if any of these in-scope policy statements grant the permission(s) required by the operation that the NetworkAdmin is attempting. In our scenario, it will find that the policy attached to compartment A grants the permission(s) and it will therefore allow the operation regardless of the fact that the policy attached to compartment B does not allow the permission .

(*) This is a result of OCI's least-privileged access model. Initially, users have no granted permissions, but they can gain permissions through in-scope policy statements that grant users permissions. The trajectory is always to accumulate more permissions. Once a permission is granted, it cannot be restricted by another in-scope policy statement. More permissive policies always take precedence.

Figure-5
Figure-5

 

A more nuanced example is shown in Figure 6. This example demonstrates a more restricted policy with a condition that is not directly related to policy permissions, but instead focuses on the value of one of the request variables.

 

As discussed earlier, the more permissive policy attached to compartment A will again render the policy attached to compartment B unnecessary. The group will be granted the manage permissions in compartment B even if the condition of the policy attached to compartment B evaluates to false.

Figure-6
Figure-6

Consolidate Group Membership

The primary focus of the scenarios in this section is to optimize the number of policy statements by focusing on the groups, and their memberships, that are referenced in the policy statements.

Figure-7 displays two nearly identical policies, with the differences being the referenced groups in each policy statement, the scope referenced in the policies, and where they are attached. 

Figure-7
Figure-7

 

If we know that the groups NetworkAdminA and NetworkAdminB have the same membership (*), we can optimize the policies by combining them into one statement. This statement will be attached to a shared ancestor of compartments B and C, as shown in Figure 7.1.

Figure 7.1
Figure-7.1

However, this situation allows members to have the assigned permissions in the parent compartment A in our example. To address this, we can include a condition in the combined policy statement. This condition would restrict access to the parent compartment A by the two groups in question. For example :

Allow group NetworkAdminB,NetworkAdminC to manage virtual-network-family in compartment A where any {target.compartment.name='B',target.compartment.name='C'} 

 

Consolidating NetworkAdminB and NetworkAdminC into a single NetworkAdmin group simplifies the access model. In addition to reducing the number of policy statements needed to implement the access model, this consolidation can enhance efficiency, clarity, and consistency between the access control system and the overall organizational structure. The policy statement attached to the common parent compartment of compartment B and compartment C can then be written as:

Allow group NetworkAdmin to manage virtual-network-family in compartment A where any {target.compartment.name='B',target.compartment.name='C'}

NetworkAdminB & NetworkAdminC have diffrent members

In the scenario illustrated in Figure 7, if the memberships of NetworkAdminB and NetworkAdminC are different, we can still consolidate the two policies by modifying our consolidated policy statement conditions as follows:

Allow group NetworkAdminB,NetworkAdminC to manage virtual-network-family in compartment A where any {all { target.compartment.name='B',request.groups.id=OCID_of_NetworkAdminB },all { target.compartment.name='C', request.groups.id=OCID_of_NetworkAdminC}}

 

(*)  This can occur when the implemented Role Based Access model is more fine-grained than the organization's real-world IT division of labor.

A related scenario,

which is also more common, is when you have two or more groups that have different memberships but still require the same permissions in OCI. To optimize the number of required policy statements in the account, you can use the same form of policy statement that references multiple groups in the statement. For example, the following two policies :

Allow group NetworkAdminA to use virtual-network-family in compartment AB_SharedNetwork 
Allow group NetworkAdminB to use virtual-network-family in compartment AB_SharedNetwork

 

Can be consolidated into a single policy statement:

Allow group NetworkAdminA, NetworkAdminB to use virtual-network-family in compartment AB_SharedNetwork

 

Conclusion

Let's conclude Part 1 here. In Part 2, we'll examine a few more strategies for minimizing the number of policy statements needed to implement our chosen OCI access model.

Resources 

OCI IAM Policy Syntax

OCI IAM Policy Refrence 

Using Tags to manage Resources 

 

 

Gordon Trevorrow

Principal Cloud Architect


Previous Post

Comparing Oracle ETL/ELT Tools

Elói Lopes | 16 min read

Next Post


Oracle Fusion Cloud Bill Management – External User Setup

Manoj Shetty | 5 min read