Skip to main content

Ensure Network Policy Is Enabled And Set As Appropriate

More Info:​

Amazon EKS provides two ways to implement network policy. You choose a network policy option when you create an EKS cluster. The policy option cant be changed after the cluster is created: Calico Network Policies, an open-source network and network security solution founded by Tigera. Both implementations use Linux IPTables to enforce the specified policies. Policies are translated into sets of allowed and disallowed IP pairs. These pairs are then programmed as IPTable filter rules.

Risk Level​

Low

Address​

Security

Compliance Standards​

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CIS GKE
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • NIS2 Directive
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation​

Remediation​

Manual Steps
  1. Identify cluster(s) and current network policy status
    Run on any machine with gcloud configured:

    gcloud container clusters list --format="table(name,location,networkConfig.networkPolicy)"

    For each relevant cluster:

    gcloud container clusters describe CLUSTER_NAME \
    --zone CLUSTER_ZONE \
    --format="yaml:name,location,networkConfig.networkPolicy"

    Review whether networkConfig.networkPolicy.enabled is true and note the provider and clusterIpv4Cidr/network to understand the networking context.

  2. Decide whether to enable Network Policy per cluster
    For each cluster where networkConfig.networkPolicy.enabled is false, review:

    • Whether workloads require pod isolation, namespace-level segmentation, or deny-by-default behavior.
    • Whether any in-cluster services or sidecars assume unrestricted pod-to-pod communication.
    • Change management / window to handle any potential connectivity changes once policies are applied.
      If isolation is required and the cluster can tolerate policy-driven restrictions, proceed to enable Network Policy.
  3. Enable Network Policy add-on where required
    For each cluster you have decided to protect with Network Policy and where it is currently disabled, run:

    gcloud container clusters update CLUSTER_NAME \
    --zone CLUSTER_ZONE \
    --update-addons NetworkPolicy=ENABLED

    Note that this is a control-plane configuration change and may take several minutes; monitor for any errors.

  4. Enable Network Policy enforcement on the cluster
    After the add-on is enabled, turn on Network Policy for the cluster:

    gcloud container clusters update CLUSTER_NAME \
    --zone CLUSTER_ZONE \
    --enable-network-policy

    Be aware this changes dataplane behavior; if you later add restrictive policies, pod-to-pod connectivity may be impacted.

  5. Define initial, safe NetworkPolicy objects (using kubectl)
    On any machine with kubectl access, for each namespace that should remain fully open initially, create an explicit allow-all policy (adjust as appropriate for your risk appetite):

    kubectl create namespace example-apps # if needed

    cat <<'EOF' | kubectl apply -f -
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
    name: allow-all-in-namespace
    namespace: example-apps
    spec:
    podSelector: {}
    policyTypes:
    - Ingress
    - Egress
    ingress:
    - {}
    egress:
    - {}
    EOF

    Then iteratively replace these with more restrictive, application-aware policies as you refine your segmentation model.

  6. Verify Network Policy is enabled and working as intended
    a. Verify control-plane configuration (any machine with gcloud):

    gcloud container clusters describe CLUSTER_NAME \
    --zone CLUSTER_ZONE \
    --format="yaml:networkConfig.networkPolicy"

    Confirm enabled: true and a valid provider.
    b. Verify in-cluster policy presence (any machine with kubectl):

    kubectl get networkpolicy --all-namespaces

    c. Optionally validate isolation by deploying simple test pods in different namespaces and confirming that traffic is allowed or blocked in line with your defined NetworkPolicy objects.

Using kubectl

kubectl cannot enable or configure the cluster-wide Network Policy feature in GKE; this must be done at the cloud provider / managed control plane level (for example, using gcloud, console, or IaC). Refer to the Manual Steps section for the exact gcloud commands and configuration changes required.

Automation
#!/usr/bin/env bash
#
# Automation: Report GKE Network Policy enablement state for a project
# Requirements:
# - gcloud configured and logged in
# - kubectl installed (used only for optional per-cluster details)
# - PROJECT must contain only GKE clusters (no effect on other resources)
#
# Usage:
# ./check_gke_network_policy.sh [GCP_PROJECT_ID]
#
# Output:
# - For each cluster: whether NetworkPolicy add-on and network policy are enabled
# - Flags clusters that are NOT enforcing network policy

set -euo pipefail

PROJECT="${1:-}"

if [[ -z "${PROJECT}" ]]; then
echo "Usage: $0 GCP_PROJECT_ID" >&2
exit 1
fi

gcloud config set project "${PROJECT}" >/dev/null

echo "=== GKE Network Policy Status for project: ${PROJECT} ==="
echo

# List all clusters in all locations for this project
# Any machine with gcloud access can run this
clusters_json="$(gcloud container clusters list --format=json || true)"

if [[ -z "${clusters_json}" || "${clusters_json}" == "[]" ]]; then
echo "No GKE clusters found in project ${PROJECT}."
exit 0
fi

# Print header
printf "%-40s %-15s %-20s %-18s %-22s %-12s\n" \
"CLUSTER" "LOCATION" "NETWORK_POLICY_ADDON" "NETWORK_POLICY_ENABLED" "NETWORK_POLICY_PROVIDER" "RISK"
printf "%0.s-" {1..135}
echo

# Parse cluster details
echo "${clusters_json}" | jq -r '.[] | @base64' | while read -r row; do
_jq() {
echo "${row}" | base64 --decode | jq -r "${1}"
}

name=$(_jq '.name')
location=$(_jq '.location // .zone // "-"')

# Add-on information (NetworkPolicy add-on)
# For older clusters, this may be under addonsConfig.networkPolicyConfig
addon_enabled=$(_jq '.addonsConfig.networkPolicyConfig.enabled // false')

# Network policy enablement
np_enabled=$(_jq '.networkPolicy.enabled // false')
np_provider=$(_jq '.networkPolicy.provider // "NONE"')

# Determine risk: if network policy not enabled at cluster level, flag as HIGH
if [[ "${np_enabled}" != "true" ]]; then
risk="HIGH"
else
risk="OK"
fi

# Normalize booleans to YES/NO
addon_status="NO"
[[ "${addon_enabled}" == "true" ]] && addon_status="YES"

np_status="NO"
[[ "${np_enabled}" == "true" ]] && np_status="YES"

printf "%-40s %-15s %-20s %-18s %-22s %-12s\n" \
"${name}" "${location}" "${addon_status}" "${np_status}" "${np_provider}" "${risk}"
done

cat <<'EOF'

Interpretation:

- NETWORK_POLICY_ADDON = YES and NETWORK_POLICY_ENABLED = YES:
* Cluster is configured to use a network policy provider (e.g., Calico or Dataplane V2).
* Next manual step: review actual NetworkPolicy objects with:
kubectl get networkpolicy -A
and assess whether policies are appropriately restrictive.

- NETWORK_POLICY_ENABLED = NO (RISK = HIGH):
* Network policy is NOT enforced at the cluster level.
* This is a finding against CIS GKE 5.6.7.
* Manual remediation (per cluster, from any machine with gcloud access):
gcloud container clusters update CLUSTER_NAME \
--zone CLUSTER_ZONE \
--update-addons NetworkPolicy=ENABLED

gcloud container clusters update CLUSTER_NAME \
--zone CLUSTER_ZONE \
--enable-network-policy

Note: This script does NOT change any configuration. Use it to identify clusters
that require manual review and potential remediation.
EOF