1. Documentation
×

Understanding network policy APIs

Network policy is defined using both cluster-scoped and namespace-scoped network policy APIs. By defining network policy across these different levels, you can create sophisticated network security configurations for your clusters, including full multi-tenant isolation.

Network policies and their scope

Cluster-scoped network policy

Cluster and network administrators can use the AdminNetworkPolicy to define network policy at the cluster level. The AdminNetworkPolicy feature consists of two APIs: the AdminNetworkPolicy API and BaselineAdminNetworkPolicy API. These APIs are used to set rules that can be applied to the entire cluster, or delegated to the namespace-scoped NetworkPolicy.

Policies defined using the AdminNetworkPolicy API take precedence over all other policy types when set to "Allow" or "Deny". However, administrators can also use "Pass" to delegate responsibility for a given policy to the namespace-scoped NetworkPolicy to allow application developers and namespace tenants to control specific aspects of network security for their projects.

Policies defined using the BaselineAdminNetworkPolicy API apply only when no other network policy overrides them. When you use the AdminNetworkPolicy API to delegate an aspect of network policy to the namespace-scoped NetworkPolicy, you should also define a sensible minimum restriction in the BaselineAdminNetworkPolicy. This ensures a baseline level of network security at the cluster level in case the NetworkPolicy for a namespace does not provide sufficient protection.

Namespace-scoped network policy

Application developers and namespace tenants can use the NetworkPolicy API to define network policy rules for a specific namespace. Rules in the NetworkPolicy for a namespace take precedence over cluster-wide rules configured using the BaselineAdminNetworkPolicy API, or for a cluster-wide rule that that has been delegated or "passed" from the cluster-wide AdminNetworkPolicy API.

How network policy is evaluated and applied

When a network connection is established, the network provider (default: OVN-Kubernetes) checks the connection details against network policy rules to determine how to handle the connection.

OVN-Kubernetes evaluates connections against network policy objects in the following order:

  1. Check for matches in the AdminNetworkPolicy tier.

    1. If a connection matches an Allow or Deny rule, follow that rule and stop evaluating.

    2. If a connection matches a Pass rule, move to the NetworkPolicy tier.

  2. Check for matches in the NetworkPolicy tier.

    1. If a connection matches a rule, follow that rule and stop evaluating.

    2. If no match is found, move to the BaselineAdminNetworkPolicy tier.

  3. Follow a matching rule in the BaselineAdminNetworkPolicy tier.

OVN-Kubernetes Access Control List (ACL)
Figure 1. Evaluation of network policies by OVN-Kubernetes

Key differences between AdminNetworkPolicy and NetworkPolicy custom resources

The following table explains key differences between the cluster scoped AdminNetworkPolicy API and the namespace scoped NetworkPolicy API.

Policy elements AdminNetworkPolicy NetworkPolicy

Applicable user

Cluster administrator or equivalent

Namespace owners

Scope

Cluster

Namespace

Drop traffic

Supported with an explicit Deny action set as a rule.

Supported via implicit Deny isolation at policy creation time.

Delegate traffic

Supported with an Pass action set as a rule.

Not applicable.

Allow traffic

Supported with an explicit Allow action set as a rule.

The default action for all rules is to allow.

Rule precedence within the policy

Depends on the order in which they appear within an ANP. The higher the rule’s position the higher the precedence.

Rules are additive.

Policy precedence

Among ANPs the priority field sets the order for evaluation. The lower the priority number higher the policy precedence.

There is no policy ordering between policies.

Feature precedence

Evaluated first via tier 1 ACL and BANP is evaluated last via tier 3 ACL.

Enforced after ANP and before BANP, they are evaluated in tier 2 of the ACL.

Matching pod selection

Can apply different rules across namespaces.

Can apply different rules across pods in single namespace.

Cluster egress traffic

Supported via nodes and networks peers

Supported through ipBlock field along with accepted CIDR syntax.

Cluster ingress traffic

Not supported.

Not supported.

Fully qualified domain names (FQDN) peer support

Not supported.

Not supported.

Namespace selectors

Supports advanced selection of Namespaces with the use of namespaces.matchLabels field.

Supports label based namespace selection with the use of namespaceSelector field.