More Info:
The CNI plugin should support and enforce NetworkPolicy following least-privilege access. Start with a deny-all policy for inbound and outbound traffic and add exceptions as needed.Risk Level
MediumAddress
SecurityCompliance Standards
- CIS OKE
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify namespaces and current NetworkPolicies
- Run on any machine with
kubectlaccess: - Review which namespaces lack any
NetworkPolicy, as they are effectively “allow all” for ingress/egress.
- Run on any machine with
-
Inspect existing NetworkPolicies for least-privilege design
- For each namespace with policies, inspect details:
- Check that:
- Policies are scoped to specific
podSelectors (not missing or overly broad where that would violate least privilege). ingress/egressrules are as narrow as possible (namespaces, pods, IPBlocks, ports).- There is no “catch-all allow” (e.g., empty
ingress/egressarrays interpreted as allow depending on CNI, or rules that match all peers and all ports).
- Policies are scoped to specific
- For each namespace with policies, inspect details:
-
Determine default behavior (deny vs allow) per namespace
- Confirm whether there is an explicit “default deny” for both ingress and egress in each namespace where least privilege is required. Typical examples (for review, not necessarily verbatim for your CNI):
- If such policies do not exist, note that this namespace is likely in an “allow all” state unless your CNI enforces a different default.
- Confirm whether there is an explicit “default deny” for both ingress and egress in each namespace where least privilege is required. Typical examples (for review, not necessarily verbatim for your CNI):
-
Review CNI capabilities and NetworkPolicy support
- Check which CNI is installed and whether it fully supports Kubernetes
NetworkPolicyand, if applicable, global policies: - Use the CNI documentation (outside this procedure) to confirm:
- Support for
NetworkPolicy(ingress and egress). - Support for “global” policies (e.g., Calico GlobalNetworkPolicy) if you plan to use cluster-wide default denies.
- Support for
- Check which CNI is installed and whether it fully supports Kubernetes
-
Design and apply least-privilege default-deny policies
- For each target namespace, decide whether to use:
- A namespace-scoped default deny (
NetworkPolicywith emptyingressand/oregresslists andpodSelector: {}) plus explicit allow policies, or - A global/default policy mechanism provided by your CNI (e.g., Calico global policy), if appropriate.
- A namespace-scoped default deny (
- Create or update manifests locally, then apply:
- Ensure that for every namespace where you introduce default deny, you also define the minimal set of allow rules needed for application functionality.
- For each target namespace, decide whether to use:
-
Verify effective behavior and refine
- Confirm policies are in place:
- Optionally test connectivity (from test pods) to verify that:
- Traffic is blocked by default where intended.
- Only approved communications succeed.
- Iterate by adjusting manifests and reapplying with
kubectl apply -f ...until the balance between least privilege and application requirements is acceptable.
- Confirm policies are in place:
Using kubectl
Using kubectl
- No
NetworkPolicyobjects at all, or critical namespaces (e.g.default, application namespaces) with 0 policies. - Namespaces where every policy has
policyTypesonly containingIngress(noEgress) or vice versa, implying one direction is completely unrestricted. - Namespaces that are security‑sensitive but lack any “default deny” style policies.
- Namespaces with no policy that:
- Explicitly denies all ingress (no
ingressrules,policyTypesincludesIngress), and - Explicitly denies all egress (no
egressrules,policyTypesincludesEgress).
- Explicitly denies all ingress (no
- Policies that are clearly overly permissive, for example:
podSelector: {}combined withingress: []but no correspondingegressdefault deny (or vice versa).- Allow rules using
ipBlock: 0.0.0.0/0or very broad CIDRs. - Policies that select all pods in the namespace (
podSelector: {}) and allow all traffic (emptyingress/egresssections with missingpolicyTypesso they default to Ingress only).
- A CNI plugin known not to support Kubernetes
NetworkPolicy, or configured in a mode that disables policy enforcement. - Very old image tags (e.g. obvious legacy versions) suggesting the plugin may lack current NetworkPolicy features or bug fixes.
- No “baseline” policies that:
- Deny all ingress (
policyTypes: ["Ingress"]with emptyingress: []), and - Deny all egress (
policyTypes: ["Egress"]with emptyegress: []or combined["Ingress","Egress"]with both empty).
- Deny all ingress (
- Policies that only add allows without any default deny in that namespace, meaning pods with no matching policy remain fully open.
- Absence of any global “default deny” style
GlobalNetworkPolicywhen you expect cluster‑wide least‑privilege enforcement. - Global policies that broadly allow all ingress/egress without fine‑grained selectors.
How to interpret the findings
- If you find namespaces (especially
defaultor production app namespaces) with no default deny for ingress and egress and only permissive or no policies, the cluster is not following least‑privilege. - If the CNI plugin is old or lacks NetworkPolicy support, then even well‑written policies may not be enforced as intended.
Automation
Automation

