Zero Trust Packet Routing on OCI

Enforcing Network Security Based on What Workloads Are, Not Where They Sit

Executive Summary

Circumventing the cloud security is a bold challenge the enterprises today as the incidents go beyond the perimeter, conquering after a workload has already been reached, through a compromised instance, a leaked credential, or an overprivileged service account. In the fast-paced adoption of security enablement, almost 50% of industries have adopted Zero Trust strategy. Keeping its essence aside for a moment, Oracle Cloud Infrastructure (OCI) has released three controls, designed to work together, that give a checkmate to how far an attacker can strategize moves inside with Zero Trust Packet Routing (ZPR), Private Service Access (PSA), and IAM deny policies guarding your infrastructure.

Together, these controls harden the security based on a workload’s declared identity and approved network path, rather than IP address or network location. This briefing summarizes what each control does, walks through three realistic attack scenarios each is designed to block, and closes with discussion points for evaluating adoption.

  • No implicit trust: ZPR requires an explicit policy for any workload-to-workload communication. Anything not declared is denied by default, even within the same subnet or VCN.
  • Defence in depth: ZPR, PSA, and IAM deny policies operate at three independent layers – workload, service endpoint, and request path, so satisfying that only one control will not help.
  • Attribute-based, not IP-based: Policies are tied to workload identity/attributes, so they remain valid through autoscaling, instance replacement, and topology changes, with no IP allowlists to maintain.
  • Audit-ready: All the three controls log to OCI Audit and can be rolled out incrementally, starting with the most sensitive workloads.

Background

Lateral movement is one of the most common post-compromise patterns in cloud environments as an attacker gains a foothold on a less-sensitive, externally reachable system and then attempts to pivot from there toward higher-value data. Traditional network security has security lists, route tables, subnet boundaries, governing the traffic based on IP address and network topology. If a compromised instance has a private IP that is routable to a sensitive subnet, that path is often open by default.

OCI ZPR changes the basis for that decision. Access between workloads is determined by declared intent, expressed as policy over workload attributes, not by network topology. What is permitted to communicate with what is stated explicitly; anything not covered by a policy is denied. PSA and IAM deny policies extend the same principle to how OCI services themselves such as how and where the Object Storage is accessed.

Three Layers of Control

OCI ZPR, PSA, and IAM deny policies are part of the same release and are designed to be used together, with each operating at a different layer:

Control Layer Enforced What It Does
OCI Zero Trust Packet Routing (ZPR) Workload-to-workload (network) Allows communication only between workloads whose declared attributes match an explicit policy. Unlisted pairs are denied by default, regardless of IP address or subnet.
Private Service Access (PSA) OCI service endpoint Validates that credentials used against a private service endpoint (e.g. Object Storage) belong to the expected tenancy. Cross-tenancy credentials are rejected before the request reaches the service.
IAM Deny Policies Request path Requires that requests to OCI services arrive over an approved private network path (e.g. through a PSA gateway). Denies requests over the public internet even with a valid, sufficiently privileged credential.

The scenarios below walk through each control in a concrete situation, with the policy configuration and expected behavior for each.

Detailed Scenario Walkthroughs

Scenario 1: Lateral Movement into the Database

An attacker gains a foothold on a web-facing instance in the front-end tier, a less-sensitive, externally reachable system and attempts to pivot toward the database. The web instance has a private IP address that is routable to the database subnet, so a traditional, IP-based security rule might allow the connection to proceed.

With OCI ZPR in place, the web node carries the attribute apps:frontend, and the database carries apps:db. The policy for this environment permits only apps:backend endpoints to connect to apps:db endpoints on TCP/1521. No policy exists for apps:frontend to connect to apps:db. When the compromised web node attempts to connect to the database, ZPR evaluates the attribute pair, finds no match, and denies the connection at the network layer before a TCP handshake completes or the database issues an authentication prompt.

Policy Configuration and Expected Behavior

# ZPR policies for a three-tier application

in networks:app-vcn VCN allow apps:frontend endpoints to connect to apps:backend endpoints with protocol=’tcp/443′

in networks:app-vcn VCN allow apps:backend  endpoints to connect to apps:db      endpoints with protocol=’tcp/1521′

# No policy exists for: apps:frontend to apps:db

 

# Attacker on compromised web node attempts direct connection to DB:

$ nc -zv <db-private-ip> 1521

  => Connection refused   # ZPR: no matching policy for this attribute pair

 

# Legitimate backend node connecting to DB:

$ nc -zv <db-private-ip> 1521

  => Connection succeeded # ZPR: apps:backend to apps:db policy matched

Key takeaway:  Enforcement is tied to the workload’s attribute, not its IP address, so this protection continues to apply across autoscaling events, instance replacements, and VCN topology changes with no policy updates required when IP addresses change.

Scenario 2: Data Exfiltration to an External Tenancy

When workloads interact with OCI services, PSA can require that access go through a private endpoint inside the VCN rather than the public service address. At that endpoint, PSA validates the tenancy of the credentials in the request while credentials belonging to a different tenancy are rejected before the request reaches the Object Storage service.

ZPR adds a second, independent constraint where only nodes tagged with the apps:psa attribute are permitted to reach the PSA endpoint at all. A node without that attribute cannot make Object Storage API calls through PSA, regardless of the credentials it holds, both conditions must be satisfied.

Policy Configuration and Expected Behavior

# Attempt 1: Valid credentials, uploading to an external tenancy bucket

$ oci os object put –bucket-name attacker-bucket \

    –namespace external-tenancy –file records.csv

  => 403 Forbidden   # PSA endpoint: cross-tenancy credential rejected

 

# Attempt 2: Node without apps:psa attribute tries to reach the PSA endpoint

$ nc -zv <psa-objectstorage-endpoint> 443

  => Connection refused  # ZPR: no policy for this attribute to PSA endpoint

 

# Authorized: backend node tagged apps:psa, uploading to an internal tenancy bucket

$ oci os object put –bucket-name prod-reports \

    –namespace my-tenancy –file report.csv

  => 200 OK

Key takeaway:  PSA and ZPR operate independently, so satisfying only one is not enough. A valid credential without the right network path is rejected by PSA; a node with network access but the wrong attribute cannot reach the endpoint through ZPR.

Scenario 3: Stolen Credentials Used from Outside OCI

Credential exposure is one of the more damaging risks in cloud environments: an OCI API key can be leaked through a committed configuration file, a hard-coded secret in a CI/CD pipeline, a phished developer, or a misconfigured environment variable. Traditionally, the question after a leak is whether the key has the right IAM permissions. IAM deny policies, combined with PSA, add a second question – is the request coming from the right place?

In this example, an IAM deny policy applied to the Object Storage namespace requires every request to arrive through a PSA gateway. The policy condition evaluates request.gateway.type; if the request arrives from the public internet, the condition is not satisfied and the request is denied, regardless of whether the credential is valid, regardless of the IAM permissions attached to the user, and regardless of the resource being requested.

The denial returns 404 Not Found rather than 403 Forbidden. This is intentional as a 403 would confirm to the attacker that the resource exists and that they simply lack permission. A 404 avoids confirming the existence of the bucket to an unauthorized requester. The same credentials, used by an authorized internal process whose traffic routes through the PSA gateway, continue to work exactly as before.

Policy Configuration and Expected Behavior

# IAM Deny policy: applied to the Object Storage namespace

Deny any-user to inspect object-family in tenancy

  where any {

    not request.gateway.id,

    request.gateway.type != ‘privateserviceaccess’

  }

 

# Attacker: valid API key, request sent from a laptop over the public internet

$ oci os object get –bucket-name prod-backups \

    –name data.sql.gz –file /tmp/local.gz

  => 404 Not Found   # IAM Deny triggered; bucket existence not confirmed

 

# Authorized internal process: same credentials, request routed via PSA

$ oci os object get –bucket-name prod-backups \

    –name data.sql.gz –file /var/backup/data.sql.gz

  => 200 OK          # PSA gateway present; IAM Deny condition not triggered

Key takeaway:  A valid API key used from outside the approved network path is not treated the same as one used from within it. The credential still has to arrive through a PSA gateway for the IAM deny condition to be satisfied.

Top-Notch Security for Your Cloud Infrastructure

OCI ZPR, PSA, and IAM deny policies each operate at a different layer for workload communication, service endpoint, and request path. Used together, they make network position alone, a valid credential alone, or access to the right endpoint alone insufficient as each scenario above requires a different combination of conditions to be satisfied simultaneously.

All three controls produce entries in OCI Audit logs. ZPR security attributes are assigned through the OCI Console, CLI, or Terraform. PSA and IAM deny policies can be scoped to specific services and rolled out incrementally, starting with the most sensitive workloads.

Discussion Points

Suggested discussion points for evaluating adoption internally. However, these are not conclusions about our current environment:

  • Identify our most sensitive OCI workloads (databases, object storage buckets holding regulated or confidential data) as first candidates for a ZPR / PSA / IAM deny policy pilot.
  • Review current reliance on IP-based security lists for workload segmentation and assess a path to attribute-based ZPR policies.
  • Confirm OCI Audit log integration with our existing monitoring/SIEM tooling for visibility into policy denials.
  • Plan an incremental rollout, starting with one pilot workload before broader adoption.

Conclusion

Organizations going for cloud infrastructure must implement zero trust. Oracle offers layered security posture with greater controls, templates, and tools, driving the deployments faster with better scalability and unified management. Manage secured access to your data with OCI Zero Trust Packet Routing as these policies sit at the network layer, safeguarding your enterprise from unpredicted incidents or attacks.  

Share:

Recent Posts

Categories: