Note:

• This tutorial requires access to Oracle Cloud. To sign up for a free account, see Get started with Oracle Cloud Infrastructure Free Tier.
• It uses example values for Oracle Cloud Infrastructure credentials, tenancy, and compartments. When completing your lab, substitute these values with ones specific to your cloud environment.

Deep Dive into Tag based Oracle Cloud Infrastructure Identity and Access Management Policies

Introduction

Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) policies are the cornerstone of a robust and secure cloud environment. They provide a powerful, flexible mechanism to control access to OCI resources, ensuring that only authorized users and services can perform specific actions on designated resources.

At its core, an OCI IAM policy is a set of declarative statements written in a human-readable syntax that dictates who can access what and under which conditions. These policies enable organizations to enforce the principle of least privilege, granting users and services only the permissions they need to perform their tasks and nothing more. This minimizes security risks while maintaining operational efficiency.

OCI IAM policies are applied at various levels of the OCI hierarchy, including compartments, tenancy, and specific resources, making them highly adaptable to complex organizational structures. With OCI’s policy inheritance and compartmentalization, administrators can establish granular controls tailored to their specific security and operational requirements. For more information about OCI policies, see Getting Started with Policies.

In this tutorial, we will delve into the importance of policy optimization, explore the best practices for fine-tuning policies to achieve optimal results, and highlight scenarios where policy optimization can be leveraged to its fullest potential.

Objectives

• Demystify policy components and syntax.

• Understand why tuning OCI IAM policies is crucial for scalability and policy limits.

• Provide actionable best practices.

• Emphasize the role of tagging in policy management.

• Highlight common challenges and solutions through showcasing real-world use cases.

Prerequisites

• Access to an OCI tenancy.

• Basic understanding of OCI concepts.

• Knowledge of OCI IAM.

• Familiarity with policy syntax.

• Understanding of compartmentalization and tagging basics.

• Least-privilege principle awareness.

• OCI policy limits knowledge.

• Experience with governance and compliance standards.

Demystify Policy Components and Syntax

To effectively tune OCI IAM policies, it is essential to understand their structure and key components. Policies in OCI define permissions by specifying who (principal), what (action) on what (resource), and where (scope). Let us break this down:

Key Components of an OCI IAM Policy

• Principal (Subject): The entity requesting access, which can be one of the following:

  • User: An individual account within OCI, typically representing a person. For more information, see Managing Users.

  • Group: A collection of users with shared access needs. For more information, see Working with Groups.

  • Dynamic Group: A set of OCI resources (for example, compute instances, functions) identified by specific rules. Resources in a dynamic group are automatically grouped based on criteria such as tags or metadata. For more information, see Managing Dynamic Groups.

  • Resource Principal: A service (like OCI Functions or Oracle Autonomous Database) acting on its own behalf. Resource principals allow services to securely authenticate with OCI and other resources without requiring explicit credentials. For more information, see Resource Principal Authentication.

  • Instance Principal: A type of resource principal specific to compute instances. It enables instances to directly interact with OCI services (For example, OCI Object Storage or Identity) using OCI IAM policies, without embedding credentials in the application running on the instance. For more information, see Instance Principals.

• Action (Verb): Specifies operations the principal can perform:

  • inspect: View metadata about the resource.
  • read: View metadata and data within the resource.
  • use: Perform read actions and limited management operations.
  • manage: Perform all actions, including creating and deleting resources.

  For more information, see Operations.

• Resource (Resource-Type): Defines the type of OCI resource the action applies to, such as:

  • Compute instances, storage buckets, VCNs, databases, and so on.
  • Resources can be organized hierarchically using compartments for better management.

  For more information, see Resources.

• Scope (Location): Specifies the location where the policy applies:

  • Compartment: A logical container for resources, enabling hierarchical organization.
  • Tenancy: The entire OCI account, typically used for global permissions.

  For more information, see Location.

• Matching Rule (conditions): 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>,...}.

  For more information, see Conditions.

Bonus Tip: Understanding Sets-Intersect Concept in OCI IAM Policy

The sets-intersect in OCI IAM policies is used to grant access only when there is an overlap between two sets of values. This ensures that permissions are granted dynamically based on group membership, resource tags, or other attributes, rather than hardcoding specific users or groups in policies.

• Example of Sets-Intersect in OCI IAM Policy

  Allow any-user to manage database-family-resources in tenancy
  where sets-intersect(request.groups.name, target.resource.compartment.tag.database.admins)
  
  

  Breaking Down the Policy Statement:

  • Allow any-user: This policy applies to any authenticated user in OCI (regardless of specific group membership).

  • to manage database-family-resources: Grants full administrative control over all database-related resources (autonomous databases, database systems, backups, and so on).

  • in tenancy: The policy applies to the entire tenancy (all compartments).

  • where sets-intersect(request.groups.name, target.resource.compartment.tag.database.admins)

    • request.groups.name: Represents the groups the user belongs to.
    • target.resource.compartment.tag.database.admins: A tag on the compartment that contains a list of allowed groups who can manage database resources in that compartment.
    • sets-intersect(…): Ensures that access is granted only if the user belongs to at least one group listed in the tag.

OCI IAM Policy Model for Large Scale

OCI IAM policies are one of the fundamental pieces of securing workloads on OCI. It is crucial to be able to scale and support a large workload for our customers. That is why we have created a policy model that requires a small number of policies, within OCI’s policy limits, that work for any size of workload. The following are some of the reasons to adopt the scalable policy model. For more information, see IAM With Identity Domains Limits.

Tuning OCI IAM policies is a critical task for maintaining a secure, scalable, and efficient cloud environment while staying within OCI’s policy limits. Here’s why this process is essential:

• Policy Limits and Constraints: OCI enforces specific limits on the number of policies that can be created within a tenancy and compartments. These limits can be quickly exhausted in large-scale or complex environments if policies are not optimized.

  • Key reasons include:

    • Avoid Redundancy: Repeatedly defining similar policies for different compartments or resources can lead to policy bloat, making it harder to manage.
    • Stay Within OCI Policy Limits: OCI has a maximum number of policy statements per policy and per tenancy. Tuning ensures you do not hit these limits prematurely.

• Enhancing Manageability: As organizations grow, managing hundreds of policies across multiple compartments can become unwieldy without tuning. Optimized policies:

  • Simplify management by reducing the total number of policies.
  • Improve clarity and avoid overlapping or conflicting rules, making debugging and auditing easier.

• Scalability Across Complex Environments: Tuned policies allow seamless scaling by:

  • Using wildcards and resource-level permissions where appropriate to reduce the need for compartment-specific or resource-specific rules. For more information, see Conditions.
  • Leveraging policy inheritance so that higher-level policies apply to child compartments without needing duplicative statements. For more information, see Policy Inheritance.
  • Grouping users and resources logically to apply broader but still secure permissions.

• Performance Optimization: OCI evaluates policies during every access request. A large number of redundant or overly specific policies can increase evaluation time, potentially leading to slower access control decisions. Optimized policies reduce overhead, ensuring faster and more efficient operations.

• Adhering to the Principle of Least Privilege: While tuning for scalability, it is critical to maintain the principle of least privilege. Broad, unchecked policies can compromise security, so striking a balance between minimal access and scalability is essential.

The Role of Tagging in Policy Management

Tagging is a powerful feature in OCI that significantly enhances policy management by enabling fine-grained control over resources. Tags are metadata labels, represented as key-value pairs, that can be attached to resources. They help organize, manage, and enforce access control at scale, especially in complex cloud environments with multiple teams and projects. For more information, see Tagging Overview.

How Tagging Enhances Policy Management

1. Simplifies Resource Identification: Tags provide a unified way to categorize resources based on attributes like projects, environments, owners, or departments. This simplifies the process of applying policies to specific subsets of resources.

   Example: Tagging resources with Project: ProjectX enables targeted access policies.

   Allow group Developers to manage instances in tenancy where tag.Project = 'ProjectX'
   

2. Enables Dynamic Policy Enforcement: Policies based on tags adapt to changing resource attributes. For instance, if a new instance is tagged with Environment: Production, it automatically inherits policies defined for production environments.

   Example Policy:

   Allow group QA to inspect instances in tenancy where tag.Environment = 'Test'
   

3. Streamlines Multi-Project and Multi-Team Governance: Tags help isolate access by associating resources with specific teams or projects. This reduces complexity when managing permissions across multiple groups.

4. Facilitates Automation: Tags can drive automated workflows for resource creation, monitoring, and lifecycle management. For instance, cost-tracking scripts can retrieve all resources tagged with CostCenter: Marketing to generate detailed expense reports.

5. Improves Cost Management and Reporting: Tags enable granular cost attribution to specific projects, departments, or environments. This helps organizations track spending and optimize budgets more effectively.

Tag Governance: Controlling Tag Management

To maintain consistency, reliability, and security in policy management, tag creation and modification should be tightly controlled. Governance ensures that tags are applied correctly and align with organizational standards. Restricting tag management to a specific set of individuals or groups is a key element of maintaining control, consistency, and security within an organization’s cloud environment.

• Why Restrict Tag Management?

  Tagging is a powerful tool for organizing and controlling resources, but if mismanaged, it can lead to inconsistent or unauthorized access control, cost tracking issues, and governance challenges. By implementing strict policies around who can manage tags, organizations can ensure that only authorized personnel can create, modify, or delete critical tags, preserving the integrity of the environment.

  1. Prevent Unauthorized Changes: Tags are often tied to important business processes, such as cost allocation, resource categorization, and access control. Allowing unrestricted access to modify tags could lead to unauthorized or accidental changes, which could disrupt operations or result in misallocated resources.

  2. Ensure Consistent Tagging Standards: Organizations benefit from standardized tagging schemas that help organize resources and enable easy tracking. By limiting tag management to a defined group of administrators, organizations can ensure adherence to these standards, preventing fragmentation and inconsistency in tagging practices.

  3. Maintain Security and Compliance: Tags can be leveraged to enforce security policies and compliance requirements. For example, tags might define environments (for example, Production, Development) or sensitive data classifications. Allowing only authorized users to modify these tags ensures that sensitive environments are protected and access controls are enforced correctly.

  4. Reduce Risk of Policy Misconfiguration: Tag-based policies in OCI (like resource access control) depend on consistent and accurate tag usage. If the wrong group or individual can modify or delete tags, it could inadvertently result in overly broad or restrictive access policies.

• How to Restrict Tag Management in OCI

  In OCI, tag management can be controlled by creating and applying OCI IAM policies that define who can perform tag operations such as creating, updating, or deleting tags. These policies can be tailored to grant access to specific users, groups, or compartments, ensuring that only authorized individuals have the power to change critical tags.

  Here are some ways to restrict tag management to specific individuals or groups:

  1. Use Group-Based Access Control: The first step in controlling tag management is to ensure that only specific groups are granted the necessary permissions to manage tags. For instance, a designated group such as TagAdmins can be given exclusive permissions to handle tag creation and updates.

     Example OCI IAM Policy:

     Allow group TagAdmins to manage tag-namespaces in tenancy
     

     This policy ensures that only the TagAdmins group can create, modify, or delete tags and tag namespaces across the entire tenancy. For allowing some groups like devops engineers or Terraform Runner groups to be able to use these created tags through console for scripts, you can define the following policy.

     Allow group devopsTeam to use tag-namespaces in tenancy
     Allow group terraformRunner to use tag-namespaces in tenancy
     Allow dynamic-group terraformRunner to use tag-namespaces in tenancy
     

  2. Use Compartment-Level Policies for Granular Control: Tag management policies can be applied at the compartment level, so only certain compartments have tag management access. For example, if you want to restrict tag management to a specific project or business unit, you can apply policies that limit tag access within the relevant compartment.

     Example Policy for Compartment-Specific Tag Management:

     Allow group TagAdmins to manage tag-namespaces in compartment ProjectA
     

     This ensures that only users in the TagAdmins group can manage tags within the ProjectA compartment, limiting their access to other compartments. Also, you can create groups to only allow users to use the created tags but not modify them at the compartment level.

     Allow group TagUser to use tag-namespaces in compartment ProjectA
     

  3. Tagging Control with Tag Namespaces: OCI supports tag namespaces, which group related tags together. You can control who can manage tags within a specific namespace, which allows for more granular control over who has access to specific types of tags.

     Example Policy for Namespace-Specific Tag Management:

     Allow group TagAdmins to manage tag-namespaces in tenancy where tag.namespace = 'Billing'
     

     This ensures that only users with TagAdmins permissions can manage tags within the Billing namespace, providing tighter governance around cost-tracking tags.

  4. Audit and Monitor Tag Changes: To ensure that tag management remains secure, organizations should implement auditing and monitoring policies to track any changes made to tags. OCI’s audit logs provide visibility into actions related to tag creation, deletion, and modification. Monitoring these logs helps identify any unauthorized attempts to modify tags or any patterns that suggest mismanagement.

Tag based OCI IAM Policies for Real-Life Use Cases

Now with all that you have learned above, let us work on tuning OCI IAM policies for User principles and Instance principles in real-life use cases. But before we do that, there are some common policies that every customer will require irrespective of their use case.

• Common OCI IAM Policies:

  • OCI IAM Policies for User Management: The IAMAdmin group is responsible for managing OCI IAM related configurations such as OCI IAM domains, users, and groups.

    Allow group IAMAdmin to manage domains in tenancy
    Allow group IAMAdmin to manage users in tenancy
    Allow group IAMAdmin to manage groups in tenancy
    

  • OCI IAM Policies for Tags Management: The InfoSec group is responsible for managing security-related configurations such as OCI IAM policies, users, and tag namespaces.

    Allow group InfoSec to manage tag-namespaces in tenancy
    Allow group InfoSec to manage policies in tenancy
    Allow group InfoSec to use users in tenancy
    Allow group InfoSec to manage groups in tenancy where all {target.group.name != ‘Administrators’, target.group.name != ‘InfoSec’}
    

  • OCI IAM Policies for (Terraform Runner): The terraform-runner group is dedicated to executing Terraform automation scripts for infrastructure provisioning.

    Allow group terraform-runner to use tag-namespaces in tenancy
    Allow group terraform-runner to manage instance-family in compartment Tenants
    Allow group terraform-runner to manage virtual-network-family in compartment Tenants
    Allow group terraform-runner to manage volume-family in compartment Tenants
    Allow group terraform-runner to manage object-family in compartment Storage
    Allow group terraform-runner to manage secret-family in compartment Tenants
    Allow group terraform-runner to manage key-family in compartment Tenants
    

Scale OCI IAM Policies for User Principals

OCI IAM Policy Model: In this policy model, the goal is to write a small number of more manageable policies that are informed by data (tags in our case), also know as Attribute Based Access Control. We will refer to tags assigned to target resource or target resource compartment for access control as permission tags.

Permission Tags: Define permission tag for every Verb (Action) + Resource Type combination in the tenancy. They define a unique permission that you need to assign to a group of users for target resources. The list is not once set and done. Start with a small number of permission tags. Once you get a handle over the policy model, you can add more permission tags. For this tutorial, we will create a permission tag namespace as mgmt. Also, we will create a tag namespace (we will call this infosec) with one tag key named gname.

1. For the following compartment structure with four resource types and to assign manage and use permissions for those resources, we will create permission tags.

   

2. For every permission that you need to assign to a target (compartments in most cases), create a group. We assign permission tags to the resources (using compartment default tags) and resource compartments. The tag value is the group that should have the given permission on the target resource.

   

3. Once permission tags are defined, we can write policies. The end result is, we will need only one policy per permission tag defined in the tenancy. The same policy for the given permission will operate in the entire tenancy.

   

4. As we onboard more workloads, if there are more resource types to be managed then you may have to add more permission tags and policies for those permission tags. Otherwise, you just assign existing permission tags to the new workload with group of users that should have the access. We do not have to write any new policies for the new workload.

This approach will remain consistent across all the examples discussed here, serving as the foundation for defining OCI IAM Groups and Policies.

Example 1: Compartment for Every Application

Step 1: Gain a Comprehensive Understanding of the Customer’s Business Overview

CompanyA is a growing technology company that develops and deploys multiple cloud-native applications for its clients. Each application caters to a specific customer segment, with strict security and compliance requirements. To ensure isolation, scalability, and efficient access control, CompanyA organizes its OCI resources using a structured compartmentalization approach.

Step 2: Design Compartment Structure for the Workload

As described, CompanyA follows the OCI IAM policy model for scaling their OCI IAM policies. They have created separate compartments for their applications to maintain resource isolation.

Note: Only administrators should be able to manage the mgmt and infosec tag namespace.

Step 3: Design the Following Permission Tags of Type Verb+Resource Combination

Create groups in OCI.

1. Log in to the OCI IAM domain with an Admin account having the privilege to create groups.

   

2. Go to Identity and Security and click Domains under Identity.

   

3. Select your compartment and click domain for which you want create the groups.

   

4. Click Groups.

   

5. Define your Groups based upon the permission tags. (Optionally) add your users to those groups.

   

Note: You will have to create groups for a unique combination of permission and target. If the same functional group of users (NetworkAdmin) requires to have access to manage network across all targets, then you need just one group to manage access across all targets.

The following are the permission tags and OCI IAM groups for those tags. Follow the above steps to create groups for each of the defined permission tags.

1. Root Compartment: The root compartment serves as the top-level management layer. Where we will have our admin groups tagged with permission tags. The following tags are:

   • Administrators: manageall permission for managing overall tenancy management.
   • UseAdministrators: useall permission for accessing resources across tenancy.
   • Auditor: readall permission with read-only access to resources for monitoring across tenancy.

2. Per-Application Compartment Model: CompanyA has multiple cloud-based applications. We will create a separate parent compartment for each application. Let us explore how this model applies to Application 1 (App1) and Application 2 (App2) as parent compartments.

   • Application 1 (App1): A customer-facing application hosted on OCI.

     • Network Compartment: Compartment for all the network related resources like VCN’s, subnets, and so on. Now, lets create the permission tags and their respective OCI IAM groups.
       • App1NetworkAdmin: managenetwork resources permission tag for engineers managing network resources for App1.
       • App1NetworkUser: usenetwork resources permission tag for developers needing limited access to network configurations of App1.
       • App1NetworkReader: readnetwork resources permission tag for auditors verifying network setup of App1.
     • Compute Compartment: Compartment for compute instances. Now, lets create the permission tags and their respective OCI IAM groups.
       • App1ComputeAdmin: managecompute resources permission tag for system administrators provisioning and scaling compute instances for the App1 backend.
       • App1ComputeUser: usecompute resources permission tag for developers deploying and testing backend services of App1.
       • App1ComputeReader: readcompute resources permission tag for auditors monitoring compute resource usage for App1.
     • Data Compartment: Compartment for database and storage related resources. Now, lets create the permission tags and their respective OCI IAM groups.
       • App1DataAdmin: managedb resources permission tag for database administrators managing Oracle Autonomous Databases and OCI Object Storage for App1.
       • App1DataUser: usedb resources permission tag for data scientists accessing datasets for analysis with respect to App1.
       • App1DataReader: readdb resources permission tag for auditors reviewing database configurations of App1.

   • Application 2 (App2): An internal enterprise resource planning (ERP) system for CompanyA’s operations.

     Note: Here too we will follow the same compartment structure approach and create Network Compartment , Compute Compartment and Data Compartment under parent App2 compartment. To avoid redundancy, we will just note down the permission tags and OCI IAM groups for App2.

     • Network Compartment:

       • App2NetworkAdmin: managenetwork resources permission tag.
       • App2NetworkUser: usenetwork resources permission tag.
       • App2NetworkReader: readnetwork resources permission tag.

     • Compute Compartment:

       • App2ComputeAdmin: managecompute resources permission tag.
       • App2ComputeUser: usecompute resources permission tag.
       • App2ComputeReader: readcompute resources permission tag.

     • Data Compartment:

       • App2DataAdmin: managedb resources permission tag.
       • App2DataUser: usedb resources permission tag.
       • App2DataReader: readdb resources permission tag.

Note: Apply a permission tag to a target (the target can be a resource or compartment) to dictate which group will have that specific permission on the target for App1 and App2.

Step 4: Write OCI IAM Policies for those Permission Tags

We will create the policies for CompanyA using the same approach that is discussed here: Have less be More - Scaling OCI IAM policies for Groups. For this, create a tag namespace (we will call this infosec) with one tag key named gname.

1. Log in to the OCI IAM domain with an Admin account having the privilege to create policies.

   

2. Go to Identity and Security and click Policies under Identity.

   

3. Select the root Compartment and click Create Policy.

   

4. Enter Name, Description to your policy and add the Policy Statements as well. Click Create.

   • All Resources Policy:

     Allow any-user to manage all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageall)
     Allow any-user to use all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useall)
     Allow any-user to read all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readall)
     

     

     Note: Follow the same procedure to define all the following mentioned policies and add their respective policy statements.

   • Cloudguard Policy:

     Allow any-user to manage cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managecspm)
     Allow any-user to use cloud-guard-family in tenancy where
     sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usecspm)
     Allow any-user to read cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readcspm)
     

   • Network Policy:

     Allow any-user to manage virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managenetwork)
     Allow any-user to use virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useetwork)
     Allow any-user to read virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readnetwork)
     

   • Compute Policy:

     Allow any-user to manage instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managecompute)
     Allow any-user to use instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usecompute)
     Allow any-user to read instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readcompute)
     

   • Database Policy:

     Allow any-user to manage database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managedb)
     Allow any-user to use database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usedb)
     Allow any-user to read database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readdb)
     

Example 2: Compartment for Every Customer/Tenant

Step 1: Gain a Comprehensive Understanding of the Customer’s Business Overview

CompanyB Solutions is a leading Independent Software Vendor (ISV) that provides tenant-based SaaS applications in cloud infrastructure, data management, and analytics. CompanyB serves multiple clients across industries, delivering seamless, secure, and scalable solutions. Their success hinges on using OCI with a well-designed compartmental structure to manage resources efficiently while adhering to security and compliance requirements.

Step 2: Design Compartment Structure for the Workload

CompanyB has isolated the workloads for their customers and have created dedicated sub compartment. Also, they have a network compartment, shared storage and database compartment. Even CompanyB follows OCI IAM policy model for scaling their OCI IAM policies.

Step 3: Design Following Permission Tags of Type Verb+Resource Combination

To create groups, see Example 1 Step 3. You will have to create groups for all your permission tags defined below.

1. Root Compartment - Centralized Governance: The root component acts as the central layer for overseeing all resources and activities across the OCI tenancy. Where we will have our admin groups tagged with permission tags. The following tags are:

   • Administrators: manageall permission for managing overall tenancy management.
   • UseAdministrators: useall permission for accessing resources across tenancy.
   • Auditor: readall permission with read-only access to resources for monitoring across tenancy.

2. Network Compartment - Backbone of Operations: The network compartment supports CompanyB’s cloud networking infrastructure, enabling connectivity across all resources. This includes Virtual Cloud Networks (VCNs), subnets, gateways, and load balancers. Let us define the permission tags and respective OCI IAM groups for it.

   • NetworkAdmin: managenetwork resources permission tag for engineers managing network resources for CompanyB.
   • NetworkUser: usenetwork resources permission tag for developers needing limited access to network configurations of CompanyB.
   • NetworkReader: readnetwork resources permission tag for auditors verifying network setup of CompanyB.

3. Tenants Compartment - Isolated Compartments for Different Customer Workloads: The tenants compartment is structured to isolate resources and workloads for each client (tenant). This ensures CompanyB delivers secure and private services while maintaining operational efficiency.

   • Tenant 1 Compartment: Tenant 1 represents a major enterprise client that uses CompanyB for application development and logging services. The following are the permission tags and respective OCI IAM groups:

     • t1devadmin: manageappdev resource permission for the development team for Tenant 1 has administrative privileges to, configure and deploy custom applications.
     • t1devuser: useappdev resource permission to monitor and adjust application resources. Tenant 1’s developers use these resources for day-to-day development and testing.
     • t1logsadmin and t1devuser: managelogs and uselogs resource permission for logging and monitoring roles ensure that administrators configure logging services while developers access logs to debug and optimize applications.
     • t1devadmin and t1devuser: managecspm and usecspm resource permission for Tenant 1 as they also have a focus on security posture, with the capability to monitor and remediate security risks.

   • Tenant 2 and Tenant 3 Compartments: The structure for Tenant 2 and Tenant 3 mirrors that of Tenant 1, with roles like t2devadmin, t2devuser, t3devadmin, t3devuser, t2logsadmin and t3logsadmin ensuring that each tenant operates in a fully isolated environment. This approach enables CompanyB to maintain consistent governance while catering to specific tenant needs.

   • Shared Compartment - Centralized Resources for All Tenants: The shared compartment includes resources like databases and object storage that multiple tenants utilize but remain logically segregated for privacy and security.

     • Database Compartment:
       • dbadmin: managedb resource permission for CompanyB’s database administrators handle shared databases used by all tenants, including provisioning, scaling, and patching.
       • dbuser: usedb resource permission for Tenant-specific users access their respective database schemas or services.
       • dbreader: readdb resource permission for auditors have read-only access to ensure database configurations comply with security policies.
     • Storage Compartment: OCI Object Storage is managed centrally, with dedicated buckets for each tenant:
       • osadmin: manageobject resource permission for responsible for managing the shared object storage resources.
       • osuser: useobject Tenant-specific storage resource permission (or example, t1osur, t2osur, t3osur) ensure that tenants only access their respective buckets.
       • osreader: readobject resource permission for compliance teams review storage configurations and usage patterns.

Step 4: Write OCI IAM Policies for those Permission Tags

To create policies, see Example 1 Step 4. You will have to create the following policies.

• All Resources Policy:

  Allow any-user to manage all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageall)
  Allow any-user to use all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useall)
  Allow any-user to read all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readall)
  

• Cloudguard Policy:

  Allow any-user to manage cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managecspm)
  Allow any-user to use cloud-guard-family in tenancy where
  sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usecspm)
  Allow any-user to read cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readcspm)
  

• Network Policy:

  Allow any-user to manage virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managenetwork)
  Allow any-user to use virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useetwork)
  Allow any-user to read virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readnetwork)
  

• Logs Policy:

  Allow any-user to manage logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managelogs)
  Allow any-user to use logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.uselogs)
  Allow any-user to read logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readlogs)
  

• Appdev Policy:

  Allow any-user to manage instance-family in tenancy where
  sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageappdev)
  Allow any-user to use instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useappdev)
  Allow any-user to read instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readappdev)
  
  

• Db Policy:

  Allow any-user to manage database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managedb)
  Allow any-user to use database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usedb)
  Allow any-user to read database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readdb)
  

• Storage Policy:

  Allow any-user to manage object-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageobject)
  Allow any-user to use object-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useobject)
  Allow any-user to read object-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readobject)
  

Example 3: Large Enterprise Compartment Structure

Step 1: Gain a Comprehensive Understanding of the Customer’s Business Overview

CompanyC Solutions, a multinational organization specializing in innovative software solutions, decided to migrate its mission-critical workloads to OCI. The company operates in highly regulated industries like finance and healthcare, where security, compliance, and scalability are of utmost importance.

Step 2: Design Compartment Structure for the Workload

Let us now explore the compartment structure for CompanyC, which follows OCI IAM policy model for scaling their OCI IAM policies.

Step 3: Design the Following Permission Tags of Type Verb+Resource Combination

To create groups, see Example 1 Step 3. You have to create groups for all the following permission tags.

1. Root Compartment - Centralized Governance: The root component acts as the central layer for overseeing all resources and activities across the OCI tenancy. Where we will have our admin groups tagged with permission tags. The following tags are:

   • Administrators: manageall permission for managing overall tenancy management.
   • UseAdministrators: useall permission for accessing resources across tenancy.
   • Auditor: readall permission with read-only access to resources for monitoring across tenancy.

2. PROD Compartment: The compartment for hosting mission-critical production workloads that directly impact business operations and end-users. Each application has its dedicated sub-compartment for resource isolation and optimized management. Let us define the permission tags and respective OCI IAM groups for it.

   • NetworkAdmin: managenetwork resources permission tag for engineers managing Network resources for CompanyC.
   • NetworkReader: readnetwork resources permission tag for auditors verifying network setup of CompanyC.
   • ComputeAdmin: managecompute resources permission tag for system administrators provisioning and scaling compute instances for CompanyC.
   • ComputeReader: readcompute resources permission tag for auditors monitoring compute resource usage for CompanyC.
   • StorageReader: manageobject resource permission for storage admin teams to manage storage configurations.
   • StorageReader: readobject resource permission for compliance teams review storage configurations and usage patterns.
   • SecurityAdmin: managecspm resource permission for Compartment PROD as they also have a focus on security posture, with the capability to monitor and remediate security risks.

   Now we will go ahead and define the permission tags and respective OCI IAM groups for application specific sub compartments. In the interest of time, we have merged and defined permissions for all the 3 different application compartments.

   • Application Compartments:
     • PRApp1NetAdmin, PRApp2NetAdmin and PRApp3NetAdmin: Admin OCI IAM groups with managenetwork resources permission tag for engineers managing Network resources for App1, App2 and App3 respectively.
     • PRApp1NetUser, PRApp2NetUser and PRApp3NetUser: Admin OCI IAM groups with usenetwork resources permission tag for engineers managing network resources for App1, App2 and App3 respectively.
     • PRApp1ComputeAdmin, PRApp2ComputeAdmin and PRApp3ComputeAdmin: Admin OCI IAM groups with managecompute resources permission tag for engineers managing OCI Compute instances for App1, App2 and App3 respectively.
     • PRApp1ComputeUser, PRApp2ComputeUser and PRApp3ComputeUser: Admin OCI IAM groups with usecompute resources permission tag for engineers using OCI Compute instances for App1, App2 and App3 respectively.
     • PRApp1StorageAdmin, PRApp2StorageAdmin and PRApp3StorageAdmin: Admin OCI IAM groups with manageobject resources permission tag for engineers managing OCI Object Storage for App1, App2 and App3 respectively.
     • PRApp1StorageUser, PRApp2StorageUser and PRApp3StorageUser: Admin OCI IAM groups with useobject resources permission tag for engineers using OCI Object Storage for App1, App2 and App3 respectively.

3. NPROD Compartment: Dedicated for staging, development, and quality assurance environments. This compartment is structured similarly to PROD to ensure consistency. Let us define the permission tags and respective OCI IAM groups for it.

   • NetworkAdmin: managenetwork resources permission tag for engineers managing network resources for CompanyC.
   • NetworkReader: readnetwork resources permission tag for auditors verifying network setup of CompanyC.
   • ComputeAdmin: managecompute resources permission tag for system administrators provisioning and scaling OCI Compute instances for CompanyC.
   • ComputeReader: readcompute resources permission tag for auditors monitoring OCI Compute resource usage for CompanyC.
   • StorageReader: manageobject resource permission for storage admin teams to manage storage configurations.
   • StorageReader: readStorage resource permission for compliance teams review storage configurations and usage patterns.
   • SecurityAdmin: managecspm resource permission for Compartment NPROD as they also have a focus on security posture, with the capability to monitor and remediate security risks.

   Similarly, now we will go ahead and define the permission tags and respective OCI IAM groups for application specific sub compartments.

   • Application Compartments:
     • NPApp1NetAdmin, NPApp2NetAdmin and NPApp3NetAdmin: Admin OCI IAM groups with managenetwork resources permission tag for engineers managing network resources for App1, App2 and App3 respectively.
     • NPApp1NetUser, NPApp2NetUser and NPApp3NetUser: Admin OCI IAM groups with usenetwork resources permission tag for engineers managing network resources for App1, App2 and App3 respectively.
     • NPApp1ComputeAdmin, NPApp2ComputeAdmin and NPApp3ComputeAdmin: Admin OCI IAM groups with managecompute resources permission tag for engineers managing OCI Compute instances for App1, App2 and App3 respectively.
     • NPApp1ComputeUser, NPApp2ComputeUser and NPApp3ComputeUser: Admin OCI IAM groups with usecompute resources permission tag for engineers using OCI Compute instances for App1, App2 and App3 respectively.
     • NPApp1StorageAdmin, NPApp2StorageAdmin and NPApp3StorageAdmin: Admin OCI IAM groups with manageobject resources permission tag for engineers managing OCI Object Storage for App1, App2 and App3 respectively.
     • NPApp1StorageUser, NPApp2StorageUser and NPApp3StorageUser: Admin OCI IAM groups with useobject resources permission tag for engineers using OCI Object Storage for App1, App2 and App3 respectively.

4. Shared Compartment: The shared compartment hosts resources for monitoring like logging and cloud guard OCI services. It also has keys for encryption and decryption which are utilized by multiple tenants while ensuring logical segregation to maintain privacy and security. All the Admins from your Applications needing the access to these services will be added to the created OCI IAM groups for these services. Let us define the permission tags and respective OCI IAM Groups for it.

   • Oracle Cloud Guard Compartments:

     • cspmAdmin: Admin OCI IAM groups with managecspm resources permission tag for admins managing Oracle Cloud Guard for PROD and Non PROD compartments.
     • cspmUser: OCI IAM groups with usecspm resources permission tag for engineers using/monitoring Oracle Cloud Guard for PROD and Non PROD compartments.
     • cspmReader: OCI IAM groups with readcspm resources permission tag for engineers reading Oracle Cloud Guard for PROD and Non PROD compartments.

   • OCI Logging Compartments:

     • logsAdmin: Admin OCI IAM groups with managelogs resources permission tag for admins managing OCI Logging for PROD and Non PROD compartments.
     • logsUser: OCI IAM groups with uselogs resources permission tag for engineers using/monitoring OCI Logging for PROD and Non PROD compartments.
     • logsReader: OCI IAM groups with readlogs resources permission tag for engineers reading OCI Logging for PROD and Non PROD compartments.

   • Keys Compartments:

     • kmsAdmin: Admin OCI IAM groups with managekeys resources permission tag for admins managing key vault for PROD and Non PROD compartments.
     • kmsUser: OCI IAM groups with usekeys resources permission tag for engineers using/monitoring key vault for PROD and Non PROD compartments.
     • kmsReader: OCI IAM groups with readkeys resources permission tag for engineers reading key vault for PROD and Non PROD compartments.

5. Playground Compartment: A flexible and isolated environment for experimentation, development, and testing. This compartment is not tied to production or compliance constraints, making it ideal for innovation. Here we will have only one OCI IAM admin group for very child compartment and will give the manage privileges to all OCI resources that are needed for testing requirements.

   • Dev Compartments:

     • DevAdmin: Admin OCI IAM groups with managenetwork, managecompute, manageobject, managekeys, managelogs resources permission for Dev admins for testing out new implementation within Dev Compartment.

   • Test Compartments:

     • TestAdmin: Admin OCI IAM groups with managenetwork, managecompute, manageobject, managekeys, managelogs resources permission for Dev admins for testing out new implementation within Test Compartment.

   • Performance Testing Compartments:

     • PerfTestAdmin: Admin OCI IAM groups with managenetwork, managecompute, manageobject, managekeys, managelogs resources permission for Dev admins for testing out new implementation within Performance Testing Compartment.

Step 4: Write OCI IAM Policies for those Permission Tags

To create policies, see Example 1 Step 4. You have to create the following policies.

• All Resources Policy:

  Allow any-user to manage all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageall)
  Allow any-user to use all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useall)
  Allow any-user to read all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readall)
  

• Logs Policy:

  Allow any-user to manage logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managelogs)
  Allow any-user to use logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.uselogs)
  Allow any-user to read logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readlogs)
  

• Cloudguard Policy:

  Allow any-user to manage cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managecspm)
  Allow any-user to use cloud-guard-family in tenancy where
  sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usecspm)
  Allow any-user to read cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readcspm)
  

• Key Policy

  Allow any-user to manage keys in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managekeys)
  Allow any-user to use keys in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usekeys)
  Allow any-user to read keys in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readkeys)
  
  

• Application Policy:

  Allow any-user to manage virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managenetwork)
  Allow any-user to use virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useetwork)
  Allow any-user to manage instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managecompute)
  Allow any-user to use instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usecompute)
  Allow any-user to manage object-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageobject)
  Allow any-user to use object-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useobject)
  
  

• Playground Policy:

  Allow any-user to manage virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managenetwork)
  Allow any-user to manage virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managenetwork)
  Allow any-user to manage object-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageobject)
  Allow any-user to manage logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managelogs)
  Allow any-user to manage vaults in compartment Playground where request.principal.group.tag.infosec.gname=target.compartment.tag.mgmt.manageVaults
  Allow any-user to manage keys in compartment Playground where request.principal.group.tag.infosec.gname=target.compartment.tag.mgmt.manageKeys
  
  

Note: For such scenario’s every time you onboard new workload:

• Check if you need any additional permission tags. If you do then create them along with OCI IAM policies for those permission tags.
• Create groups to manage access to the new workload compartment.
• Tag workload compartment using permission tags and the groups created.

Tag based Permission Model for Granular Access Control

So far, all the examples, we have discussed create manage, user, or read permissions for a family of resources. However, most customers require granular access control to follow the least privilege model. The tutorial’s focus is on understanding the policy model, which is why we talked about a simple use case. However, let me take an example of four network persons and how you can design granular permission tags and OCI IAM policies for those four personas.

• NetworkOwner: This person or team owns the network implementation for the OCI tenancy. They have access to set up FastConnect and permission to manage the network for all the applications.

• NetworkAdmin: This team owns the network implementation for the application teams. They can create VCNs for application teams. However, they do not have access to set up a network firewall or FastConnect.

• NetworkOperator: This team owns the application’s network. The team can create an application subnet in the application’s VCN or a shared VCN. However, they do not have permission to manage or update VCNs.

• NetworkUser: This is the application admin team that requires use permission on the application network resources.

We will define networkowner, networkadmin, networkoperator, and networkuser as four tags on the network compartment. For those tags, we will assign group names that have access to the network compartment.

• NetworkOwner Policy:

  Allow any-user to manage virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkowner)
  

• NetworkAdmin Policy:

  Allow any-user to manage vcns in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin)
  Allow any-user to manage subnets in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin)
  Allow any-user to manage route-tables in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin)
  Allow any-user to manage security-lists in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin)
  Allow any-user to manage network-security-groups in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin)
  Allow any-user to manage dhcp-options in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin)
  Allow any-user to manage local-peering-gateways in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin)
  Allow any-user to manage service-gateways in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin)
  Allow any-user to manage internet-gateways in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin)
  

• NetworkOperator Policy:

  Allow any-user to {VCN_ATTACH,VCN_DETACH} in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator)
  Allow any-user to inspect vcns in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator)
  Allow any-user to manage subnets in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator)
  Allow any-user to manage route-tables in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator)
  Allow any-user to manage security-lists in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator)
  Allow any-user to manage network-security-groups in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator)
  Allow any-user to manage dhcp-options in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator)
  

• NetworkUser Policy:

  Allow any-user to inspect vcns in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkuser)
  Allow any-user to use subnets in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkuser)
  Allow any-user to use vnics in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkuser)
  Allow any-user to use security-lists in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkuser)
  Allow any-user to use network-security-groups in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkuser)
  

Scale OCI IAM policies for Instance Principals

Example 1: Multi-Tenant Instance Access Control for Shared Storage and Secrets in OCI

Step 1: Gain a Comprehensive Understanding of the Customer’s Business Overview

XYZ Cloud Solutions is a SaaS provider offering a Document Management System (DMS) hosted on OCI. The platform serves multiple enterprise customers, each requiring strict isolation of their data while leveraging a shared infrastructure.

Customer Requirements:

• Each enterprise (tenant) should have isolated instances to process and manage documents.
• Each tenant’s secrets (API keys, database credentials) should only be accessible to that tenant’s instances.
• All tenants store their documents in a centralized OCI Object Storage compartment, but they should only access their own bucket.
• The system should support auto-scaling and easy onboarding of new tenants.

Step 2: Design Compartment Structure for the Workload

Let us now explore the compartment structure for XYZ Cloud Solutions, which follows OCI IAM policy model for scaling their OCI IAM policies.

• Tenant Isolation with Compartments:

  • Create a dedicated OCI compartment for each enterprise customer (Tenant1, Tenant2, and so on).
  • Deploy compute instances (VMs, Functions, or Containers) inside their respective compartments.
  • Centralized storage with access control.

• Maintain a Shared Storage Compartment for OCI Object Storage Buckets:

  • Each tenant gets a dedicated bucket, tagged with Enterprise.Tenant=<TenantName>.
  • OCI IAM policies ensure that each tenant’s instances can only read from their own bucket.
  • Secrets management with OCI Vault.

• Store Database Credentials, API Keys, and Encryption Keys in OCI Vault:

  • Each tenant’s secrets are tagged with Enterprise.Tenant=<TenantName>.
  • OCI IAM policies allow only that tenant’s instances to retrieve their secrets.
  • Enterprise tagging strategy for governance.

• Define an Enterprise Tag Namespace with Enterprise.Tenant to track Tenant Ownership:

  • Apply compartment default tags to automatically tag resources within each tenant’s compartment.
  • Use policies based on tags for automated access control.

Step 3: Create OCI IAM Groups

To ensure secure and isolated access management in an OCI multi-tenant environment, the following policies will be defined for:

• InfoSec Group: Security administrators with access to manage policies, tags, users, and groups.

• Terraform-Runner Group: Infrastructure-as-Code (IaC) execution group for managing OCI resources.

Note: These groups and OCI IAM policies are already created as described above in Common OCI IAM Policies section.

Step 4: Create OCI IAM Policies for the Defined Groups

Tenant Resource Access Policies: To maintain data isolation, tenant resources should only be able to access their own secrets and object storage.

Allow any-user to use object-family in compartment Storage where request.principal.compartment.tag.Enterprise.Tenant = target.resource.tag.Enterprise.Tenant
Allow any-user to use secret-family in compartment Tenants where request.principal.compartment.tag.Enterprise.Tenant = target.resource.tag.Enterprise.Tenant

If the tenant instance principles require permission to create new objects as well, then you can create bucket names with the same name as tenant name and use tenant name tag to compare with the bucket name.

Allow any-user to manage objects in compartment Storage where request.principal.compartment.tag.Enterprise.Tenant = target.bucket.name

Example 2: Fine-Grained Access Control for Multi-Service Data Access in a Shared OCI Storage Model

Step 1: Gain a Comprehensive Understanding of the Customer’s Business Overview

XYZ Corp is a rapidly growing enterprise specializing in digital transformation solutions. With a global presence, XYZ Corp operates in multiple regions and leverages OCI for hosting critical applications, managing data, and ensuring seamless collaboration among teams.

Customer Requirements:

• All instances of the Admin Service for a specific tenant can read Admin Buckets within the shared storage compartment.
• All instances of the Sales Service for a specific tenant can read Sales Buckets within the shared storage compartment.
• All instances of the Supply Service for a specific tenant can read Supply Buckets within the shared storage compartment.
• All instances for a specific tenant can read Shared Services Buckets within the shared storage compartment.
• All instances for a specific tenant can read Secrets for that tenant within the tenant compartment.

Step 2: Design Compartment Structure for the Workload

Let us now explore the compartment structure for XYZ Corp, which follows OCI IAM policy model for scaling their OCI IAM policies.

• Tenant-Specific Compartment Creation:

  • Create a dedicated compartment for each tenant.
  • All resources belonging to a tenant should be provisioned inside that tenant’s compartment.

• Enterprise Tagging Namespace:

  • Define an Enterprise Tag Namespace with the following tag keys:
    • Enterprise.Tenant Captures the tenant name.
    • Enterprise.Service Captures the service type. For example, Admin, Sales, Supply, or Shared.

• Default Tags for Tenant Compartments:

  • Configure Compartment Default Tags for each tenant compartment, ensuring that the Enterprise.Tenant tag is automatically applied to all resources within the compartment, capturing the tenant name.

• Resource-Level Tagging:

  • Every resource within a tenant compartment should be tagged with Enterprise.Service specifies the service type. For example, Admin, Sales, Supply, and so on.

• Target Resource Tagging (Buckets and Secrets):

  • Tag every target resource (such as buckets and secrets) with:
    • Enterprise.Tenant Captures the tenant name.
    • Enterprise.Service Captures the associated service type.

• Tagging Shared Buckets:

  • For shared bucket resources, set Enterprise.Service = 'Shared' to indicate cross-service accessibility.

Step 3: Create OCI IAM Groups

To ensure secure and isolated access management in an OCI multi-tenant environment, the following policies will be defined for:

• InfoSec Group: Security administrators with access to manage policies, tags, users, and groups.

• Terraform-Runner Group: Infrastructure-as-Code (IaC) execution group for managing OCI resources.

• Dynamic group AdminInstances: With matching rule All {tag.Enterprise.Service.value=’Admin’}.

• Dynamic group SalesInstances: With matching rule All {tag.Enterprise.Service.value=’Sales’}.

• Dynamic group SupplyInstances: With matching rule All {tag.Enterprise.Service.value=’Supply’}.

Note: InfoSec and Terraform-Runner groups and IAM policies are already created as described above in Common OCI IAM Policies section.

Step 4: Create OCI IAM Policies for the Defined Groups

Tenant Resource Access Policies: To maintain data isolation, tenant resources should only be able to access their own secrets and object storage.

Allow dynamic-group AdminInstances to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Admin’}

Allow dynamic-group SalesInstances to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Sales’}

Allow dynamic-group SupplyInstances to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Supply’}

Allow any-user to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Shared’}

Allow dynamic-group AdminInstances to use secret-family in compartment Tenants where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Admin’}

Allow dynamic-group SalesInstances to use secret-family in compartment Tenants where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Sales’}

Allow dynamic-group SupplyInstances to use secret-family in compartment Tenants where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Supply’}

Related Links

• Getting Started with Policies

• Securing Tagging

• About Tag-Based Access Control

• Have less be More - Scaling OCI IAM policies for Groups

• Have less be More - Scaling OCI IAM policies

Acknowledgments

• Author - Chetan Soni (Senior Cloud Engineer)

• Contributor - Kiran Thakkar (Master Principal Cloud Architect)

More Learning Resources

Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.

For product documentation, visit Oracle Help Center.

---

Title and Copyright Information

<

Deep Dive into Tag based Oracle Cloud Infrastructure Identity and Access Management Policies

G30314-01

Copyright ©2025, Oracle and/or its affiliates.