In the last entry I tried to explain how Zero Trust Packet Routing (ZPR) contrasted with Security Lists (SCL) and Network Security Groups (NSG). In this entry, I wanted to take a closer look at ZPR and what is required to implement in an OCI tenancy. That encompasses the IAM policies required, ZPR required components and how security attributes are assigned.

The documentation tells us that at a minimum, a customer must have read permission to compute instances. They must also have read access to database resources and the ability to inspect workload requests. I think this is a perfect time for a quick review of OCI IAM policy inspect and read permissions.  Inspect permissions grant the ability to list OCI resources, without access to any confidential information or user-specified metadata that might be part of that resource. Read permission provides a group Inspect permissions and adds the ability to get user-specified metadata and the actual resource itself.

What is the metadata for an instance? The instance metadata service (IMDS) provides information about a running instance, including a variety of details about the instance, its attached virtual network interface cards (VNICs), its attached multipath-enabled volume attachments, and any custom metadata that you define. IMDS also provides information to cloud-init that you can use for various system initialization tasks.

If I want ZPR to be implemented for network resources like load balancers, I personally want to manage that access in the least number of policies and permissions possible. We know that the Read permission does not grant authorization to update, delete or create resources. We can safely assume the ZPR admin is a team member who can have access to see the VNIC information of deployed resources. Therefore, granting them read access to the tenancy would cover any existing or future resources without having to revisit policies as compartments and resources are added to the tenancy. An example policy statement would be Allow group ZPR_Admin_Group to read all-resources in tenancy.

In addition, the ZPR admin group would also need to be able to manage security attributes and policies.

Allow group SecurityAdmins to manage zpr-security-attribute in tenancy

Allow group SecurityAdmins to manage zpr-policy in tenancy

There are three main components to ZPR:

1. Security Attribute Namespace – a container for a set of security attributes. Security attribute namespaces let you logically organize and secure security attributes.

2. Security Attributes – can be a static attribute where a string value is provided when assigned to a resource or a pre-defined list of string values that can be chosen from when assigning to a resource.

3. ZPR Policy – enforces access control based on the security attributes that are applied to the resources involved in an access attempt.

ZPR allows, via IAM policy, for any group (app, dba, etc) to manage ZPR security attributes. With IAM policy we can specify which namespace a group is allowed to manage. How many ZPR namespaces are created for segmentation of attributes is up to the customer. As an example, we could create an application namespace and a database namespace. Using OCI IAM policy, we can then segment the management of those namespaces to the specific groups (app group to application namespace and DBA group to database namespace).

Here is where I think the implementation of ZPR becomes unique per customer. If a customer wants rigid oversight of the ZPR attributes and policies, then the creation and maintenance of those attributes will be maintained by one group. How many namespaces to be created will vary. The important part would be that the centralized ZPR management team would manage the following:

• Security Attribute namespace/s – (could be one or many)
• Security Attributes in the namespace/s
• Assignment of the Security Attributes to OCI resources
• Creation and maintenance of the ZPR policies

Some of the key considerations while implementing ZPR include the following:

• Naming standards – develop standardized security attribute names and values. Make the attribute names and values understandable for the team creating the ZPR policies
• Assignment of Security Attributes – What group has access to assign the security attributes? As an example, if the application owners assign the Security Attributes and values, they will need to be locked down to their compartments and resources via IAM policy. This could mean more IAM policies to manage within the OCI tenancy.
• Security Attribute Value Type – How are standardized and meaningful Security Attribute values being assigned? If the application owners manage the Security Attributes, is there a standardized value added when the security attribute is assigned to an OCI resource? This is where the pre-defined attribute values (dropdown lists), could be of value.
• ZPR Policy Management – We do not want ZPR policy created that breaks the application. If application owners are allowed to assign Security Attributes to resources, how does the ZPR policy management team know the intent behind the assigned security attributes?

As ZPR is intended to enhance the security of protected data, in my opinion, centralized management with detailed designs coming out of planning sessions with security, network and application owners would be my recommended approach. De-centralizing the security attribute management has the potential to create operational overhead (clarifying questions, re-work, etc) and risk (creating a policy that breaks an application as the policy conflicts with an existing SCL or NSG rule or leveraging a security attribute incorrectly within the policy statement). We need the security teams, network teams and application owners to be in lock step to ensure security protocols are being implemented without breaking the functionality of the applications.