OCI Events: Email Notification for Object Storage Updates

Oracle object storage is used in daily tasks like uploading backup data, archiving data, purging old data, etc. It will be very useful if we get notified about the changes happening in object storage. We can achieve this through OCI events. In this article we will go through the steps to configure OCI events for Object storage updates.

Object Storage Bucket → OCI Events Rule → OCI Notifications Topic → Email Alert

Whenever a new object is created in an OCI Object Storage bucket, OCI can generate an event, match it with an Events rule, and send an email notification through the Notifications service. OCI Events is designed to create notification based on resource state changes, and Object Storage supports emitting events for object state changes at the bucket level.

1)     Create an Object Storage Bucket

In the OCI console, open the navigation menu and move to Storage → Buckets. Select the compartment and click Create Bucket. Enter a bucket name and click Create

We will create events to capture the updates in this bucket.

---

2) Enable Event Emission for Object State Changes

For Object Storage to participate in this workflow, the bucket must emit events for object state changes. In the bucket details page, click Emit object events.

Click Enable button.

Now we could see Emit Object Events status is enabled in the console.

This allows OCI to generate an event when an object is created, updated, or deleted in the bucket.

3)  Create an OCI Notifications Topic

Next, create a topic that will receive messages from OCI Events.

In the OCI console, move to Developer Services -> Application Integration -> Notification services.

Click Topics and click Create Topic. Enter a topic name and click Create.

OCI Notifications uses topics as logical channels for publishing messages to subscribers.

4)  Add an Email Subscription

The next step is to add email as a subscriber to the topic.

Click the newly created topic and click Create Subscription.

Select protocol Email and enter email address that has to receive notification and click Create.

 

OCI will send a confirmation email to that address. The subscription remains pending until we confirm it.

5)  Confirm the Email Subscription

The email subscription will send a confirmation email to prescribed email ID. Open the confirmation email sent by OCI Notifications and click the confirmation link.

 

After confirming, In the OCI console, refresh the subscription page and verify the subscription status shows as Active. This step is mandatory, without this confirmation step, the email notifications will not be delivered.

 

6)  Create an OCI Events Rule

Now let’s create the rule that connects Object Storage events to the Notifications.

In the OCI console, choose Observability & Management → Events Service → Rules

Click Create Rule, enter a name and choose the event type related to Object Storage object creates.

For the action, choose Notifications and select the topic created earlier and click Create

7) Upload a File to the Bucket

Let’s test it now. In Object Storage bucket, Click Upload and Choose a file to upload and click Upload.

Once the object is created, OCI should emit the event, the Events rule should match it, and Notifications should send an email to the subscribed address. We can also enable notification for object delete, update.

---

8)  Verify the Email Notification

Check the mail inbox for the email notification generated by OCI. The below notification has been received for deleting an object from bucket.

At this point, we have a working event driven automation flow in your OCI tenancy.

 

 

OCI Logging – Auditing VCN Security list changes

In the previous post, we discussed how to audit VCN Security List changes. In this article, we will review how to audit VCN Route Table changes using OCI Audit service.

Route Tables control how traffic flows within a VCN. Any incorrect modification such as adding an Internet Gateway route or changing a DRG target can impact security posture, connectivity, or cost governance. Therefore, auditing route table changes is critical for enterprise cloud governance.

Login into OCI Console -> Networking -> VCN. It will show list of VCNS, we can choose the desired one.

In the VCN details page, choose Routing, it will list all the route tables associated with the VCN.

In this exercise we have only default route table with single route rule and the route rule is created for external access through Internet Gateway. We will add a route rule for Service Gateway.

Now route rule is added, we will use Audit to identify what changes happened in the route table.

OCI Audit is a native, always-on service that records all API operations across your tenancy. Any modification to a VCN Route Table (creation, update, or deletion) is captured here with full request payload and identity metadata.

Select:

• Compartment → root
• Set appropriate Time Range

Route Tables are network resources under specific compartments. Select the right compartment o see changes across all sub-compartments if required.

Once the timeframe is chosen the audit page will updated with all Event types recorded in that timeframe. Choose UpateRouteTable event type which is appropriate to our requirement.

Other available event types are below.

Event Name = UpdateRouteTable
Event Name = CreateRouteTable
Event Name = DeleteRouteTable

UpdateRouteTable event provides

·       Who made the change (User/Service Principal)

·       When it was made (Timestamp)

·       From which IP address

·       Target Resource OCID

·       Request/Response payload

 

In the JSON output, locate the stateChange section.

Inside stateChange, expand:

• previous
• current

Within these sections, examine routeRules.

By comparing the previous and current routeRules arrays, you can identify exactly what changed.

In our case:

• previous → One route rule
• current → Two route rules

This confirms that a new route rule was added.

In summary, OCI Audit logs provide a reliable and tamper-resistant mechanism to track route table changes, something the OCI Route Table UI itself does not natively provide.

 

OCI Logging – Auditing VCN Security list changes

In this article, we discuss a common governance requirement: auditing changes to a VCN Security List. VCN security list has set of firewall rules, but it doesn’t list information about when a rule has added/modified/removed. But this information will be very much required when we work on finding route cause of security related issues. It’s highly possible that security list changes would have created violations and we need to identify who changed what, when, and from where. 

Lets explore how OCI Audit helps to get the details. Choose a Security list and perform changes in the security list rules.

 

Add a Ingress security rule to the security list.

Add Ingress rule

Also add a egress rule to the security list.

Egress rule has been added.

We have added an Ingress and egress rule. Now our task is to identify when the ingress/egress rule has been changed and what changes have been done.

We can find the details at Observability Management -> Logging -> Audit. OCI Audit records control-plane events - meaning actions performed through the OCI Console, OCI CLI, SDK, Terraform, or APIs that create, update, or delete OCI resources.

In the Audit page, first select the compartment where you want to review activity. Audit entries record control-plane events, such as creating, updating, or deleting OCI resources.

The most important filter on this page is the Time range. By default, the console shows events from the last 5 minutes. When you open the Audit page, it loads all audit events that occurred within that default time window.

Other filters—such as User, Resource, Request action, and related fields will be populated based on the events retrieved for the selected compartment and time range. If you expand the time window (for example, last 1 hour or last 24 hours), you will see more events and more filter values available.

Another important filter is Event type. All audit events have event type. Choosing right event type will help us to reach the event that we look for. In this exercise, we target the security list changes. Event type having security list change is “com.oraclecloud.virtualNetwork.UpdateSecurityList”.

In case if we are not seeing this event type, then we may need to increase the Filter by time.

Once the event type is chosen, we could see the related events. In our case Ingress and Egress change have happened at different time, hence it has created two different Audit events.

Click the arrow button located in the right corner, that will expand the event.

The event contains many details. To identify what changed in the Security List, locate the stateChange section. It contains two parts:

• current: the Security List state after the change
• previous: the Security List state before the change

Comparing these two sections reveals exactly what was modified.

The current denotes the current status of security list and previous denotes the state of security list before change. Comparing both will give the details of the change.

Under the current we can find egressSecurityRules and ingressSecurityRules which has details of security rules.

Click the egressSecurityRules

Collect egressSecurityRules from previous section.

We could the difference is “2” which is present only in current version. It means a rule has been added by the update.

Checking ingressSecurityRules, we could see it has same number of rules for current and previous section, which means only egress rule got changed at this time.

Along with the actual changes, we can fine some additional details.

Timecreated -> the time the change has happened.
CompartmentId -> compartment of security list
VcnID -> OCID of VCN
id -> OCID of security list.

In summary, OCI Audit logs provide a reliable way to track and prove changes made to VCN Security Lists, something the Security List UI alone does not capture. 

  OCI Logging – Enable Flow logging for VCN

Oracle Cloud Infrastructure (OCI) provides built-in observability features to help you monitor cloud activity. For networking, VCN Flow Logs capture traffic flow metadata (source/destination IP, ports, protocol, direction, bytes/packets, and accept/reject status). This is very useful for troubleshooting connectivity, validating security posture, and supporting audits or penetration testing evidence.

In this article, we will enable Flow Logs at the subnet level and control the captured traffic using a Capture Filter.

To enable Logging to VCN, go to Network -> VCN -> Subnets page.

Click Monitoring tab and in the Monitoring page, we could see Logs section.

 We need to enable Flow Logs. Click the three dots located in the right side and click Enable Log option.

Specify compartment, Log location, Log group and Log name.

We ned to specify Capture filter, it’s a required parameter to enable log. We need to specify OCID of desired Capture filter.

The network activities will create huge amount of logs, OCI provides option to mention which traffic needs to be included or excluded from flow logs. The Capture Filter can be created in the Networking -> Network Command center -> Capture Filters.

Specify name, compartment for Capture filter. It can be created for either Flow log capture filter and VTAP. For our activity we need capture filter for Flow log. Sampling rate defines the percentage of network flows to be examined, we can specify one of the predefined percentage (1%,5%,10%,20%,25%,50%,100%).

The next section is defining rules which needs to included or excluded from flow logs. We can define upto 10 rules in a capture filter and it will follow the order to examine. If first rule is met then it will stop executing other rules, so we need to be careful with the rules.

The rules can also defined later in the capture filter. Suppose we are not sure about the traffic to be excluded/included, then we can leave with Traffic disposition as All (Accept and Reject) and Include/Exclude as Include, in that way we are making to include all the traffic without any condition.

Once the capture filter is created, copy the OCID of that.

Paste the OCID in the Subnet’s Enable resource log page that we discussed earlier.

It also gives option to specify retention period of captured logs. Its available in the Advanced option.

The default and minimum Log retention is 1 month and Maximum is 6 months.

 Click the Log name and in the Log details page, choose Explore log. We could see all the flow traffic captured in the log.

 

 IPv6 Connectivity Across OCI VCNs via Dynamic Routing Gateway

In the past articles, we discussed the IPv6 address format and how the communication can happen via Internet Gateway. In this article, we will explore how IPv6 communication can be set up via Dynamic Routing Gateway (DRG).

IPv6 address includes a VCN-specific identifier, which ensures global uniqueness. Because of this uniqueness, interconnectivity between networks is possible even when their IPv4 CIDR ranges overlap. If the VCN, Subnets and Compute instances are enabled with IPv6 then please move to DRG section.

First, we create two VCNs with the same IPv4 CIDR range. Next, we enable IPv6 CIDR ranges for both VCNs to allow seamless communication over IPv6. In this exercise VCNs are created in the same region.

The VCN has only IPv4 CIDR Range.

Lets enable IPv6 CIDR range to the VCN.

After enable, we could see IPv6 CIDR range now.

Right now, only VCN got enabled with IPv6 and we need to enable IPv6 CIDR range at Subnet level.

In the Subnet -> IP Administration page, add IPv6 prefix.

Perform the above steps for Second VCN and subnets within the second vcn.

At this stage VCNs and Subnets are configured with IPv6. Lets test the communication among them by creating VM compute instance in each VCN and try to communicate through IPv6.

After instance creation, we can check their IPv4 and IPv6 address.

 

Dynamic Routing Gateway

Create a Dynamic Routing Gateway (DRG) in the OCI console.

Attach the VCNs into the DRG.

 

The DRG attachement has default route table. Check the route rules.

Click “Get all route rules” button. We could see IPv4 CIDR are showing conflict and IPv6 routes are clean.

 

Security rules and Route tables configuration

At the network side, we need to enable rules to allow communication among them. Add Security list and Route rule to allow communication between the instances. Specify IPv6 CIDR range of other VCN as Source CIDR (Ingress) and Destination CIDR (Egress) and use “IPv6-ICMP” protocol.

First_VCN

 

For Route rules, Specify Dynamic routing gateway as protocol with IPv6 version.

Second_VCN

Perform the security rule and Route rule configuration in Second VCN.

Test the connectivity by pinging the compute instances from each other.