Overview
The Network Policy service is an out-of-the-box offering that allows platform teams and developers to build zero-trust network security into their Kubernetes environments without sacrificing governance, access control and performance. Some of the key advantages of this solution include:
- Standardized installation and deployment of network policies across a fleet of clusters via blueprinting including the ability to define defaults to enable a Day 0 zero trust model
- Assignment of policies to multiple levels of infrastructure including clusters and namespaces and ability to fine-tune based on application needs
Network Policy Overview¶
Using the console, API, RCTL, or GitOps, an admin can create network policies of the following types:
- Cluster: these policies are scoped at the cluster level and should be used to enforce default sets of rules across the cluster
- Namespace: these policies are scoped at the namespace level and should be used to protect individual pods or applications in a given workspace
The creation of cluster-wide policies versus namespace policies have different workflows and require certain roles. See the RBAC section below to learn more. These policies can then be assigned to the appropriate assets and standardized across your project infrastructure.
Cilium Integration¶
Starting with the 2.6 release, a CNI agnostic approach is supported for network policy enforcement within the platform.
- Network policy enforcement will be handled by the primary CNI in the cluster or any other plugin (like Cilium in chaining mode) installed as an add-on
- Users have the flexibility to deploy their own add-on (like Cilium’s Hubble component) for visibility
Network Policy Enforcement Recommendations by Cluster Type and Primary CNI¶
| Cluster Type | Primary CNI | Supported? | Recommendation |
|---|---|---|---|
| AKS | azure | Yes | Use Azure’s policy enforcement capability (OR) Deploy Cilium as custom add-on in chaining mode |
| calico | Yes | Use Calico’s policy enforcement capability (OR) Deploy Cilium as custom add-on in chaining mode | |
| kubenet | No | No | |
| azure-cni-overlay | Yes | Use azure-cni-overlay with cilium as dataplane (OR) Deploy Cilium as custom add-on in chaining mode | |
| EKS | aws-cni | Yes | Use aws-cni’s policy enforcement capability (OR) Deploy Cilium as custom add-on in chaining mode |
| calico | Yes | Use Calico’s policy enforcement capability (OR) Deploy Cilium as custom add-on in chaining mode | |
| MKS | calico | Yes | Use Calico’s policy enforcement capability (OR) Deploy Cilium as custom add-on in chaining mode |
| canal | Yes | Deploy Cilium as custom add-on in chaining mode | |
| cilium | Yes | Use Cilium’s policy enforcement |
To deploy Cilium as a custom add-on in chaining mode, refer Cilium in Chaining-Mode for Network Policy
RBAC¶
The following table lists the roles that can access specific components of the Network Policy Management Service.
| Feature | Roles |
|---|---|
| Cluster Network Policies | Infra Admin, Org Admin |
| Namespace Network Policies | Workspace Admin, Project Admin, Org Admin |
For more information on what these roles do generally, see the roles documentation.