Zero Trust Packet Routing Policy
A Zero Trust Packet Routing policy enforces access control based on the security attributes applied to resources involved in an access attempt.
A policy is a container for a set of policy statements. A policy statement is a rule that specifies who can access what resource, and how. Zero Trust Packet Routing (ZPR) policy is based on an Attribute Based Access Control (ABAC) authorization model that evaluates attributes (or characteristics) to determine access to resources. This approach is different than OCI IAM (see How ZPR Differs from IAM). ZPR policies are designed to achieve "attribute based access control" where the security attributes of source, target, and network are factored into the evaluation of policy using Zero Trust Packet Routing Policy Language (ZPL).
ZPL lets you write policy statements focused on allowing client endpoints with security attributes to access other endpoints.
ZPR policies don't take the place of setting up peering relationships between VCNs. For peering two VCNs in the same region, see Local VCN Peering using Local Peering Gateways or Local VCN Peering Through an Upgraded DRG. For peering two VCNs in different regions, see Remote VCN Peering through an Upgraded DRG.
ZPL supports the following types of allow statements in regards to communication to, from, and within individual VCNs identified by their security attributes:
- Allow traffic between two endpoints within a VCN
- Allow traffic between endpoints in different VCNs within the same region
For example, the following policy statement allows apps:hr-apps hosts to read any OCI resource with the apps:hr-app-data security attribute applied to them within the same VCN:
in networks:application VCN allow apps:hr-apps endpoints to connect to apps:hr-app-data endpoints
The following policy statement allows networks:net1:App1 endpoints in the networks:net1 VCN to connect to DB-Server:App1 endpoints in the networks:net2 VCN, when both VCNs are in the same region:
allow networks:net1:App1 endpoints in networks:net1 VCN to connect to DB-Server:App1 endpoints in networks:net2 VCN
To allow traffic between endpoints in different VCNs that aren't in the same region, or VCNs in the same region that don't have security attributes assigned to them, you must use CIDR or IP-based policy. For example, if you need to allow a client in networks:net1 VCN to access a Compute instance or database in another VCN in a different region, you need to use IP addresses to reference the targets in the other VCN:
in networks:net1 VCN allow apps:app1 endpoints to connect to '192.168.0.0/16'
To create ZPR policies, you must first create security attributes. Security attributes are factored into the evaluation of ZPR policy. After you create security attributes, review ZPR policy syntax, then examine the options for creating a policy with policy builders. You can also learn about ZPR policies from examples.
You must add security attributes to OCI resources for ZPR policy to take effect.
After you create security attributes and ZPR policies, you can add the security attributes to resources.
See Resources That Can Be Assigned Security Attributes for the types of resources you can use in ZPR policies.