kubernetes-sigs · k8s-ci-robot · Nov 7, 2025 · Oct 13, 2025 · Nov 5, 2025 · Dyanngg
diff --git a/mkdocs.yml b/mkdocs.yml
@@ -17,6 +17,7 @@ theme:
     - search.highlight
     - navigation.tabs
     - navigation.top
+    - content.code.copy
 edit_uri: edit/master/site-src/
 plugins:
   - search

diff --git a/site-src/api-overview.md b/site-src/api-overview.md
@@ -1,16 +1,15 @@
-# Api Object Overview
+# API Object Overview
 
 Prior to the Network Policy API the original NetworkPolicy V1 Resource was the only
 way for k8s users to apply security rules to their kubernetes workloads. One of the
 main drawbacks to this API was that it was designed exclusively for use by the
 Application Developer, although in reality it is used by many different cluster
 personas, sometimes creating a complex web of objects to be maintained. In
-Contrast, each resource in the Network Policy API is designed to be used by a
+contrast, each resource in the Network Policy API is designed to be used by a
 specific persona.
 
-With the advent of the AdminNetworkPolicy and BaselineAdminNetworkPolicy
-resources Cluster Admins will now have the ability to apply policy globally with
-only a few simple policy objects.
+With the advent of the ClusterNetworkPolicy resource Cluster Admins will now have 
+the ability to apply policy globally with only a few simple policy objects.
 
 ## Roles and personas
 
@@ -27,116 +26,108 @@ In this documentation we refer to three primary personas:
     Custom Resource Definitions (CRDs). Unqualified resource names below will
     implicitly be in this API group.
 
-Currently, there are two main objects in the Network Policy API resource model:
+Currently, there is one main object in the Network Policy API resource model:
 
-- **AdminNetworkPolicy (ANP)**
-
-- **BaselineAdminNetworkPolicy (BANP)**
+- **ClusterNetworkPolicy (CNP)**
 
 The diagram below demonstrates how these new API objects interact with
 each-other and existing NetworkPolicy Objects:
 
-![Alt text](./images/ANP-api-model.png?raw=true "Admin Network Policy API Model")
+<img src="/images/CNP.drawio.svg" width="541" alt="Cluster Network Policy API model">
 
 ## General Notes
 
-- Any well defined AdminNetworkPolicy rules should
+- Any well-defined ClusterNetworkPolicy rules should
 be read as-is, i.e. there will not be any implicit isolation effects for the Pods
-selected by the AdminNetworkPolicy, as opposed to what NetworkPolicy rules imply.
+selected by the ClusterNetworkPolicy, as opposed to what NetworkPolicy rules imply.
+
+- We now have multiple API versions, see the [ClusterNetworkPolicy blog post](blog/posts/ClusterNetworkPolicy.md) for more details
+
+## The ClusterNetworkPolicy Resource
 
-- As of `v1alpha1` of this API we focus primarily on E/W cluster traffic and
-do not address N/S (Ingress/Egress) use cases. However this is an issue the community
-would like to keep thinking about during further iterations, and a tracking issue
-can be found/ commented on here ---> [issue #28](https://github.com/kubernetes-sigs/network-policy-api/issues/28)
+The ClusterNetworkPolicy (CNP) resource will help administrators set cluster-wide security
+rules for the cluster, which are evaluated before or after the NetworkPolicies defined by the
+namespace owners.
 
-## The AdminNetworkPolicy Resource
+### Tiers
 
-The AdminNetworkPolicy (ANP) resource will help administrators set strict security
-rules for the cluster, i.e. a developer CANNOT override these rules by creating
-NetworkPolicies that apply to the same workloads as the AdminNetworkPolicy.
+Tier is used as the top-level grouping for network policy prioritization.
 
-### AdminNetworkPolicy Actions
+Policy tiers are evaluated in the following order:
+* `Admin` tier
+* NetworkPolicy tier
+* `Baseline` tier
+
+ClusterNetworkPolicy can use 2 of these tiers: `Admin` and `Baseline`.
+
+The `Admin` tier will help administrators set strict security rules for the cluster, 
+i.e. a developer CANNOT override these rules by creating NetworkPolicies that apply 
+to the same workloads as the ClusterNetworkPolicy.
+
+The `Baseline` tier will allow administrators to set baseline security rules that 
+describe default connectivity for cluster workloads, which CAN be overridden by 
+developer NetworkPolicies if needed. 
+The major use case for `Baseline` tier is the ability to flip the [default security stance of the
+cluster](user-stories.md#story-5-cluster-wide-default-guardrails).
+
+### Actions
 
 Unlike the NetworkPolicy resource in which each rule represents an allowed
-traffic, AdminNetworkPolicies will enable administrators to set `Pass`,
-`Deny` or `Allow` as the action of each rule. AdminNetworkPolicy rules should
+traffic, ClusterNetworkPolicy will enable administrators to set `Pass`,
+`Deny` or `Accept` as the action of each rule. ClusterNetworkPolicy rules should
 be read as-is, i.e. there will not be any implicit isolation effects for the Pods
-selected by the AdminNetworkPolicy, as opposed to implicit deny NetworkPolicy rules imply.
-
-- **Pass**: Traffic that matches a `Pass` rule will skip all further rules from all
-  numbered ANPs and instead be enforced by the K8s NetworkPolicies.
-  If there is no K8s NetworkPolicy of BaselineAdminNetworkPolicy rule match
-  traffic will be governed by the implementation. For most implementations,
-  this means "allow", but there may be implementations which have their own policies 
-  outside of the standard Kubernetes APIs.
-- **Deny**: Traffic that matches a `Deny` rule will be dropped.
-- **Allow**: Traffic that matches an `Allow` rule will be allowed.
-
-AdminNetworkPolicy `Deny` rules are useful for administrators to explicitly
+selected by the ClusterNetworkPolicy, as opposed to implicit deny NetworkPolicy rules imply.
+
+- **Accept**: Accepts the selected traffic, allowing it into
+  the destination. No further ClusterNetworkPolicy or
+  NetworkPolicy rules will be processed.
+
+- **Deny**: Drops the selected traffic. No further
+  ClusterNetworkPolicy or NetworkPolicy rules will be
+  processed.
+
+- **Pass**: Skips all further ClusterNetworkPolicy rules in the
+  current tier for the selected traffic, and passes
+  evaluation to the next tier.
+
+ClusterNetworkPolicy `Deny` rules are useful for administrators to explicitly
 block traffic with malicious in-cluster clients, or workloads that pose security risks.
 Those traffic restrictions can only be lifted once the `Deny` rules are deleted,
 modified by the admin, or overridden by a higher priority rule.
 
-On the other hand, the `Allow` rules can be used to call out traffic in the cluster
+On the other hand, the `Accept` rules can be used to call out traffic in the cluster
 that needs to be allowed for certain components to work as expected (egress to
 CoreDNS for example). This traffic should not be blocked when developers apply
 NetworkPolicy to their Namespaces which isolates the workloads.
 
-AdminNetworkPolicy `Pass` rules allow an admin to delegate security posture for
+ClusterNetworkPolicy `Pass` rules in the `Admin` tier allow an admin to delegate security posture for
 certain traffic to the Namespace owners by overriding any lower precedence Allow
-or Deny rules. For example, intra-tenant traffic management can be delegated to tenant
-admins explicitly with the use of `Pass` rules. More specifically traffic selected 
-by a `Pass` rule will skip any further ANP rule selection, be evaluated against
-any well defined NetworkPolicies, and if not terminated ultimately be evaluated against any 
-BaselineAdminNetworkPolicies. 
+or Deny rules. For example, intra-namespace traffic management can be delegated to namespace
+admins explicitly with the use of `Pass` rules. More specifically traffic selected by a `Pass` rule
+will skip any lower precedence `Admin` tier rules and proceed to be evaluated by `NetworkPolicy` and
+`Baseline` tier policies. When the `Pass` action is matched at the `Admin` tier, `NetworkPolicy` will 
+apply next or if there is no `NetworkPolicy` match, `Baseline` policies will be evaluated.
 
-### AdminNetworkPolicy Priorities 
+### Priorities 
 
-Integer priority values were added to the AdminNetworkPolicy API to allow Cluster 
-Admins to express direct and intentional ordering between various ANP Objects.  
-The `Priority` field in the ANP spec is defined as an integer value 
-within the range 0 to 1000 where rules with lower priority values have higher 
-precedence. Regardless of priority value all ANPs have higher precedence than 
-any defined NetworkPolicy or BaselineAdminNetworkPolicy objects.
+Integer priority values were added to the ClusterNetworkPolicy API to allow Cluster 
+Admins to express direct and intentional ordering between various CNP Objects.  
+The `Priority` field in the CNP spec is defined as a non-negative integer value 
+where rules with lower priority values have higher precedence, and are checked 
+before policies with higher priority values in the same tier.
 
-### AdminNetworkPolicy Rules 
+### Rules 
 
-Each ANP should define at least one `Ingress` or `Egress` relevant in-cluster traffic flow 
+Each CNP should define at least one `Ingress` or `Egress` relevant in-cluster traffic flow 
 along with the associated Action that should occur. In each `gress` rule the user 
-should AT THE MINIMUM define an `Action`, and at least one `AdminNetworkPolicyPeer`.
+should AT THE MINIMUM define an `Action`, and at least one `ClusterNetworkPolicyPeer`.
 Optionally the user may also define select `Ports` to filter traffic on and also 
 a name for each rule to make management and reporting easier for Admins.
 
-### AdminNetworkPolicy Status 
+### Status 
 
-For `v1alpha1` of this API the ANP status field is simply defined as a list of 
+For `v1alpha2` of this API the ANP status field is simply defined as a list of 
 [`metav1.condition`](https://github.com/kubernetes/apimachinery/blob/v0.25.0/pkg/apis/meta/v1/types.go#L1464)s. Currently there are no rules as to what these conditions should display,
 and it is up to each implementation to report what they see fit. For further 
 API iterations the community may consider standardizing these conditions based on 
 the usefulness they provide for various implementors.
-
-## The BaselineAdminNetworkPolicy Resource 
-
-The BaselineAdminNetworkPolicy (BANP) resource will allow administrators to 
-set baseline security rules that describes default connectivity for cluster workloads, 
-which CAN be overridden by developer NetworkPolicies if needed. The major use case 
-BANPs solve is the ability to flip the [default security stance of the 
-cluster](user-stories.md#story-5-cluster-wide-default-guardrails).
-
-### BaselineAdminNetworkPolicy Rule Actions 
-
-BaselineAdminNetworkPolicies allow administrators to define two distinct actions
-for each well defined rule, `Allow` and `Deny`. 
-
-- **Deny**: Traffic that matches a `Deny` rule will be dropped.
-- **Allow**: Traffic that matches an `Allow` rule will be allowed.
-
-### BaselineAdminNetworkPolicy Rules 
-
-BANP Rules are defined and behave the same (Except for the `Pass` action) as [ANP 
-rules](#adminnetworkpolicy-rules).
-
-### BaselineAdminNetworkPolicy Status
-
-The BANP `status` field follows the same constructs as used by the
-[AdminNetworkPolicy.Status](#adminnetworkpolicy-status) field.
diff --git a/site-src/blog/.authors.yml b/site-src/blog/.authors.yml
@@ -7,3 +7,7 @@ authors:
     name: Yang Ding
     description: Senior Member of Technical Staff at VMware. network-policy-api co-lead.
     avatar: https://github.com/dyanngg.png  
+  npinaeva:
+    name: Nadia Pinaeva
+    description: Software Engineer
+    avatar: https://github.com/npinaeva.png
diff --git a/site-src/blog/posts/ClusterNetworkPolicy.md b/site-src/blog/posts/ClusterNetworkPolicy.md
@@ -0,0 +1,105 @@
+---
+date: 2025-10-09
+authors:
+  - npinaeva
+---
+
+# API update for v1alpha2: `ClusterNetworkPolicy` replaces `AdminNetworkPolicy` and `BaselineAdminNetworkPolicy`
+
+We have merged `v1alpha1.AdminNetworkPolicy` and `v1alpha1.BaselineAdminNetworkPolicy` into a single API in `v1alpha2.ClusterNetworkPolicy`.
+
+AdminNetworkPolicy (ANP) and BaselineAdminNetworkPolicy (BANP) were the first APIs created by the Network Policy API working group.
+They are `v1alpha1` resources, which means that they are not stable and are mostly used to get early feedback on the API design from
+the community.
+
+If you have seen these APIs, you probably have noticed that they are quite similar. If you have written controllers to reconcile these resources,
+you probably also found some code duplication. The original reason for having two separate resources was just a lack of
+use cases for multiple instances of BANP, which made it a singleton. However, with more feedback from the community, we have realized that
+those use cases do exist and that having two separate resources adds more burden than value.
+
+<!-- more -->
+
+### What has changed
+
+As a reminder, here is how the original Admin Network Policy API Model looked like:
+
+![image](/images/ANP-api-model.png)
+
+The model stays the same with the new API, the only difference is that evaluation order is now defined by the `tier` field
+and not by the resource type. `AdminNetworkPolicy` becomes a `ClusterNetworkPolicy` with `tier=Admin` and 
+`BaselineAdminNetworkPolicy` becomes a `ClusterNetworkPolicy` with `tier=Baseline`.
+
+<img src="/images/CNP.drawio.svg" width="541" alt="Cluster Network Policy API model">
+
+Other changes bring the functionality of `BaselineAdminNetworkPolicy` to parity with `AdminNetworkPolicy`. This includes:
+
+- Allowing multiple `ClusterNetworkPolicy` resources with `tier=Baseline` by using the same `priority` field as for `tier=Admin`.
+- Supporting `Pass` action in `ClusterNetworkPolicy` with `tier=Baseline` to allow skipping all further rules in the `Baseline` tier.
+- Supporting `domainNames` matching for `egress` rules in `ClusterNetworkPolicy` with `tier=Baseline`.
+
+The [enhancement proposal](https://github.com/kubernetes-sigs/network-policy-api/pull/289) has some more details for those interested.
+
+### Examples
+
+Let's take a look at some examples based on the original [user stories](../../user-stories.md).
+
+#### Story 1:Deny traffic at a cluster level
+
+To deny all traffic at the cluster level, the following `AdminNetworkPolicy` was used:
+
+```yaml
+apiVersion: policy.networking.k8s.io/v1alpha1
+kind: AdminNetworkPolicy
+metadata:
+  name: cluster-wide-deny-example
+spec:
+  priority: 10
+  subject:
+    namespaces:
+      matchLabels:
+        kubernetes.io/metadata.name: sensitive-ns
+  ingress:
+    - action: Deny
+      from:
+      - namespaces:
+         namespaceSelector: {}
+      name: select-all-deny-all
+```
+
+which looks like this with the new `ClusterNetworkPolicy` API:
+
+```yaml
+--8<-- "user-story-examples/user-story-1.yaml"
+```
+
+#### Story 5: Cluster Wide Default Guardrails
+
+To deny all traffic in a cluster by default (in an overridable manner), the following `BaselineAdminNetworkPolicy` was used:
+
+```yaml
+apiVersion: policy.networking.k8s.io/v1alpha1
+kind: BaselineAdminNetworkPolicy
+metadata:
+  name: default
+spec:
+  subject:
+    namespaces: {}
+  ingress:
+    - action: Deny   # zero-trust cluster default security posture
+      from:
+      - namespaces:
+          namespaceSelector: {}
+```
+
+which looks like this with the new `ClusterNetworkPolicy` API:
+
+```yaml
+--8<-- "user-story-examples/user-story-5.yaml"
+```
+
+### Migration
+
+We appreciate all early adopters of the `AdminNetworkPolicy` and `BaselineAdminNetworkPolicy` APIs. 
+You can continue using them at their latest released version [v0.1.7](https://github.com/kubernetes-sigs/network-policy-api/releases/tag/v0.1.7)
+At the same time, we encourage you to plan your migration to the new `ClusterNetworkPolicy` API, which can be done once its first version is available.
+We plan to base our `beta` release on the `ClusterNetworkPolicy` API.
diff --git a/site-src/getting-started.md b/site-src/getting-started.md
@@ -8,11 +8,19 @@ doc for details on the supportability matrix.
 
 **2. Install the Network Policy API CRDs**
 
-The following commands will install the latest release version of the `AdminNetworkPolicy` and
-`BaselineAdminNetworkPolicy` CRDs in your K8s cluster:
+We don't have a released version of the `ClusterNetworkPolicy` API yet, but you can try out
+the latest version from the `main` branch by applying the following manifest:
 
 ```bash
-kubectl apply -f https://github.com/kubernetes-sigs/network-policy-api/releases/download/v0.1.1/install.yaml
+kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/network-policy-api/refs/heads/main/config/crd/standard/policy.networking.k8s.io_clusternetworkpolicies.yaml
+```
+
+The latest released version of the `AdminNetworkPolicy` and `BaselineAdminNetworkPolicy` is `v0.1.7`.
+Use the following command to install it in your cluster:
+
+```bash
+kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/network-policy-api/refs/tags/v0.1.7/config/crd/standard/policy.networking.k8s.io_adminnetworkpolicies.yaml \
+-f https://raw.githubusercontent.com/kubernetes-sigs/network-policy-api/refs/tags/v0.1.7/config/crd/standard/policy.networking.k8s.io_baselineadminnetworkpolicies.yaml
 ```
 
 **3. Try out one of the sample yamls for specific user stories**

diff --git a/site-src/images/CNP.drawio.svg b/site-src/images/CNP.drawio.svg
diff --git a/site-src/implementations.md b/site-src/implementations.md
@@ -6,11 +6,17 @@ Network Policy API resources and provides status and resource references for the
 Implementors of Network Policy API resources are encouraged to update this document with status information about their
 implementations, the versions they cover, and documentation to help users get started.
 
-## AdminNetworkPolicy and BaseLineAdminNetworkPolicy
+## ClusterNetworkPolicy
 
-Updated: 11-14-2024
+Updated: 13-Oct-2025
 
 - [Kube-network-policies](https://github.com/kubernetes-sigs/kube-network-policies)
+
+## AdminNetworkPolicy and BaseLineAdminNetworkPolicy (v1alpha1)
+
+Updated: 14-Nov-2024
+
+- [Kube-network-policies](https://github.com/kubernetes-sigs/kube-network-policies/tree/v0.8.1)
 - [OVN-Kubernetes CNI](https://github.com/ovn-org/ovn-kubernetes/) (Has implemented standard fields of the API + Nodes/Networks in Experimental)
 - [Antrea CNI](https://github.com/antrea-io/antrea/) (Has implemented standard fields of the API)
 - [KubeOVN CNI](https://github.com/kubeovn/kube-ovn) (Has implemented standard fields of the API)

diff --git a/site-src/index.md b/site-src/index.md
@@ -19,7 +19,12 @@ multiple K8s CRD resources geared towards different users and use cases.
 
 ### Active (APIs undergoing active development)
 
-- [AdminNetworkPolicy](api-overview.md#the-adminnetworkpolicy-resource) and [BaselineAdminNetworkPolicy](api-overview.md#the-baselineadminnetworkpolicy-resource)
+- [ClusterNetworkPolicy](api-overview.md#the-clusternetworkpolicy-resource)
+
+### Previous (APIs that have evolved to the next stage and are no longer actively developed)
+
+- [AdminNetworkPolicy](https://network-policy-api.sigs.k8s.io/reference/spec/#policy.networking.k8s.io%2fv1alpha1.AdminNetworkPolicy) and 
+[BaselineAdminNetworkPolicy](https://network-policy-api.sigs.k8s.io/reference/spec/#policy.networking.k8s.io%2fv1alpha1.BaselineAdminNetworkPolicy)
 
 ### Future (Possible APIs to be created in the future)
 
@@ -30,6 +35,7 @@ multiple K8s CRD resources geared towards different users and use cases.
 - [Kubecon NA 2022 Contributors Summit](https://youtu.be/00nVssi2oPA)
 - [Kubecon NA 2022 SIG Network Deep Dive](https://www.youtube.com/watch?v=qn9bM5Cwvg0&t=752s)
 - [Kubecon EU 2023 SIG Network Deep Dive](https://www.youtube.com/watch?v=0uPEFcWn-_o)
+- [Kubecon EU 2025 SIG Network Intro and Updates](https://www.youtube.com/watch?v=lBOdQHNNgEU)
 
 ## Community, discussion, contribution, and support
 Learn how to engage with the Kubernetes community on the [community page](http://kubernetes.io/community/).