Skip to main content

More Info:

Enable and configure Network Policy for the cluster to control pod-to-pod traffic and enforce network segmentation.

Risk Level

High

Address

Security

Compliance Standards

  • CIS OKE

Triage and Remediation

Remediation

Manual Steps

  1. Identify whether the cluster supports NetworkPolicy
    • On any machine with access to your cloud provider/IaC:
      • For OKE (OCI CLI):
        Confirm the CNI/plugin in use supports Kubernetes NetworkPolicy (e.g., Calico, Cilium, appropriate OCI CNI mode).
  2. List existing NetworkPolicy resources and check coverage
    • On any machine with kubectl access:
    • Review whether:
      • Namespaces containing sensitive workloads (e.g., prod, payments, customer-data) have at least one NetworkPolicy.
      • There is a strategy (e.g., default deny + explicit allows) rather than a few ad‑hoc policies.
  3. Check for default-deny behavior per namespace
    • On any machine with kubectl access:
    • For important namespaces, confirm there is at least one policy that:
      • Uses an empty podSelector: {} with policyTypes including Ingress and/or Egress to enforce default deny,
      • Or otherwise clearly restricts traffic according to your segmentation requirements.
  4. Review cloud/IaC configuration for CNI and policy enablement
    • In cloud console or IaC (Terraform, OCI Resource Manager templates, etc.), inspect cluster configuration:
      • Confirm the selected network plugin/CNI is the one intended and supports NetworkPolicy.
      • Confirm any “Network Policy” / “Network Security” options exposed by the provider are enabled where required (document the setting and where it is defined in your IaC).
    • If IaC is used, locate the cluster resource and inspect:
      • CNI type and any flags that enable/disable network policies.
  5. Decide and define the target segmentation model
    • Outside of the cluster, document:
      • Which namespaces are “default deny” by design.
      • Which system/infra namespaces (e.g., kube-system, logging, monitoring) need carefully scoped exceptions.
      • Any required cross-namespace and external dependencies (databases, APIs, ingress controllers).
    • Based on this, determine where NetworkPolicy must be tightened (namespaces with no policies or policies that are too permissive).
  6. Implement and validate policy changes
    • Using your cloud provider console/CLI/IaC:
      • If NetworkPolicy is not enabled at the cluster/CNI level, update the cluster configuration to an option that supports it (this may require cluster recreation or node pool changes per provider documentation).
    • Using manifests applied through your normal deployment process (IaC/CI/CD), add or update NetworkPolicy objects to enforce the decided model (e.g., default deny + explicit allow).
    • Validate behavior on any machine with kubectl access:
      Optionally, run connectivity tests between pods in different namespaces to confirm policies are enforced as intended.
kubectl cannot be used to enable or configure the cluster‑level Network Policy provider; this must be done in the cloud provider’s managed control plane configuration (console, CLI, or IaC). Refer to the Manual Steps section for guidance on what to review and how to remediate this finding at the provider/IaC level.