Google CloudOverview
Network policy enforcement lets you restrict which Pods and Services can communicate with each other. Without it, workloads in the cluster can generally talk to each other freely unless you add other controls.
Rationale
Enabling network policy is the platform prerequisite for Kubernetes NetworkPolicy objects to have effect. This is useful for reducing lateral movement between workloads, separating tiers of an application, and containing compromise. Enabling the feature alone is not enough, though: you must also create actual NetworkPolicy resources for the namespaces and workloads that need isolation.
Remediation guidance
Using Google Cloud Console
- Open
Kubernetes Enginein Google Cloud Console. - Select the affected cluster.
- Under
Networking, edit the network policy settings. - Enable network policy enforcement for the cluster.
- If the cluster uses Standard mode without GKE Dataplane V2, ensure the related node enforcement setting is also enabled.
Using Command Line
For Standard clusters, enable the network policy add-on and enforcement:
gcloud container clusters update [CLUSTER_NAME] --location [LOCATION] --update-addons=NetworkPolicy=ENABLED
gcloud container clusters update [CLUSTER_NAME] --location [LOCATION] --enable-network-policy
Then deploy namespace-level policies. Example default-deny ingress policy:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: default
spec:
podSelector: {}
policyTypes:
- Ingress
Impact
Enabling network policy enforcement on existing Standard clusters can recreate nodes and disrupt workloads during rollout. It can also break application traffic if you enable enforcement before defining the allow rules your workloads need.
Notes
In Autopilot, network policy enforcement is enabled by default. In clusters using GKE Dataplane V2, policy enforcement is built in.
References
- https://cloud.google.com/kubernetes-engine/docs/how-to/network-policy
- https://kubernetes.io/docs/concepts/services-networking/network-policies/
Service-wide remediation
Recommended when many resources are affected: treat network policy as a platform control and roll it out together with reusable baseline policies, not as an isolated cluster toggle.
Standardize a baseline policy set such as default-deny plus approved namespace exceptions, then apply it consistently through GitOps or IaC.
Operational rollout
- Start with non-production clusters and map application flows before enforcing policy.
- Enable the cluster feature, then apply baseline policies and app-specific allow rules.
- Re-scan and validate east-west traffic after rollout.
Query logic
These are the stored checks tied to this control.
Network policy is enabled on Kubernetes Engine Clusters
Connectors
Covered asset types
Expected check: eq []
gkeClusters(where:{networkPolicyEnabled:false}){...AssetFragment}
