How to Customize Oracle Database@AWS RBAC Integration

🎯 Overview

Oracle Database@AWS (ODBAWS) is revolutionizing how enterprises manage their Oracle workloads across AWS deployments. But with great power comes great responsibility—especially when it comes to access control.

If you’re onboarding ODBAWS and need to grant users access permissions outside the default RBAC setup as described in the ODBAWS documentation, for example at an AWS Account level, this guide walks you through customizing the corresponding OCI groups and policies to make it happen.

This post is your runbook for success—whether you’re tackling this during onboarding or adjusting post-deployment.

🔧 Prerequisites

Before you begin, make sure the following are in place:

• ✅ ODBAWS onboarding steps 1–7 completed
• ✅ OCI operator with Tenancy Admin or Identity Domain Admin privileges

👥 Custom ODBAWS Groups: Why and How

By default, when you establish the multicloud link, OCI automation creates a set of groups and policies using predefined names. These default OCI policies provide access to the respective groups at an ODBAWS private offer / OCI tenancy level – meaning the permissions apply to all ODBAWS resources provisioned in the OCI tenancy, regardless of the AWS Account in which they’re deployed.

But what if you want something a little more tailored? For example, you deploy ODBAWS resources in multiple AWS accounts (using subscription sharing). AWS permissions are defined at an account level and you require the OCI permissions at the same granularity, i.e. the OCI compartment that maps to the AWS account. This process is briefly described in the documentation, but if you are looking for more details to guide you to make the customization. This post is your answer. 

🎯 The Goal: Assign OCI privileges at a more granular scope—AWS Account / OCI Compartment

✅ How to Do It: 

1. Identify a custom prefix (e.g., acmeco-finance) for your OCI group names. See the documentation for the default OCI groups as a guide.
2. Create AWS and OCI groups using this naming convention – refer to table 1 below.
3. Optionally, if you will use identity federation, complete the Federation task in the onboarding documentation, manage the AWS and OCI users and groups from  the chosen IDP (EntraID, Okta, etc), and add the groups to the AWS and OCI identity synchronization.
4. Customize the OCI policies to assign permissions to the new groups (refer to the section below for more detail).

🧠 Pro Tips: 

• Create separate AWS and OCI groups for each AWS account.
• Manually create or synchronize the groups from an IDP before updating the OCI policies. If the OCI groups do not exist then any policy referencing them will need to be updated before it takes effect.
• The steps in this blog use a naming convention combining the default group names appended to a custom prefix. Although you may use your own naming convention instead, keeping the default group name, as part of the name, helps identify the changes made from the default configuration – which can help if trying to fix issues in the future, including when working with Oracle Support.

Table 1

🔐 OCI Policy Customization: Step-by-Step

When you provision ODBAWS resources in a new AWS account, a new OCI child compartment is created under the multicloud link compartment.  

By default, the default ODBAWS OCI policies, and the permissions they grant, will apply to all compartments under the multicloud link compartment – in other words the same permissions apply to all ODBAWS resources from every account.

To customize the OCI Policies, and grant access only to the new compartment/account using the custom groups created above, navigate to the OCI Console under Identity & Security → Policies and search for policies, in the root compartment, with a MulticloudLink_AWS prefix. These policies reference the default aws groups. Refer to the screenshot below for an example.

✍️ Create Custom Policies:

1. For the MulticloudLink_AWS policy ending in “User_Group_Policies”.  create a new policy with the same prefix used for the group names above. E.g. acmeco-finance-MulticloudLink_AWS_YYYYMMDDHHMMSS_User_Group_Policies.
2. Copy the original policy statements (use advanced editor) and paste them in the new policy
3. Edit each policy statement to:
   • Match the corresponding custom group name(s) 
   • Reference the appropriate compartment, linked to the AWS account, instead of the MultiCloudLink compartment.
   • Example syntax:

allow group acmeco-finance-aws-exa-cdb-administrators to manage <resource> in compartment <multicloudlink compartment name>:<account sub-compartment name>

⏳ Note: Do not modify the existing policies as this may impact normal service operations. Use the existing policies as a template for the new customer policies. 

🔐 Using Identity Domains other than Default

OCI Identity Domains are where you manage users, groups, federation and other access controls in OCI. Your OCI tenancy comes with an identity domain named Default and this is where the default ODBAWS groups are created by the multicloud link automation. You may also choose to create additional identity domains to maintain separate identity populations. For example, an OCI security best practice is to use the Default domain for break glass accounts and a separate identity domain(s) for other identity use cases, which may include OraDB@AWS users, groups and federation.

If you do introduce a new identity domain, ensure that any custom IAM policies, applicable to groups in that domain, explicitly include the domain name in each policy statement. For example, when using an Identity Domain named AWS:

allow group 'AWS'/'acmeco-finance-aws-exa-cdb-administrators' to manage <resource> in compartment <multicloudlink compartment name>:<account sub-compartment name>

Also, if using an IDP to manage OCI users and groups, make sure Federation and Synchronization is configured in the new Identity Domain.

🧩 Bringing It All Together

By customizing your groups and OCI policies:

• Empower your org with fine-grained access control
• Enable multi-account access control flexibility for Oracle Database@AWS
• Keep user access clean, scoped, and secure

🧠 Helpful Resources

Oracle Database@AWS Onboarding Guide
Oracle Database@AWS RBAC
Oracle Database@AWS OCI Groups
Oracle Database@AWS AWS IAM Permissions
Overview of Working with OCI Policies
OCI Identity Domains
Oracle Database@AWS Subscription Sharing