OCI has made zero trust packet routing (ZPR) generally available. There was quite a bit of buzz around the new feature during Oracle Cloud World. In conversation with some of my colleagues, there seemed to be a lack of consensus on what exactly the new feature is and what it can do. Now that I have had an opportunity to look into the new feature for the past few days, I think it would be a good idea to do a multi-part blog on ZPR. First part being what ZPR is. Second part being a deeper dive into the components of ZPR. The third entry being a look at use cases for ZPR.

So, what is ZPR? Zero Trust Packet Routing is a concept that Applied Invention brought to the attention of Oracle and the organizations committed to work together on compatibility and on an open standard with an open-source reference implementation. This means ZPR is an industry first technology solution, currently only available on one cloud service provider…OCI.

One misconception I would like to put to rest is that ZPR does NOT have to replace OCI Security Lists (SCL) or Network Security Groups (NSG). ZPR is built on top of existing NSG and SCL rules. For a packet to reach a target, it must pass all NSG and SCL rules, and ZPR policy. If any NSG, SCL, or ZPR rule or policy doesn’t allow traffic, the request is dropped. When ZPR is enabled in the tenancy, OCI clearly calls out the fact that it will not alter any current NSG or SCL rules in place.

When creating a VCN within OCI a default SCL is automatically created. Customers can choose to use the default SCL when creating subnets or create their own SCL’s. At least one SCL is required for a VCN subnet. Customers can choose to remove the SCL rules from the assigned SCL, but they must have at least one SCL attached to a subnet. SCL’s applied the defined security rules to the entire subnet (i.e. if port 1521 was opened to the subnet SCL, that rule applied to every instance deployed within the subnet).

NSG’s were added to OCI long after SCL’s. NSG’s allowed network admin’s to group virtual NIC’s (VNIC’s) together and apply network security rules at a VNIC level rather than subnet wide. NSG’s offered more granular control and allowed network admins to group application VNIC’s together (i.e. web tier, application tier and db tier VNIC’s) and apply network rules specific to the application stack even if the stack spanned multiple subnets. They just have to be in the same VCN.

The diagram below shows how SCL and NSG can be leveraged together to implement network security controls for Services such as anti-virus and anti-malware (AV/AM), domain controllers (DNS), vulernability scanners, etc to be allowed to access application and database subnets while NSG’s are implemented to implement application stack network controls (traffic between application tiers). It is important to note that while NSG is a grouping of VNIC’s, the NSG assignment is done at the parent component layer (i.e. I have to assign a compute resource to an NSG from the compute resource, I cannot just add the VNIC directly to the NSG)

ZPR allows us to now use security attributes (much like tags) to apply policy based rules that would sit on top of SCL and NSG or in some cases replace SCL rules or NSG rules (to simplify the management of traffic security). I would like to add a caveat here, my example below is a simple one to illustrate how ZPR could easily be added to an existing VCN. In the next blog entry on ZPR, we will look at how ZPR is not limited to resources in a VCN like SCL and NSG. ZPR also allows admins to drill down from the ZPR menu in the console to assign attributes to resources (easier than having to navigate to parent resources for management of NSG’s).

Assuming we set a ZPR security attribute on the VCN, on the VNIC’s of the services compute instances and on the VNIC’s of the application instances, we can then apply a ZPR policy that would allow the services VNIC’s to communicate with the application VNIC’s. We can start with a simple policy and get granular by adding ports and protocols if needed.

in VCN:SingleVCN VCN allow ‘Services:Domain Controller’ endpoints to connect to App1:App1 endpoints

The above statement uses the value from VCN to ensure we are evaluating the traffic for the VCN SingleVCN. The policy statement will allow the VNIC’s I have assigned the Services attribute with the value of Domain Controller to communicate with the endpoints assigned the security attribute App1 with a value of App1. In this example, I have defined the security attribute Services with a list of values to be chosen when assigned to a VNIC: AV/AM, Domain Controller and Vulnerability Scanner. Additionally, we could specify the protocol and port for the trusted traffic for more granularity

in VCN:SingleVCN VCN allow ‘Services:Domain Controller’ endpoints to connect to App1:App1 endpoints with protocol=’tcp/53′

Hopefully, this simple example demonstrates the difference between OCI security lists, network security groups and the new zero trust packet routing. I will look to do a deeper dive on ZPR int he next blog entry.