This PR adds a blog to the website about the future of the API.

Author: frozenprocess

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  
+  frozenprocess:
+    name: Reza Ramezanpour
+    description: Senior Developer Advocate at Tigera.
+    avatar: https://github.com/frozenprocess.png

site-src/blog/posts/The Road to a More Scalable and Unified Network Policy API.md

@@ -0,0 +1,63 @@
+---
+date: 2025-10-05
+authors:
+  - frozenprocess
+---
+
+# The Road to a More Scalable and Unified Network Policy API
+
+The Admin and Baseline Network Policy (ANP, BANP) has been available in `v1alpha1` state for some time, with several open source projects [implementations](../implementation) of it giving security enthusiast a sneak peak into a way to experiment and adopt it in real-world environments. In this blog we are going to go over some new changes that made their way to the `v1alpha2` and 🤞 the beta!
+
+In particular, the sub-group has been addressing some of the complexities within the existing tow APIs and some terminology changes to better represent their functionalities.
+A central part of this effort is rethinking how cluster-wide and namespace-level policies interact, ensuring the API evolves into a more consistent and powerful tool for Kubernetes users and to achieve it we are unify these separate APIs into a single, modular, and extensible design.
+
+<!-- more -->
+
+## Quick reminder
+
+Regardless of the names or the fancy technical terms, the ultimate goal here is to provide a more robust and comprehensive way to secure your environment.
+The `v1alpha1` API addressed this by introducing two resources, `ANP` and `BANP`, which brought features like **Action, Priority, and multi-namespace reach** to Kubernetes security, among others. These were capabilities many of us felt were missing when working with traditional Kubernetes network policies.
+
+To give you a clear sense of what to expect from this blog, we’ll dive into the following bullet points in detail:
+
+1. Unifying Admin and Baseline Network Policies
+  1. Changes to Action
+  1. Policy Types (Tier)
+  1. Docs and Versioning Strategy
+1. A Modular Architecture for Network Policies
+1. The Path to Beta (Get involved!)
+
+
+## Unifying Admin and Baseline Network Policies
+
+Both `AdminNetworkPolicy` and `BaselineAdminNetworkPolicy` are being replaced by the new `ClusterNetworkPolicy` resource. Introduced in `v1alpha2`, this resource consolidates and enhances the functionality of its predecessors, making cluster scaled network policy management more streamlined and efficient.
+
+### Changes to Action
+
+`ClusterNetworkPolicy` supports the **Accept, Deny, and Pass** actions. Note that the previous **Allow** action has been renamed to **Accept** to make its behavior clearer to users.
+
+### Policy Types (Tier)
+
+The `ClusterNetworkPolicySpec` now includes a `Tier` field, which can be set to either `Admin` or `Baseline`.
+The `Admin tier` corresponds to the old `AdminNetworkPolicy` and is evaluated **first**. The `Baseline tier` corresponds to the old `BaselineAdminNetworkPolicy` and is **evaluated after** the `NetworkPolicy tier`.
+
+***
+
+## A Modular Architecture for Network Policies
+
+The group is refactoring its reference implementation to improve modularity and extensibility. This new architecture employs a plugin-based system where new policy evaluators can be added without modifying the core logic. This design is intended to simplify the process of adding new features and experimenting with new ideas. The new design also incorporates a **Cube IP tracker** to help with scalability issues by abstracting pod information and reducing the load on the API server. This approach is seen as a way to address issues with network policies that depend on IPs and pods, which have high churn and can heavily impact the API server.
+
+***
+
+## The Path Beta (Get involved!)
+
+The immediate priority for the subgroup is to finalize v1alpha2, which will pave the way for a stable v1beta1 candidate. This timeline, however, depends on receiving timely API reviews from the busy Kubernetes API approvers.
+
+An important part of this process is updating the documentation to reflect all the new API changes and the project’s updated name. The team plans to complete these documentation updates once the core API changes are merged. Volunteers are always welcome to help accelerate this effort. If you’re interested, you can learn more about how to get involved [here](https://github.com/kubernetes-sigs/network-policy-api?tab=readme-ov-file#community-discussion-contribution-and-support).
+
+
+# What’s Next
+
+The subgroup aims to:
+- Finalize `v1alpha2` implementation.
+- Continue tightening conformance, documentation, and image publishing automation. ([Get involved we can always use some help](https://github.com/kubernetes-sigs/network-policy-api?tab=readme-ov-file#community-discussion-contribution-and-support))