11.3 Zero Trust Packet Routing (ZPR): Security Attributes & Intent-Based Policy
Key Takeaways
ZPR enforces intent-based network policy using security attributes applied to resources, and the policy keeps working when the network topology changes.
A packet reaches its target only if a route exists and it passes every NSG, security list, and ZPR policy rule; failing any one of them drops the traffic.
ZPR enforces policy on VCN traffic, including traffic through local peering and DRGs, but it does not enforce policy on traffic from the internet or on-premises networks.
ZPR allows 1,000 security attributes per tenancy, 1 per VCN, 5 per VNIC, and 3 per other resource.
ZPR is a network-layer (L4) control, while IAM policy is an application-level (L7) control over which principals may call OCI APIs.
Why ZPR Exists
Network security groups and security lists are written in terms of IP addresses and CIDR blocks. When an architecture changes, for example when a subnet is re-addressed, a VCN is peered, or a route table is edited by mistake, IP-based rules can silently allow more than intended. Zero Trust Packet Routing (ZPR) lets you express security intent about resources themselves: "trusted application servers may connect to sensitive databases on the database port." ZPR enforces that intent at the network level for every access attempt, regardless of later changes to the network design.
Building Blocks
| Concept | Meaning |
|---|---|
| Security attribute namespace | A container for a set of security attributes, such as data or networks |
| Security attribute | A label that ZPR policy can reference, such as data:sensitive or hosts:trusted |
| ZPR policy | A rule that governs communication between endpoints identified by their security attributes |
| ZPR Policy Language (ZPL) | The language used to write ZPR policy statements |
| ZPR Visualizer | A view of the relationships between attributes, protected resources, and policies in a region |
The workflow has three steps:
- Create security attribute namespaces and security attributes.
- Write ZPR policies that use the attributes.
- Add the security attributes to resources.
Resources that support security attributes include compute instances and instance configurations, VNICs, VCNs, DB systems and Autonomous AI Databases, load balancers and network load balancers, Network Firewall, OCI Cache clusters, Search with OpenSearch clusters, File Storage mount targets, Functions applications, bastions, stream pools, Recovery Service subnets, and private endpoints for services such as Resource Manager and DevOps.
Writing ZPL Policies
Within one VCN. Oracle's basic example lets trusted hosts reach sensitive data inside the VCN that carries the networks:internal attribute:
in networks:internal VCN allow hosts:trusted endpoints to connect to data:sensitive endpoints
Restricting the protocol and port. Policies can limit a connection to a protocol and port. Oracle's Base Database guidance uses statements like:
in networks:app VCN allow apps:frontend endpoints to connect to db:orders endpoints with protocol='tcp/1521'
Reaching Oracle services. A resource such as a DB system needs to reach the Oracle Services Network for backups and management:
in networks:app VCN allow db:orders endpoints to connect to 'osn-services-ip-addresses'
Across two VCNs in the same region. When both VCNs have security attributes, a policy can name both:
allow networks:net1:App1 endpoints in networks:net1 VCN to connect to DB-Server:App1 endpoints in networks:net2 VCN
Across regions, or to VCNs without attributes. Traffic between VCNs in different regions, or to a VCN that has no security attribute, must be written with CIDR or IP-based policy, for example allowing an attribute-tagged client to connect to a standby VCN's CIDR block for Data Guard.
Clustered databases. For RAC, the database nodes must be allowed to connect to each other, so Oracle's guidance includes a statement letting endpoints with the database attribute connect to endpoints with the same attribute.
How ZPR Fits With Other Controls
ZPR is built on top of existing network controls. For a packet to reach a target:
- A route table entry must exist.
- Every applicable NSG and security list must allow it.
- The ZPR policy must allow it.
If any of these is missing, the traffic is dropped. ZPR therefore adds protection; it never opens a path that the other controls block.
| Control | Applies to | How it is attached | Limit |
|---|---|---|---|
| Security list | All VNICs in a subnet | Associated with the subnet | 5 per subnet |
| Network security group | Selected VNICs in one VCN | VNICs join or leave the NSG | 5 per VNIC |
| ZPR | Selected resources in one or more VCNs | A security attribute on the resource | 3 per resource, 5 per VNIC |
ZPR also differs from IAM. ZPR is a network-layer (L4) control that looks at the security attributes of the source and target, the IP address, the protocol, and the port. IAM is an application-level (L7) control that decides which principals can call which OCI APIs. A user may have IAM permission to manage a database and still be blocked by ZPR from opening a network connection to it from an untrusted host.
What ZPR Does Not Cover
ZPR enforces policy on VCN traffic, including traffic routed through local peering gateways and DRGs. It does not enforce policy on traffic arriving from the internet or from on-premises networks. For those paths, use NSGs, security lists, the Network Firewall, and WAF. Oracle also suggests running Network Path Analyzer before applying security attributes to peered VCNs, to find routing problems first.
In OKE, ZPR security attributes are supported for managed and self-managed nodes in clusters that use the VCN-native CNI plugin, but not for virtual node pools or flannel clusters.
Limits
| Item | Limit |
|---|---|
| Security attributes per tenancy | 1,000 |
| Security attributes per VCN | 1 |
| Security attributes per VNIC | 5 |
| Security attributes per other resource | 3 |
| Policy statements per policy object | 50 |
| Policy objects per tenancy | 100 |
| Policies for peered VCNs per tenancy | 200 |
A security team applies the attribute data:sensitive to a database and hosts:trusted to application servers, and writes the ZPR policy "in networks:internal VCN allow hosts:trusted endpoints to connect to data:sensitive endpoints". A different server in the same VCN, which has no security attribute, has an NSG rule that permits port 1521 to the database. What happens when it tries to connect?
It succeeds, because the NSG allows it and NSG rules take precedence over ZPR
It succeeds, because ZPR policies apply only to traffic arriving from on-premises networks
It is dropped, because the packet must pass every control, including ZPR policy
It is dropped only when the server is in a different subnet from the database
An architect wants ZPR to protect a database from clients in an on-premises data center that connect over FastConnect. What should the architect understand about this design?
ZPR policies apply automatically to clients that use FastConnect private peering
ZPR does not apply to on-premises traffic; use NSGs, security lists, or a firewall
On-premises clients must receive security attributes through the DRG attachment
ZPR blocks all on-premises traffic by default until a CIDR-based ZPR policy allows it
Sections you finish are checked off in the contents.