KubernetesOverview
Use network policies to isolate traffic in your cluster network.
Rationale
Running different applications on the same Kubernetes cluster creates a risk of one compromised application attacking a neighboring application. Network segmentation is important to ensure that containers can communicate only with those they are supposed to. A network policy is a specification of how selections of pods are allowed to communicate with each other and other network endpoints.
Network Policies are namespace scoped. When a network policy is introduced to a given namespace, all traffic not allowed by the policy is denied. However, if there are no network policies in a namespace all traffic will be allowed into and out of the pods in that namespace.
Impact
Once network policies are in use within a given namespace, traffic not explicitly allowed by a network policy will be denied. As such it is important to ensure that, when introducing network policies, legitimate traffic is not blocked.
Audit
Run the below command and review the NetworkPolicy objects created in the cluster.
kubectl get networkpolicy --all-namespaces
Ensure that each namespace defined in the cluster has at least one Network Policy.
Remediation guidance
Follow the documentation and create NetworkPolicy objects as you need them.
References
Multiple Remediation Paths
SERVICE-WIDE (RECOMMENDED when many resources are affected): Apply organization/tenant-level guardrails and baseline policies for the entire platform.
ASSET-LEVEL: Fix only the affected resources identified by this control.
PREVENTIVE: Add preventive policy checks to CI/CD and periodic posture scans.
References for Service-Wide Patterns
- Platform policy/governance and preventive control patterns should be applied tenant-wide where supported.
Query logic
These are the stored checks tied to this control.
Kubernetes namespaces without network policies
Connectors
Covered asset types
Expected check: eq []
{
namespaces(where: {networkPolicies: null}) {
...AssetFragment
}
}
