Skip to main content

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

Medium

Address

Security

Compliance Standards

  • CIS OKE

Triage and Remediation

Remediation

Manual Steps

  1. Identify namespaces and current NetworkPolicies
    • Run on any machine with kubectl access:
    • Review which namespaces lack any NetworkPolicy, as they are effectively “allow all” for ingress/egress.
  2. 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/egress rules are as narrow as possible (namespaces, pods, IPBlocks, ports).
      • There is no “catch-all allow” (e.g., empty ingress/egress arrays interpreted as allow depending on CNI, or rules that match all peers and all ports).
  3. 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.
  4. Review CNI capabilities and NetworkPolicy support
    • Check which CNI is installed and whether it fully supports Kubernetes NetworkPolicy and, 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.
  5. Design and apply least-privilege default-deny policies
    • For each target namespace, decide whether to use:
      • A namespace-scoped default deny (NetworkPolicy with empty ingress and/or egress lists and podSelector: {}) plus explicit allow policies, or
      • A global/default policy mechanism provided by your CNI (e.g., Calico global policy), if appropriate.
    • 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.
  6. 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.
What to look for (problem indicators)
  • No NetworkPolicy objects at all, or critical namespaces (e.g. default, application namespaces) with 0 policies.
  • Namespaces where every policy has policyTypes only containing Ingress (no Egress) or vice versa, implying one direction is completely unrestricted.
  • Namespaces that are security‑sensitive but lack any “default deny” style policies.

What to look for (problem indicators)
  • Namespaces with no policy that:
    • Explicitly denies all ingress (no ingress rules, policyTypes includes Ingress), and
    • Explicitly denies all egress (no egress rules, policyTypes includes Egress).
  • Policies that are clearly overly permissive, for example:
    • podSelector: {} combined with ingress: [] but no corresponding egress default deny (or vice versa).
    • Allow rules using ipBlock: 0.0.0.0/0 or very broad CIDRs.
    • Policies that select all pods in the namespace (podSelector: {}) and allow all traffic (empty ingress / egress sections with missing policyTypes so they default to Ingress only).

Then inspect the CNI daemonset or pods:
What to look for (problem indicators)
  • 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.

What to look for (problem indicators)
  • No “baseline” policies that:
    • Deny all ingress (policyTypes: ["Ingress"] with empty ingress: []), and
    • Deny all egress (policyTypes: ["Egress"] with empty egress: [] or combined ["Ingress","Egress"] with both empty).
  • Policies that only add allows without any default deny in that namespace, meaning pods with no matching policy remain fully open.

What to look for (problem indicators)
  • Absence of any global “default deny” style GlobalNetworkPolicy when 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 default or 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.
Deciding what policies to add or adjust depends on application requirements and risk appetite and must be done manually based on this evidence.