Set up an RPC connection between two Tenants and two DRG
Introduction
In a multi-tenant Oracle Cloud Infrastructure (OCI) environment, enabling secure and efficient communication between different tenants is crucial for hybrid and distributed network architectures. One way to achieve this is by setting up a Remote Peering Connection (RPC) between two Tenants and their corresponding Dynamic Routing Gateways (DRGs).
Objectives
This tutorial will guide you through the step-by-step process of configuring an RPC between two DRGs in separate OCI tenants, ensuring seamless connectivity across networks. By the end, you will have a working RPC setup that allows secure traffic flow between the tenants, helping you build robust multi-tenant architectures in OCI.
Prerequisites
Before setting up the Remote Peering Connection (RPC) between two Tenants and their Dynamic Routing Gateways (DRGs), ensure you have the following:
- Access to Two OCI Tenants – You need administrator or appropriate permissions in both OCI tenants to configure networking components.
- DRGs in Both Tenants – Each tenant must have a Dynamic Routing Gateway (DRG) already created and attached to a Virtual Cloud Network (VCN).
- Region Compatibility – The DRGs must be in the same or different OCI commercial regions that support RPC. Cross-region RPC is supported, but both regions must be accessible. The requestor needs to be subscribed to the acceptor region.
- Public or Private Connectivity – Decide whether you will allow communication over private IPs and ensure proper subnet CIDR blocks are planned to avoid conflicts.
- VCNs and Routing Configuration – The Virtual Cloud Networks (VCNs) in both tenants should have properly configured route tables and security lists to allow traffic over the RPC.
The above prerequisites will be out of scope in this tutorial. The prerequisite below will be within the scope of this tutorial.
- Policies for Cross-Tenant Peering – Ensure that IAM policies are in place to allow DRG peering across different OCI tenants. You may need to define policies for both tenants to establish trust.
Once these prerequisites are met, you can proceed with configuring the RPC between the two tenants.
The Steps Summary
- [ ] STEP 01: Determine which tenant is going to be the Requestor and the Acceptor
- [ ] STEP 02: Subscribe the Acceptor region to the Requestor region
- [ ] STEP 03: Gather the required parameters to create the IAM Policy for the Requestor and the Acceptor side
- [ ] STEP 04: Create and configure the IAM Policy on the Requestor and the Acceptor side
- [ ] STEP 05: Configure the DRG Attachments on the DRG on the Requestor and the Acceptor side
- [ ] STEP 06: Establish the connection from the Requestor side
- [ ] STEP 07: Design RPC Architectures with three or more tenants
STEP 01 - Determine which tenant is going to be the Requestor and the Acceptor
In Oracle Cloud Infrastructure (OCI), when setting up cross-cloud communications or resource sharing, it is critical to define which tenant is the Requestor and which is the Acceptor in terms of Identity and Access Management (IAM) policies. These roles are governed by IAM policies, which define permissions for users, groups, and compartments.
By defining the Requestor and Acceptor roles clearly within IAM policies, you ensure that permissions are correctly set up to allow secure, controlled access to resources across OCI tenants and compartments. Both tenants need to work together to ensure that the appropriate permissions are granted and that IAM policies are set in a way that adheres to security best practices.
Requestor Tenant: The Requestor is the OCI tenant (or specific compartment within a tenant) that initiates a request for access to resources from another OCI tenant or compartment. The Requestor’s IAM policies must grant the necessary permissions to access the Acceptor's resources. For example, the Requestor might need to create a policy that allows their users to access a resource in the Acceptor tenant.
The Requestor must also ensure that the right IAM roles are assigned to the users or groups making the request.
Acceptor Tenant: The Acceptor is the OCI tenant (or compartment) that receives the access request and grants the necessary permissions to the Requestor. The Acceptor’s IAM policies must define which actions the Requestor can perform and which resources they can access. The Acceptor’s policies should also specify the users or groups who are allowed to accept such requests, ensuring that access is securely managed.
In addition to granting access, the Acceptor should configure IAM policies to specify what the Requestor is authorized to do, ensuring proper scope and least privilege principles are followed.
The diagram below shows you an example of two tenants that are connected with each other with RPC where one of them is defined as the Requestor (REQ) and the other is the Acceptor (ACC).
STEP 02 - Subscribe the Acceptor region to the Requestor region
In the context of setting up Remote Peering Connections (RPC) between two OCI tenants, the Requester needs to be subscribed to the Acceptor tenants region, while the Acceptor does not need to be subscribed to the Requester region. Here’s why:
Why the Requester Needs to Be Subscribed to the Acceptor Tenant:
- Initiating Communication: The Requester tenant is the entity that initiates the RPC by sending requests to the Acceptor tenant. To allow for this communication, the Requester needs to be subscribed to the Acceptor, which enables it to recognize and connect to the Acceptor's network and services.
- Establishing Trust and Connectivity: By subscribing to the Acceptor tenant, the Requester tenant establishes the necessary trust and connectivity to interact with the Acceptor's environment. The subscription ensures that the Requester can route traffic and requests properly to the Acceptor's services over the peering connection.
Why the Acceptor Does Not Need to Be Subscribed to the Requester Tenant
- Passive Role of the Acceptor: The Acceptor tenant only receives requests from the Requester tenant; it does not initiate any communication. Because the Acceptor is only responding to the requests made by the Requester, it does not need to subscribe to the Requester. It simply needs to be accessible and configured to handle incoming requests.
- One-Way Communication: RPCs are typically set up with a one-way communication flow where the Requester is the initiator. The Acceptor doesn't require a subscription to the Requester tenant, as it does not need to initiate or manage outgoing connections.
In summary, the Requester must subscribe to the Acceptor to initiate RPCs and establish connectivity, while the Acceptor only needs to be configured to respond to requests and does not require a subscription to the Requester tenant.
In the picture below you will see an example of the Requesters OCI console. Notice that the Requester is subscribed to the Acceptors region.
In the picture below you will see an example of the Acceptors OCI console. Notice that the Acceptors are NOT subscribed to the Requestors region.
STEP 03 - Gather the required parameters to create the IAM Policy for the Requestor and the Acceptor side
Here’s the table showing the fields required in the IAM policy for both the Acceptor and Requestor tenants when setting up Remote Procedure Call (RPC) access in Oracle OCI:
| Information Required | Requestor Tenant | Acceptor Tenant |
|---|---|---|
| Tenancy OCID | X | X |
| Group Name | X | |
| Group OCID | X | |
| Compartment Name | X | X |
Make sure that this information is gathered from both sides before creating the IAM Policy.
STEP 04 - Create and configure the IAM Policy on the Requestor and the Acceptor side
The official IAM Policy documentation to make the RPC work can be found [here]. When you look at the policies you will see that in the IAM policy for the Requestor, some information is required from the Acceptor, and for the Acceptor IAM Policy some information is required from the Requestor. This makes it sometimes confusing to create the policies, and if the policies are not correct the RPC Peering connection will not come up, and troubleshooting will be hard.
To overcome this problem I have created the [RPC IAM Policy Tool]. There are more RPC network architectures available but the [RPC IAM Policy Tool] can only be used if you are trying to create an RPC between two different OCI tenants where each tenant has their own DRG.
In the picture below you will see the form that the [RPC IAM Policy Tool] will provide you to insert all the required details. The form will ask for more information that is actually required, but it is good practice to have ALL the information in one place before you start configuring the RPC and the IAM Policies on the Acceptor and Requestor side.
The Requestor information and parameters are marked with the RED color and the Acceptor information and parameters are marked with the BLUE color.
The picture below shows an example of all the information filled in. When all the (required) fields are filled in you can click on the Submit button.
When the Submit button is clicked the Tool will generate the following information:
- A Diagram with the parameters you used to put things into perspective.
- A table with all the parameters you used (so you can screenshot this, or copy-paste this into your notes for reference later).
- The IAM policy for the Requestor.
- The IAM policy for the Acceptor.
Requestor Side
- Navigate on the OCI console to Identity & Security > Policies
- Make sure you select the "root" compartment!
- Click on Create Policy
- Provide a name and a description for the policy.
- Enable the manual policy editor.
- Copy/Paste the policy statements for the Requestor side (red) into the policy.
- Click on the Create button.
When you create the policy you will see the Policy statements configured.
When you go back to the policy overview you will see the policy configured.
Acceptor Side
- Navigate on the OCI console to Identity & Security > Policies
- Make sure you select the "root" compartment!
- Click on Create Policy
- Provide a name and a description for the policy.
- Enable the manual policy editor.
- Copy/Paste the policy statements for the Requestor side into the policy.
- Click on the Create button.
When you create the policy you will see the Policy statements configured.
When you go back to the policy overview you will see the policy configured.
STEP 05 - Configure the DRG Attachments on the DRG on the Requestor and the Acceptor side
We need to create a Remote peering connection on the Requestor and Acceptor side.
Requestor Side
- Navigate on the OCI console to Networking > Dynamic Routing Gateways.
- Click on Remote peering connection attachments (in the side menu on the left).
- Click on the Create remote peering connection button.
- Specify a name.
- Click on the Create remote peering connection button.
Acceptor Side
- Navigate on the OCI console to Networking > Dynamic Routing Gateways.
- Click on Remote peering connection attachments (in the side menu on the left).
- Click on the Create remote peering connection button.
- Specify a name.
- Click on the Create remote peering connection button.
STEP 06 - Establish the connection from the Requestor side
We first need to collect the RPC OCID from the Acceptor side as we need to use this OCID to establish the RPC connection from the Requestor side.
Acceptor Side
- Navigate on the OCI console to Networking > Dynamic Routing Gateways > Remote peering connection attachments.
- Click on the remote peering connection (for the Acceptor) you created in the previous step.
- Collect (Copy) the RPC OCID from the Acceptor side.
Requestor Side
- Navigate on the OCI console to Networking > Dynamic Routing Gateways > Remote peering connection attachments.
- Click on the remote peering connection (configured for the Acceptor side) you created in the previous step.
- Click on the Establish connection button.
- Select the Region of the Acceptor.
- Paste in the RPC OCID we collected in the step before.
- Click on the Establish connection button.
- If the Requestor is subscribed to the Acceptor region and,
- If the right IAM policies are configured, and
- If the right RPC OCI
The Peering status should change to Peered (on the Requestor side).
- You can click on the Remote peering connection to look at additional information on the peering.
- Notice the Peer Status is Peered.
- Notice the Peer Region is Jeddah.
- Notice that this is a Cross Tenancy Peering.
Acceptor Side
We can also verify the peering status on the Acceptor side.
- Navigate on the OCI console to Networking > Dynamic Routing Gateways > Remote peering connection attachments.
- Click on the remote peering connection (configured for the Requestor side).
- Notice the Peering status is also set to Peered (on the Acceptor side),
- You can click on the Remote peering connection to look at additional information on the peering.
- Notice the Peer Status is Peered.
- Notice the Peer Region is Riyadh.
- Notice that this is a Cross Tenancy Peering.
STEP 07 - Design RPC Architectures with three or more tenants
It is also possible to create RPC connections between more than two sites or tenants.
In the diagram below I used three different tenants:
- OCI Riyadh (Requestor)
- OCI Jeddah (Acceptor)
- OCI Dubai (Acceptor)
In this example, Riyadh will be some kind of "HUB" site that will act as the Requestor for two Acceptors.
In the diagram below I used three different tenants:
- OCI Riyadh (Requestor)
- OCI Jeddah (Requestor + Acceptor)
- OCI Dubai (Acceptor)
In this example Riyadh will be the Requestor for Jeddah and Jeddah will be the Requestor for Dubai.
In the diagram below I used three different tenants:
- OCI Riyadh (Requestor + Acceptor)
- OCI Jeddah (Acceptor)
- OCI Dubai (Requestor)
In this example, Riyadh will be the Requestor for Jeddah and the Acceptor for Dubai.
Conclusion
Setting up a Remote Peering Connection (RPC) between two OCI tenants requires careful planning, precise configuration, and the correct IAM policies. By following this step-by-step guide, you have successfully established a secure and functional RPC between two DRGs in separate tenants. This connection enables seamless communication across networks, a crucial component for building scalable and multi-tenant OCI architectures.
To simplify the process and eliminate potential policy errors, the RPC IAM Policy Tool provides an easy way to generate the required IAM policies for both the Requestor and Acceptor tenants. Ensuring that your policies, DRG attachments, and regional subscriptions are correctly configured will guarantee a smooth peering setup.
Beyond basic RPC configurations, designing multi-tenant architectures with three or more tenants adds further flexibility and scalability to your OCI network. Understanding the role of each tenant—whether as a Requestor, Acceptor, or both—allows you to build robust, interconnected environments that support hybrid and distributed workloads efficiently.
By leveraging OCI’s networking capabilities, you can create secure, scalable, and high-performance cross-tenant architectures that align with enterprise networking best practices. If you encounter issues, revisiting IAM policies and DRG configurations is a great first step in troubleshooting.
With this knowledge in hand, you are now well-equipped to establish and expand RPC connections in Oracle Cloud Infrastructure to meet your organization’s networking requirements. Happy peering!