OCI Zero Trust Packet Routing FAQ
General
What is OCI Zero Trust Packet Routing?
OCI Zero Trust Packet Routing prevents unauthorized access to data by separating network security from the underlying network architecture. OCI Zero Trust Packet Routing policies utilize intent-based and human-readable language, making them easy to audit, understand, and manage. These policies enable security administrators to define precise data access pathways, helping ensure that only explicitly permitted traffic can traverse the network. By adopting OCI Zero Trust Packet Routing, organizations can significantly enhance their security postures while simplifying administration and compliance management.
How do I use OCI Zero Trust Packet Routing?
OCI Zero Trust Packet Routing is available by default within your tenancy and can be accessed from the web console. The steps for enabling OCI Zero Trust Packet Routing for the first time are as follows:
- From the top-level menu, select Identity & Security > Zero Trust Packet Routing.
- Click the "Enable Zero Trust Packet Routing" button.
How much does OCI Zero Trust Packet Routing cost?
OCI Zero Trust Packet Routing is offered at no additional cost for OCI configuration and OCI activity across supported OCI services. This means you can leverage OCI Zero Trust Packet Routing's robust security features without incurring extra charges, making it an accessible and cost-effective solution for enhancing your cloud security.
Is OCI Zero Trust Packet Routing a regional or global service?
OCI Zero Trust Packet Routing is implemented regionally.
Which regions are enabled?
Tenancies are enabled for OCI Zero Trust Packet Routing for all commercial regions. Please consult our list of currently supported regions.
What is a security attribute namespace?
A security attribute namespace is a container for security attributes that helps organize and manage sensitive resources. A namespace will have IAM policy written against it to define which groups of OCI administrators have access.
When you enable Zero Trust Packet Routing, it creates a security attribute namespace in your tenancy called “Oracle-Zero Trust Packet Routing” that includes an example security attribute labeled “Sensitivity.” If you omit the security attribute namespace of a security attribute when writing policy, Zero Trust Packet Routing will default to the Oracle-Zero Trust Packet Routing security attribute namespace.
How does adding or removing OCI Zero Trust Packet Routing policies impact existing networking and security configurations (NSGs/routing tables)?
OCI Zero Trust Packet Routing policies are evaluated in addition to network security groups (NSGs) and security lists. Traffic is first evaluated against existing NSG rules, then by OCI Zero Trust Packet Routing policies. This helps ensure that only traffic that meets both the network security rules and the OCI Zero Trust Packet Routing policies is permitted.
By contrast, removing OCI Zero Trust Packet Routing policies can reduce the efficacy of this layered security approach, as traffic is solely governed by the NSG and security lists. While the foundational security remains intact, the absence of OCI Zero Trust Packet Routing policies may expose the network to risks that would previously have been mitigated by these additional rules. Therefore, any changes to OCI Zero Trust Packet Routing policies should be carefully managed to keep the overall security framework aligned with the organization's security requirements.
What is the scope of OCI Zero Trust Packet Routing policies?
OCI Zero Trust Packet Routing policies reside in the root compartment of the tenancy and apply to the entire tenancy.
Purpose and scope
What problem is OCI Zero Trust Packet Routing trying to solve?
OCI Zero Trust Packet Routing removes the tight coupling between network security and IP/routing constructs. It lets customers express security intent using security attributes so access controls remain stable as networks evolve, IPs change, or routing changes.
Is OCI Zero Trust Packet Routing virtual cloud network–centric or interservice focused?
OCI Zero Trust Packet Routing is virtual cloud network–centric today. It started with enforcement within a single virtual cloud network and is expanding to cross–virtual cloud network enforcement within the same tenancy and region.
Enforcement and architecture
Where does OCI Zero Trust Packet Routing enforcement occur?
Enforcement happens at the virtual network interface card, at Layer 4. OCI Zero Trust Packet Routing is implemented using NSGs and evaluated at the same network layer.
How does OCI Zero Trust Packet Routing identify the source and destination?
OCI Zero Packet Routing uses a unique identifier (UID) representing the source and destination endpoints. This isn’t tied to users or applications.
Is the UID evaluated per packet or per connection?
OCI Zero Trust Packet Routing is stateful by default. The UID is associated with a connection (flow), not evaluated independently for each packet.
Do all packets in a connection share the same UID?
Yes. All packets belonging to the same flow share the same UID.
If there are multiple identical TCP connections, are they treated separately?
No. Identical source, destination, protocol, and port combinations are treated as a single flow.
Does OCI Zero Trust Packet Routing perform deep packet inspection or application-layer inspection?
No. OCI Zero Trust Packet Routing evaluates only L4 attributes: source, destination, protocol, and port.
Which protocols does OCI Zero Trust Packet Routing support?
TCP and UDP.
Does OCI Zero Trust Packet Routing understand users, processes, or applications?
No. OCI Zero Trust Packet Routing operates at the endpoint/host level and doesn’t have user, process, or application awareness.
Policy semantics
What is the syntax for communication within a single VCN?
For communication between workloads inside the same VCN, policies must explicitly specify the VCN security attribute context along with source and destination security attributes. This helps ensure enforcement is scoped correctly and avoids ambiguity when attributes may exist across multiple VCNs.
Syntax
In
<VCN security attribute>
VCN allow
<source attribute>
endpoints to connect to
<destination attribute>
endpoints
Examples
In SA_BACKEND_VCN VCN allow SA_WEB_FRONTEND endpoints to connect to SA_APP_BACKEND endpoints
In SA_BACKEND_VCN VCN allow SA_APP_BACKEND endpoints to connect to SA_DB_TIER endpoints
What syntax should be used for communication across VCNs?
When traffic crosses VCN boundaries, both source and destination VCN contexts must be specified so the policy engine evaluates the correct trust domains.
Syntax
Allow
<source attribute>
endpoints in
<source VCN attribute>
VCN to connect to
<destination attribute>
endpoints in
<destination VCN attribute>
VCN
Examples
Allow SA_WEB_FRONTEND endpoints in SA_FRONTEND_VCN VCN to connect to SA_APP_BACKEND endpoints in SA_BACKEND_VCN VCN
Allow SA_APP_BACKEND endpoints in SA_BACKEND_VCN VCN to connect to SA_DB_TIER endpoints in SA_DATABASE_VCN VCN
How do policies work between tagged and untagged resources?
During phased onboarding, some workloads may not yet support security attributes. OCI Zero Trust Packet Routing supports temporary policies allowing communication between resources that support security attributes and untagged endpoints using IP-based targets.
Syntax
In
<VCN security attribute>
VCN allow
<source attribute>
endpoints to connect to
<IP address>
Examples
In SA_BACKEND_VCN VCN allow SA_APP_BACKEND endpoints to connect to 10.10.0.15
In SA_FRONTEND_VCN VCN allow SA_WEB_FRONTEND endpoints to connect to 10.10.1.25
Can ports and protocols be restricted?
Yes. Policies can explicitly specify TCP/UDP and numeric ports, and specifying both is recommended.
Can ports or protocols be specified using service names like SSH?
No. Policies require explicit protocol names and numeric port values.
Security attributes
What is a security attribute?
A logical label assigned to resources that defines trust grouping and routing permissions.
Are security attributes just OCI tags?
No. They’re built on top of tagging infrastructure but are separate first-class objects with a distinct model.
Which resources support security attributes today?
Compute instances, load balancers, databases, private endpoints, OCI Private Service Access endpoints, and more.
Trust boundary and external access
What is the OCI Zero Trust Packet Routing trust boundary?
It includes all resources that can be assigned security attributes. Attribute-to-attribute communication is the preferred model within this boundary.
How does OCI Zero Trust Packet Routing handle communication outside the trust boundary?
OCI Zero Trust Packet Routing supports attribute-to-IP/CIDR rules for internet access, on-premises connectivity, and services not yet enabled by OCI Zero Trust Packet Routing.
Does OCI Zero Trust Packet Routing support cross-region or cross-tenancy enforcement?
No. Cross-region and cross-tenancy enforcement are under consideration but not available today.
Comparison to existing controls
Can OCI Zero Trust Packet Routing do anything that host-based firewalls can’t?
Functionally, no. Host-based firewalls can replicate the behavior, but OCI Zero Trust Packet Routing significantly helps reduce complexity, misconfiguration risk, and operational overhead.
If object storage is accessed through a public endpoint instead of OCI Private Service Access, will OCI Zero Trust Packet Routing block it?
No. OCI Zero Trust Packet Routing alone won’t block it. An IAM deny policy is required to enforce OCI Private Service Access–only access.
Troubleshooting and validation
What are the ways to validate whether resources are communicating or not communicating due to security attributes and corresponding OCI Zero Trust Packet Routing policies?
Connectivity validation can be performed using OCI Network Path Analyzer, which evaluates all enforcement layers affecting traffic between two resources. This analysis determines whether communication is allowed or blocked and identifies the specific control responsible for the decision.
How can you run the analysis?
You can initiate path analysis using either of the following methods:
- Navigate to OCI Network Path Analyzer and select the source and destination resources to evaluate connectivity.
- Within the OCI Zero Trust Packet Routing console, go to Protected Resources, then select the relevant resource from the Actions menu for path analysis.
What do validation checks include?
- Whether NSG or security list rules block traffic
- Whether OCI Zero Trust Packet Routing policies allow or deny the flow and policy details
- Whether routing rules prevent reachability
- Whether security attributes on endpoints match policy conditions
What does the analysis show?
The analysis output provides a consolidated decision explaining
- Allowed path or blocked path due to OCI Zero Trust Packet Routing, NSGs or security lists, and underlying routing rules
- OCI Zero Trust Packet Routing policies and security attributes causing the outcome