AdminNetworkPolicy API for OpenShift cluster security

Here in this blog, we will learn about AdminNetworkPolicy API for Openshift cluster security.

ANP stands for admin network policy and AdminNetworkPolicy Baseline (BANP)?

Installed on a TechPreviewNoUpgrade OpenShift cluster, the AdminNetworkPolicy and BaselineAdminNetworkPolicy APIs are cluster scoped Custom Resource Definitions (CRDs) supplied as out-of-tree Kubernetes APIs by the sig-network-policy-api working group as of OCP 4.14. To secure the network traffic in your cluster, you can use both of these APIs to define admin policies that apply to the entire cluster. Only intra-cluster use cases are supported by the v1alpha1 version of these APIs at this time.

The upstream community is working on new features like support for FQDN, easier and more accurate tenancy expressions, and cluster egress traffic controls. This feature is only available on TechPreviewNoUpgrade clusters because these APIs may change in future versions, and policies created in 4.14 may not work in later releases.

Network Policy API Integration

Within a cluster, ANP and BANP are intended to work in tandem and complement the Network Policy API. On a cluster, the Admin Network Policies are the ones with the highest priority. They are implemented using the tiered Access Control Lists (ACLs) of OVN in OVN-Kubernetes.

The rules in that ANP will be assessed first if the traffic matches it. Any existing Network Policies and Baseline Admin Network Policy in the cluster will be purposefully excluded from evaluation if the match was on an ANP allow or deny rule. Evaluation will move from Admin Network Policies to Network Policies if the match was on an ANP pass rule or if no matching ANPs were found. Any Baseline Admin Network Policy that is currently in the cluster will be purposefully excluded from evaluation if a Network Policy matches the traffic. We evaluate the baseline admin network policy first if no matching Network Policies are found. That becomes effective if a matching BANP is discovered. ANPs match tier 1 ACLs in OVN-Kubernetes, NPs match tier 2 ACLs, and BANP matches tier 3 ACLs.

API for Admin Network Policy

A resource called AdminNetworkPolicy enables users to specify.

1. A subject chosen by the policy that consists of a number of pods
2. A set of ingress regulations that must be followed for all traffic entering the topic. Every influx rule includes the following:

1. • a list of peer pods from which we can identify the origin of the incoming traffic at L3.
   • a list of ports on the topic pods that correspond to the ingress traffic’s destination ports at L4.
   • One of three possible actions to take in relation to the matched incoming traffic is allow, deny, or pass.

4. a set of exit regulations that must be followed for every exit from the subject. Each egress guideline includes:
5. • a list of peer pods that enables us to match egress traffic at L3 on its destination
   • A list of ports on the peer pods that correspond to the ports at which the egress traffic at L4 ends up
   • One of three possible actions to take regarding the matched egress traffic: allow, deny, or pass.
6. A priority number that determines this AdminNetworkPolicy’s order of precedence among the cluster’s other AdminNetworkPolicies: The precedence increases with decreasing value.

The AdminNetworkPolicy mentioned above, which is defined at priority 9, guarantees that all incoming traffic from the monitoring namespace to any tenant (i.e., all namespaces) within the cluster is permitted. This is an illustration of a strong ALLOW that none of the parties can override. Using NetworkPolicies, none of the tenants can prevent themselves from being watched, and the tenant doing the monitoring has no control over what it can and cannot watch.

All incoming traffic from monitoring namespaces towards restricted tenants (namespaces with the security label “restricted”) is prevented by the AdminNetworkPolicy mentioned above, which is defined at priority 5. This is an illustration of a forceful DENY that cannot be overridden by any of the parties. Even if they so choose, the owners of restricted tenants are unable to permit monitoring traffic, and the infrastructure’s monitoring service is unable to scrape data from these private namespaces. Block monitoring takes precedence over allow monitoring because the former has a lower priority value and guarantees that restricted tenants are never monitored.

The AdminNetworkPolicy mentioned above, which is defined at priority 7, makes sure that all incoming traffic from the monitoring namespace to internal infrastructure tenants (namespaces with the label security: internal) is routed to the NetworkPolicies of those namespaces for evaluation. This is an illustration of a strong PASS action that AdminNetworkPolicies use to assign the choice to tenant-defined NetworkPolicies. Pass-monitoring ANP takes precedence over allow-monitoring ANP due to its lower priority value. This means that all tenant owners grouped at security level internal will have the choice of whether or not the infrastructure’s monitoring service uses namespace scoped NetworkPolicies to scrape their metrics.

An example of what appears on OpenShift when you list AdminNetworkPolicies:

NOTE: Since the decision of which AdminNetworkPolicy takes precedence is non-deterministic, it is not advised to create two of them at the same priority. We only support priority values ranging from 0 to 99 at this time. For more details, consult the developer documentation.

API for BaselineAdminNetworkPolicy

Using a BaselineAdminNetworkPolicy resource, users can indicate:

1. A subject chosen by the policy that consists of a number of pod
2. a set of ingress regulations that must be followed for all traffic entering the topic. Every influx rule includes the following:

• • Peer pods’ list, which enables us to match the source of the incoming traffic at L3
  • A list of ports on the topic pods that correspond to the ingress traffic’s destination ports at L4
  • An action to take in relation to the matched incoming traffic; it cannot pass; it can only be allow or denied.

3. a set of egress guidelines that must be followed for every egress from the topic. Every egress rule includes:

• • A list of peer pods that enables us to match the egress traffic’s destination at L3
  • A list of ports on the peer pods that correspond to the L4 exit traffic’s destination ports
  • An action to be taken on the corresponding outgoing traffic; it cannot pass; it can only be allow or denied.

A cluster singleton object, the BaselineAdminNetworkPolicy resource primarily serves as the default catch-all guardrail policy in the event that a passed packet does not match any NetworkPolicies in the cluster. When creating a BaselineAdminNetworkPolicy object, the name must be default.

An example of YAML

The aforementioned BaselineAdminNetworkPolicy singleton makes sure that, at the internal security level, the admin has configured default deny guardrails for all ingress monitoring traffic entering the tenants. For all traffic that is passed by the pass-monitoring admin network policy, this serves as the catch-all policy.

Assume foo and bar, our two tenants, are both designated with the label security: internal. Tenant foo desires to collect application monitoring data. The NetworkPolicy that the tenant owner defines can look something like this:

The above NetworkPolicy, which implicitly denies all ingress and explicitly allows only ingress coming from the monitoring namespace, will be matched for the tenant foo if the traffic is intended for them after the pass-monitoring ANP matches and delegates traffic to the NetworkPolicy layer, meeting the tenant’s requirements. The monitoring of internal tenants would have been prohibited by the BANP if this NetworkPolicy hadn’t been in place.

Since the tenant bar hasn’t created any NetworkPolicies, no match will be found at the NP layer if the traffic is intended for the tenant bar after the pass-monitoring ANP matches and delegates traffic to the NetworkPolicy layer. Next, we will assess the aforementioned BANP, which expressly forbids the tenant bar from being observed. The administrator’s request to not automatically monitor the internal tenants is satisfied by this.

Example output from OpenShift’s listing of BaselineAdminNetworkPolices:

NOTE: Verify that the AdminNetworkPolicy was created correctly by looking at the status field of the CRD, which displays the status that the OVNKubernetes zone controller of each node reported.

An example of the output