Announcing OKE support for Zero Trust Packet Routing (ZPR)

What’s New

OCI Kubernetes Engine now supports Zero Trust Packet Routing (ZPR) for supported cluster-related OCI resources. With this support, teams can assign ZPR security attributes to those resources and write ZPR policies that define approved communication paths.

What is ZPR?

Zero Trust Packet Routing is an intent-based network security model for OCI resources. It starts with security attributes: labels assigned to supported resources. A ZPR policy references those attributes to define and enforce an allowed path between a source and a destination. Instead of describing that path only by IP address, subnet, or route shape, the policy can describe it by the roles those resources play, such as an application tier reaching a storage tier. For example, a policy can express the intended path directly:

in network:backend-vcn VCN allow app:orders-api endpoints to connect to storage:orders-fss endpoints

Why ZPR?

The key idea is separation. In many cloud networks, the same configuration carries two concerns: reachability and security intent. Network operators manage routes, subnets, NSGs, and security lists so traffic can move. Security operators need to state which resources should be allowed to communicate. When that intent is expressed only through IP addresses, CIDR ranges, and network shape, a network change can make the approved path harder to review and can create unintended vulnerabilities in the network path that can lead to costly network breaches. ZPR lets Security operators teams express part of that intent with attributes such as application, environment, or data role, so the policy stays tied to the intended path even when the underlying network changes.

ZPR does not replace existing network controls. Route rules, NSGs, and security lists continue to decide whether the network can carry the traffic. ZPR adds an attribute-based policy decision for attributed resources. When traffic involves one of those resources, the network controls must allow reachability and a ZPR policy must allow the attributed source and destination. For pod-to-pod traffic on the same node, Kubernetes NetworkPolicy remains the pod-level control.

For a deeper explanation of the general ZPR model and its design motivation, see First Principles: Robust data breach protection with Zero Trust Packet Routing.

Why This Matters For Kubernetes Teams

OKE clusters depend on OCI resources that sit on important access paths: pods send traffic through node VNICs, clients reach applications through load balancers or ingress load balancers, administrators connect to the Kubernetes API endpoint, and workloads may use File Storage mount targets. Kubernetes teams can already use VCN design, routes, NSGs, security lists, IAM, Kubernetes RBAC, and Kubernetes NetworkPolicy to control access to these resources. ZPR does not replace those controls. It adds a separate check for supported OCI resources used by the cluster, so an accidental change in network reachability does not automatically become access.

When a resource has a ZPR security attribute, network reachability is not enough. Traffic must also match a ZPR policy that allows the source and destination relationship. For example, security operators can allow pod traffic for an Orders API to reach the File Storage mount target for Orders data. Other reachable paths remain blocked unless a ZPR policy explicitly allows them.

For example, security operators can define that pod traffic for an Orders API may reach a File Storage mount target for Orders data, or that an ingress load balancer may receive traffic for a specific application path. Route rules, NSGs, and security lists continue to govern network reachability. Kubernetes NetworkPolicy remains available for pod-to-pod controls inside the cluster.

The ZPR visualizer shows how security attributes, resources, and policies are connected in a graph view.

Where ZPR Applies

When used with OKE, ZPR applies to the supported OCI resources listed below. Each resource type has its own attachment point for security attributes.

Example: Pod traffic to File Storage

The exact security attribute names depend on the customer’s security model. This example uses one OKE application path: pod traffic from the Orders API to its File Storage mount target.

The security operator can express the approved path as an application relationship: Orders API pod traffic may reach Orders File Storage. The network operator keeps the route, NSG, and security-list rules that provide network reachability. OKE applies the source attribute to the managed node secondary VNICs used for pod traffic, and the CSI volume plugin applies the destination attribute to the File Storage mount target.

• Source: app:orders-api
• Destination: storage:orders-fss
• Policy intent: allow Orders API pod traffic to reach Orders File Storage

Create the ZPR policy

Create the ZPR policy before applying security attributes to existing OKE-related resources. This policy allows pod traffic with the app:orders-api ZPR security attribute to connect to the File Storage mount target with the storage:orders-fss ZPR security attribute.

in network:backend-vcn VCN allow app:orders-api endpoints to connect to storage:orders-fss endpoints

Apply Source ZPR Security Attribute: Managed Node Secondary VNICs

For managed node pools, assign the app:orders-api ZPR security attribute to the secondary VNICs (through the Managed Node Pool configuration as shown below) used as the pod traffic source. Plan workload placement so pods that need different ZPR security attributes run in different node pools.

When assigning security attributes, teams can select the OKE-related VNIC resources that should participate in ZPR policy evaluation.

[
  {
    "displayName": "orders-api-pod-vnic",
    "nicIndex": 0,
    "createVnicDetails": {
      "subnetId": "<pod-subnet-ocid>",
      "nsgIds": ["<pod-nsg-ocid>"],
      "securityAttributes": {
        "app": {                    # ZPR security attribute namespace
          "workload": {             # ZPR security attribute key
            "value": "orders-api",  # ZPR security attribute value
            "mode": "enforce"       # Applies the attribute for ZPR policy evaluation
          }
        }
      }
    }
  }
]

oci ce node-pool update \ --node-pool-id <node-pool-ocid> \ --secondary-vnics file://secondary-vnics.json

When you update security attributes for a managed node pool, the change applies to new worker nodes. Replace existing worker nodes when existing workloads need the updated VNIC security attributes.

Apply Destination ZPR Security Attribute: File Storage Mount Target

For File Storage, add the securityAttributes parameter to the StorageClass used by the CSI volume plugin. The CSI volume plugin applies the attributes when it creates the mount target for a persistent volume claim.

The inline comments in this illustrative example identify each part of the securityAttributes value.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fss-secure
provisioner: <file-storage-csi-provisioner>
parameters:
  mountTargetSubnetOcid: ocid1.subnet.oc1..example
  securityAttributes: >-
    {
      "storage": {                # ZPR security attribute namespace
        "dataset": {              # ZPR security attribute key
          "value": "orders-fss",  # ZPR security attribute value
          "mode": "enforce"       # Applies the attribute for ZPR policy evaluation
        }
      }
    }

StorageClass parameters apply when the File Storage resources are created. Changing or recreating a StorageClass later does not update mount targets that the CSI volume plugin already created.

How To Get Started

ZPR is optional. Start with a cluster or application path where clearer communication rules matter most, such as sensitive workloads, audit-driven environments, or paths shared across platform, network, and security teams. A good first scope is one cluster, one node pool, or one application path with clear traffic requirements and a rollback plan.

Confirm The Cluster Is In Scope

Use this table as a pre-flight check before assigning ZPR security attributes. It separates the OKE configurations that are in scope from the ones that need a different control plan.

Review the cluster version, pod networking mode, security attribute namespaces, ZPR policies, and IAM permissions before you apply attributes. If a cluster uses flannel for pod networking, ZPR security attributes are not supported for the pod-networking paths described in this post. If workloads need different ZPR security profiles, plan their placement across node pools before assigning node-pool VNIC attributes.

Understand How ZPR Fits With Existing Controls

For a ZPR-attributed OKE resource, connectivity is a layered decision.

Traffic must pass existing network rules and the matching ZPR policy. If route rules, NSGs, or security lists block a path, a ZPR policy will not open it. If existing network rules allow a path but no matching ZPR policy exists for an attributed endpoint, ZPR blocks the traffic.

The policy detail view helps show which policy statement allows communication between attributed resources.

Network Path Analyzer can help teams inspect this layered decision. With ZPR integration, it can show routing, NSG, security-list, and ZPR policy evaluation for a selected path. This helps narrow the problem to the right layer, such as a missing route, a blocked NSG rule, a missing ZPR policy, or a missing security attribute as shown below.

Kubernetes NetworkPolicy remains the pod-to-pod control inside the cluster within the same node. ZPR enforces network access policies in the OCI network fabric for supported OCI resources that have ZPR security attributes.

Plan The Rollout

The order matters. Write and test the required ZPR policies before applying attributes to existing resources. If a resource has ZPR security attributes and no suitable ZPR policy allows the required traffic, traffic to that endpoint is blocked even when NSG or security-list rules allow it.

1. Map the traffic paths that must keep working. Include administrator access to the Kubernetes API endpoint, node and pod traffic, service load balancers, ingress load balancers, and storage paths.
2. Create the required security attribute namespaces and security attributes.
3. Prepare IAM permissions for the users and OKE components that need to assign security attributes.
4. Write ZPR policies before applying attributes to existing resources.
5. Apply attributes to the narrow pilot scope.
6. Validate the expected paths with Network Path Analyzer where supported. Use it before rollout to check that required paths are allowed, and during troubleshooting to see whether routing, NSGs, security lists, ZPR policies, or security attributes are blocking the path.
7. Expand to more node pools, services, ingress paths, storage-backed workloads, and clusters after the pilot is stable.

Handle Transitional Policies

During migration, some destinations may not have ZPR security attributes yet. In those cases, a ZPR policy can allow traffic from attributed endpoints to a supported IP address, CIDR block, or service endpoint expression.

in network:backend-vcn VCN allow app:orders-api endpoints to connect to '10.0.2.5/32'

Keep transitional IP-based policies narrow. Remove them after the destination resource moves into the ZPR model and an attribute-based policy is in place. After validation, teams can also simplify broad transitional NSG or security-list rules when the remaining network configuration allows required connectivity and meets their security requirements.

Final Takeaway

OKE support for ZPR helps customers express approved communication paths for supported OCI resources used by Kubernetes clusters. Start with one mapped path, write the policy first, apply attributes carefully, and validate before expanding.

Getting started

• OCI Kubernetes Engine overview
• Adding Security Attributes to OKE Cluster-Related Resources and Applying ZPR Policies
• First Principles: Robust data breach protection with Zero Trust Packet Routing
• OCI Zero Trust Packet Routing overview
• OCI Zero Trust Packet Routing best practices