More Info:
Enable and configure Network Policy for the cluster to control pod-to-pod traffic and enforce network segmentation.Risk Level
HighAddress
SecurityCompliance Standards
- CIS OKE
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
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).
- For OKE (OCI CLI):
- On any machine with access to your cloud provider/IaC:
-
List existing NetworkPolicy resources and check coverage
- On any machine with
kubectlaccess: - 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.
- Namespaces containing sensitive workloads (e.g., prod, payments, customer-data) have at least one
- On any machine with
-
Check for default-deny behavior per namespace
- On any machine with
kubectlaccess: - For important namespaces, confirm there is at least one policy that:
- Uses an empty
podSelector: {}withpolicyTypesincludingIngressand/orEgressto enforce default deny, - Or otherwise clearly restricts traffic according to your segmentation requirements.
- Uses an empty
- On any machine with
-
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).
- Confirm the selected network plugin/CNI is the one intended and supports
- If IaC is used, locate the cluster resource and inspect:
- CNI type and any flags that enable/disable network policies.
- In cloud console or IaC (Terraform, OCI Resource Manager templates, etc.), inspect cluster configuration:
-
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).
- Outside of the cluster, document:
-
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
NetworkPolicyobjects to enforce the decided model (e.g., default deny + explicit allow). - Validate behavior on any machine with
kubectlaccess:Optionally, run connectivity tests between pods in different namespaces to confirm policies are enforced as intended.
- Using your cloud provider console/CLI/IaC:
Using kubectl
Using kubectl
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.
Automation
Automation

