Introduction

As customers adopt multi-tenancy patterns in Oracle Cloud Infrastructure (OCI), I often get asked:
“How do we centralize operational or security events across all our environments into one place?”

Whether the reason is centralized SIEM integration, SOC alerting, or simply reducing duplicated efforts across business units — the ability to route OCI events from multiple tenancies into a single destination tenancy has become increasingly important.

I’ve been working on a pattern using OCI Events + cross-tenancy IAM policies that lets you do exactly that — without deploying agents, polling logs, or breaking tenancy boundaries. In this blog, I’ll walk you through the architecture, key IAM setups, and show how this design works beautifully for cases like Cloud Guard problem events, but also scales to cover services like Budgets, Vault, or Object Storage.

Why This Matters

In environments where each business unit operates its own tenancy, Cloud Guard might be enabled in each of them — monitoring and detecting threats independently.

However, for your SOC or DevSecOps team, having to log in to five different tenancies to check for active problems is operationally expensive and inefficient.

Instead, wouldn’t it be better to push these Cloud Guard problem events directly into your central tenancy, where you can:

– Forward them to SIEM tools
– Trigger ServiceNow tickets
– Store and analyze them in OCI Logging Analytics
– Or invoke remediation via OCI Functions

This is where cross-tenancy event delivery shines.

Architecting a Scalable Event Hub

Here’s a simplified architectural pattern for building a central event hub in OCI:

This enables a fully decoupled, multi-tenant-to-central-tenant pattern — where source environments emit only the required event metadata and let the destination handle enrichment, filtering, and integrations.

Enabling Cross-Tenancy Delivery

OCI requires explicit IAM policies to allow event rules in one tenancy to invoke actions in another. This includes ONS topics, Streaming services, and Functions.

To enable this:

In the source tenancy(where the event rule resides)

define tenancy destination_tenancy as <destination_tenancy_ocid>
endorse any-user to {ONS_TOPIC_PUBLISH, FN_INVOCATION, STREAM_READ, STREAM_PRODUCE} in tenancy destination_tenancy where request.principal.type = 'eventrule'

In the destination tenancy (where the event action is triggered):

define tenancy source_tenancy as <source_tenancy_ocid>
admit any-user of tenancy source_tenancy to {ONS_TOPIC_PUBLISH, FN_INVOCATION, STREAM_READ, STREAM_PRODUCE} in tenancy where request.principal.type = 'eventrule'

These policies ensure that the event rule’s principal is authorised to publish, invoke, or stream to resources across tenancy boundaries. This is crucial for compliance and isolation guarantees in multi-tenancy environments.

Example: Cloud Guard Problem Events Across Tenancies

Cloud Guard is OCI’s native threat detection and posture management service. It emits event types when problems are:

• Detected (com.oraclecloud.cloudguard.problemdetected)
• Remediated (com.oraclecloud.cloudguard.problemremediated)
• Dismissed (com.oraclecloud.cloudguard.problemdismissed)

In a decentralized model, each tenancy typically operates its own Cloud Guard instance independently — each surfacing problems relevant to their own tenancy. However, an enterprise SOC team may want to monitor all problems centrally, correlate across environments, and integrate with their SIEM or ticketing platform.

To do this:

1. Each source tenancy defines an event rule matching the relevant Cloud Guard event types.
2. The rule’s action references a Notification topic, Stream, or Function in the central tenancy.
3. The centralized resources ingest and route the event for downstream processing — such as JSON enrichment, SNOW ticket creation, or Streaming Analytics.

Here’s what the OCI CLI rule creation might look like from a source tenancy perspective:

oci events rule create \
  --compartment-id ocid1.tenancy.oc1..source-tenancy-ocid \
  --display-name "CloudGuard Events Rule" \
  --description "Sends problem lifecycle events to central SIEM pipeline" \
  --is-enabled true \
  --condition '{"eventType":[
    "com.oraclecloud.cloudguard.problemdetected",
    "com.oraclecloud.cloudguard.problemremediated",
    "com.oraclecloud.cloudguard.problemdismissed"
  ]}' \
  --actions '{
    "actions": [
      {
        "actionType": "ONS",
        "topicId": "ocid1.onstopic.oc1.region..destination-tenancy-topic-ocid"
      }
    ]
  }'

This rule runs within the source tenancy, but publishes to a topic in the centralized destination tenancy.
 

Depending on your use case, you can configure one or more of the three actions in the destination tenancy:

{
  "actions": [
    {
      "actionType": "FAAS",
      "functionId": "<function_OCID>"
    },
    {
      "actionType": "ONS",
      "topicId": "<topic_OCID>"
    },
    {
      "actionType": "OSS",
      "streamId": "<stream_OCID>"
    }
  ]
}

Below is a screenshot from the source tenancy’s OCI Console, showing the Cloud Guard Events Rule created with the CLI command:

Note: Since the destination Notification topic, Function, or Stream resides in the central tenancy, it will not appear in the resource listings of your source tenancy’s console. This is expected behavior — cross-tenancy event delivery still works thanks to the cross-tenancy IAM policies you configured.
But in case to view the full configuration of the rule, including the exact cross-tenancy destination OCIDs, use the following CLI command from the source tenancy:
 

oci events rule get --rule-id <event_rule_ocid>

Going Beyond Security: Other Event Use Cases

While Cloud Guard is a natural use case for cross-tenancy delivery, the same design can be applied for other below sample events too:

This allows centralized audit teams, SREs, or platform engineers to stay informed in real time — even across isolated organizational boundaries.

Final Thoughts

OCI’s cross-tenancy event delivery architecture is a powerful enabler for organizations looking to centralize security, observability, or compliance pipelines without sacrificing tenancy isolation. By leveraging Events, Notifications, Streaming, and Functions with carefully scoped IAM policies, you can build a responsive, scalable, and secure backbone for real-time event processing across your OCI landscape.

Whether it’s Cloud Guard problems, budget alerts, or infrastructure telemetry, the design pattern remains the same — emit, deliver, route, enrich, and act.

References

• OCI Events – Getting Started
• Services that produces events
• OCI Events CLI – Create Rule