Red Hat OpenShift Container Platform

Key differences between AdminNetworkPolicy and NetworkPolicy custom resources

To choose the right network policy API for your cluster or namespace in Red Hat OpenShift Container Platform, you can compare AdminNetworkPolicy and NetworkPolicy CRs across scope, rule actions, precedence, and peer options.

The following reference table highlights differences in who can apply policies, how traffic is allowed or denied, and how OVN-Kubernetes evaluates each API.

Policy elements AdminNetworkPolicy NetworkPolicy

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.

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.

Fully qualified domain names (FQDN) peer support

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.