diff --git a/mkdocs.yml b/mkdocs.yml
index 28dff59c..7d1b50d6 100644
--- 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
index 068b4260..cae9fac3 100644
--- 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:
-
+
## 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
index 25fa40ee..26323220 100644
--- 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
\ No newline at end of file
diff --git a/site-src/blog/posts/ClusterNetworkPolicy.md b/site-src/blog/posts/ClusterNetworkPolicy.md
new file mode 100644
index 00000000..492be9b9
--- /dev/null
+++ 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.
+
+
+
+### What has changed
+
+As a reminder, here is how the original Admin Network Policy API Model looked like:
+
+
+
+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`.
+
+
+
+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
index 698873b8..fa5fedeb 100644
--- 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
new file mode 100644
index 00000000..fac3580d
--- /dev/null
+++ b/site-src/images/CNP.drawio.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/site-src/implementations.md b/site-src/implementations.md
index 341a0f00..596620ba 100644
--- 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
index 2a46c869..bf023980 100644
--- 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/).
## 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
index 25fa40ee..26323220 100644
--- 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
\ No newline at end of file
diff --git a/site-src/blog/posts/ClusterNetworkPolicy.md b/site-src/blog/posts/ClusterNetworkPolicy.md
new file mode 100644
index 00000000..492be9b9
--- /dev/null
+++ 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.
+
+
+
+### What has changed
+
+As a reminder, here is how the original Admin Network Policy API Model looked like:
+
+
+
+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`.
+
+