Secure Cloud Networking in OCI – Zero Trust Packet Routing

Zero Trust Packet Routing (ZPR) is Oracle Cloud Infrastructure’s (OCI) move to bring the principles of zero trust to the packet level. In simple terms, it allows you to control exactly which workloads can communicate with each other, based not on IP addresses, ports, or subnets, but on high-level, intent-based labels.

Think of it as network segmentation for the cloud-native era. Done without messing with subnet layouts, static security lists, or hard-to-follow firewall rules.

ZPR allows you to define policies that are explicit, least-privilege, auditable, and decoupled from network topology. It provides an additional layer of protection on top of existing OCI security primitives, such as NSGs, Security Lists, and IAM.

Key Concepts Behind ZPR

To really understand ZPR, let’s break it into four essential building blocks:

1. Security Attribute Namespaces & Attributes

These are labels that describe your cloud resources in human-readable, intent-focused terms.

• A Namespace is a grouping mechanism for attributes (e.g. app, env, sensitivity).

• An Attribute is a key-value pair like app:frontend, env:prod, sensitivity:high.

ZPR lets you tag resources with up to 3 attributes (1 for VCNs), and policies reference those attributes to determine which communication flows are permitted.

This is powerful because it enables semantic security policies. You are no longer relying on IP or port-based rules and are using logic that’s closer to your business model.

2. ZPR Policy Language (ZPL)

ZPR policies are written in ZPL, Oracle’s purpose-built policy language for defining allowed connections. ZPL statements follow a clear syntax:

This type of human-readable policy is easy to reason about, easy to audit, and matches well with how teams think about their systems (by role, not IP).

More policy examples can be found here.

3. Enforcement and Evaluation Logic

ZPR does not replace OCI’s native security tools but it layers on top of them. Every packet that passes through your VCN is evaluated against:

1. Network Security Groups (NSGs)
2. Security Lists (for subnets)
3. ZPR Policies

A packet is only allowed if all three layers agree to permit it.

This makes ZPR defense-in-depth rather than a replacement for traditional controls.

It’s also worth noting:

• ZPR policies are enforced only within a single VCN.

  • Inter-VCN communication still relies on other mechanisms like DRG and route tables.

• ZPR policies are evaluated at packet routing time, before any connection is established.

4. Resource Support & Scope

ZPR is currently supported on a growing list of OCI resources, including:

• VCNs

• Compute Instances

• Load Balancers

• DB Systems (Autonomous/Exadata)

Also important:

• ZPR can be enabled only in the home region of a tenancy

• Enabling ZPR in a tenancy creates a default Oracle-ZPR security attribute namespace

• Changes to ZPR policies in the Console might take up to five minutes to apply

How to Use ZPR

 

Step 1: Create Namespaces and Attributes

You start by creating Security Attribute Namespaces (e.g., env, app, tier) and assigning Attributes (e.g., env:prod, app:frontend) to your resources.

You can do this via:

• OCI Console

• CLI (oci zpr security-attribute create)

• Terraform (via oci_zpr_security_attribute resource)

• REST API or SDKs

You can assign up to 3 attributes per resource (except VCNs, which allow only 1).

Step 2: Write ZPR Policies Using ZPL

Once your attributes are in place, write policies in ZPL to define who can talk to whom. You can use:

• Simple Policy Builder – GUI-based, good for basic use cases. It lets you select from prepopulated lists of resources identified by their security attributes to express security intent between two endpoints. The policy builder automatically generates the policy statement using correct syntax.

• Policy Template Builder – Uses predefined templates It lets you select from a list of templates based on common use case scenarios that provide prefilled ZPR policy statements that you can then customize to create a ZPR policy.

• Manual Policy Editor

• CLI or API – For IaC and automation flows

Example: Allow backend apps in the prod-vcn to reach the database tier on port 1521 (Oracle DB):

Step 3: Assign Attributes to Resources

Finally, use the Console or CLI to attach attributes to resources like compute instances, load balancers, and VCNs.

This is the crucial step that links the policy with real workloads.

Security Advantages of ZPR

Zero Trust Packet Routing introduces significant security improvements across Oracle Cloud Infrastructure. Here’s what makes it a standout approach:

• Identity-Aware Traffic Control
  Policies are based on resource identity and metadata (tags), not just IP addresses, making lateral movement by attackers significantly harder.

• Micro-segmentation by Design
  Enables granular control between resources such as frontend, backend, and database tiers, aligned with zero trust principles.

• No Dependency on Subnets or Security Lists
  ZPR policies operate independently of traditional network segmentation, reducing configuration complexity.

• Simplified Policy Management with ZPL
  Oracle’s purpose-built Zero Trust Policy Language (ZPL) allows for concise, human-readable security rules, reducing human error.

• Auditability and Transparency
  All ZPR policies are tracked and auditable via OCI logs and events, supporting compliance and governance needs.

• Built for Modern Cloud Architectures
  Native support for dynamic and ephemeral cloud resources like managed databases, load balancers, and more.

• Defense-in-Depth Integration
  ZPR complements other OCI security tools like NSGs, IAM, and Logging, reinforcing a layered security posture.

Summary

Zero Trust Packet Routing marks a pivotal shift in how network security is managed in Oracle Cloud Infrastructure. Traditional security models rely heavily on IP addresses, static network boundaries, and perimeter-based controls. In contrast, ZPR allows you to enforce policies based on the actual identity and purpose of resources by using a policy language that is both readable and precise.

By decoupling security controls from network constructs like subnets and IP spaces, ZPR introduces a modern, identity-centric approach that scales effortlessly with cloud-native workloads. Whether you are segmenting environments in a multitenant architecture, controlling east-west traffic between microservices, or enforcing strict rules for database access, ZPR offers the control and granularity you need without compromising agility.

The real power of ZPR lies not just in its policy engine but in how it integrates with the broader OCI ecosystem. It complements IAM, NSGs, and logging by offering another layer of precision. One that’s declarative and tightly aligned with your operational and compliance requirements.

If you are serious about least privilege, microsegmentation, and secure cloud-native design, ZPR deserves your attention.