Skip to main content

Ensure Latest Cni Version Is Used

More Info:​

There are a variety of CNI plugins available for Kubernetes. If the CNI in use does not support Network Policies it may not be possible to effectively restrict traffic in the cluster.

Risk Level​

Low

Address​

Security

Compliance Standards​

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS AKS
  • CIS Critical Security Controls v8
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • Essential 8
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • 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 the CNI plugin and version currently in use

    • On any machine with kubectl access: 
      kubectl -n kube-system get pods -o wide | grep -i 'cni\|aws-node\|calico\|weave\|cilium'
    • For AWS CNI (EKS default), capture the version from the DaemonSet image: 
      kubectl -n kube-system get ds aws-node -o jsonpath='{.spec.template.spec.containers[*].image}{"\n"}'

  2. Check the CNI plugin’s version against upstream documentation

    • In a browser, open the AWS VPC CNI release notes and installation documentation (for EKS: the “Amazon VPC CNI plugin for Kubernetes” section in AWS docs and its GitHub releases page).
    • Compare the image tag you found in step 1 with the latest supported version documented for your Kubernetes version and EKS platform version.

  3. Decide whether an upgrade is appropriate

    • Review the CNI plugin’s release notes between your current version and the latest: look specifically for breaking changes, configuration changes, and known issues for your Kubernetes version.
    • Confirm with your change-management/SRE process whether upgrading the CNI fits current maintenance windows and risk appetite.

  4. Plan and prepare the CNI upgrade

    • For AWS CNI managed by EKS add-ons, on any machine with AWS CLI configured: 
      aws eks list-addons --cluster-name YOUR_CLUSTER_NAME
      aws eks describe-addon --cluster-name YOUR_CLUSTER_NAME --addon-name vpc-cni
      aws eks describe-addon-versions --addon-name vpc-cni
    • Determine the target version from the describe-addon-versions output that is both latest and compatible with your cluster’s Kubernetes/EKS version.
    • Take a current backup of your cluster manifests and confirm you can roll back to the previous add-on version if needed.

  5. Apply the CNI upgrade using the documented method

    • For AWS-managed VPC CNI add-on, on any machine with AWS CLI: 
      aws eks update-addon \
        --cluster-name YOUR_CLUSTER_NAME \
        --addon-name vpc-cni \
        --addon-version TARGET_VERSION \
        --resolve-conflicts OVERWRITE
    • If you manage the CNI via manifests/Helm instead of EKS add-ons, follow the official AWS VPC CNI installation/upgrade guide for your version, updating the image tag to the chosen target version in your manifests or Helm values and applying them with kubectl apply or helm upgrade.

  6. Verify the new CNI version is running cluster-wide

    • On any machine with kubectl access: 
      kubectl -n kube-system get ds aws-node -o jsonpath='{.spec.template.spec.containers[*].image}{"\n"}'
      kubectl -n kube-system get pods -l k8s-app=aws-node -o wide
    • Ensure all aws-node pods are in Running state and the image tag matches the target (latest) version identified in step 2.
Using kubectl
# 1) Identify CNI plugin in use
# Run on: any machine with kubectl access
kubectl -n kube-system get pods -o wide | egrep 'aws-node|cni|calico|weave|cilium'
  • For AWS EKS with the AWS VPC CNI, you should see pods like:
    • aws-node-xxxxx in the kube-system namespace.
  • If you do not see the expected CNI DaemonSet (e.g. aws-node on EKS), that indicates a potential misconfiguration and you must first confirm which CNI is actually managing pod networking.
# 2) Inspect the AWS CNI DaemonSet version (if using aws-node)
# Run on: any machine with kubectl access
kubectl -n kube-system get daemonset aws-node -o jsonpath='{.spec.template.spec.containers[*].image}{"\n"}'
  • Output example:
    • 602401143452.dkr.ecr.us-west-2.amazonaws.com/amazon-k8s-cni:v1.16.2
  • Indicators of a potential problem:
    • Image tag is very old compared to current versions listed in the AWS VPC CNI documentation for your region and Kubernetes version.
    • Image tag is latest (no explicit version), which makes it difficult to know which version is deployed and to track updates reliably.
# 3) Check CNI-related ConfigMaps that might pin an older version or behavior
# Run on: any machine with kubectl access
kubectl -n kube-system get configmap | egrep 'cni|aws-node' || true

# For each relevant ConfigMap (example: aws-node)
kubectl -n kube-system get configmap aws-node -o yaml
  • Review the ConfigMap contents for:
    • References to deprecated or legacy features.
    • Configuration explicitly disabling NetworkPolicy-like functionality (for CNIs that support it).
  • Indicators of a potential problem:
    • Config insists on legacy operating modes that the AWS CNI documentation calls out as deprecated or insecure.
    • Config maps reference options removed or changed in newer AWS CNI releases.
# 4) Verify node-level CNI configuration directory presence / hints
# Note: kubectl cannot read /var/lib/cni/networks on nodes directly.
# This is for context only; use this to enumerate nodes for later SSH-based review if needed.
# Run on: any machine with kubectl access
kubectl get nodes -o wide
  • Use the node list to decide which nodes to inspect manually (over SSH) at /var/lib/cni/networks if you need to correlate CNI state on-disk with what Kubernetes shows.
# 5) Confirm that pod networking is actually using the expected CNI
# Run on: any machine with kubectl access
kubectl -n kube-system describe daemonset aws-node
  • Look for:
    • Image: line under Containers.
    • Events: section for failed pulls of newer images or rollouts stuck on old versions.
  • Indicators of a potential problem:
    • DaemonSet rollout is failing, leaving some nodes on an older CNI image and others on a newer one.
    • Events show image pull errors for the intended newer CNI image, forcing you to remain on an outdated version.
# 6) (Optional) Capture CNI version evidence for manual comparison
# Run on: any machine with kubectl access
kubectl -n kube-system get daemonset aws-node -o yaml > aws-node-daemonset.yaml

You must now manually compare:

  • The container image version from step 2 against the AWS VPC CNI release notes / documentation for your Kubernetes version and region.
  • The configuration from step 3 against current AWS recommendations.

If the image tag is not among the currently supported or recommended versions, or the configuration forces deprecated behavior, that indicates a problem and you should plan an upgrade/change following AWS’s documented procedure (outside the scope of kubectl alone).

Automation
#!/usr/bin/env bash
# Purpose: Report AWS VPC CNI version and basic network policy support state across the cluster.
# Run on: any machine with kubectl access and aws CLI (optional, for addon version checks).

set -euo pipefail

echo "=== 1. Detecting AWS VPC CNI DaemonSet and image versions (kube-system namespace) ==="
kubectl -n kube-system get ds -o wide | grep -E 'aws-node|cni' || true

echo
echo "Detailed aws-node DaemonSet description (if present):"
kubectl -n kube-system get ds aws-node -o yaml 2>/dev/null | \
  sed -n '/containers:/,/volumes:/p' || echo "aws-node DaemonSet not found."

echo
echo "Extracting aws-node container images:"
kubectl -n kube-system get ds aws-node -o jsonpath='{.spec.template.spec.containers[*].image}{"\n"}' 2>/dev/null || \
  echo "aws-node DaemonSet not found."

echo
echo "=== 2. Checking aws-node Pod versions across nodes ==="
kubectl -n kube-system get pods -l k8s-app=aws-node -o wide || \
  echo "No Pods with label k8s-app=aws-node found."

echo
echo "Unique aws-node images actually running:"
kubectl -n kube-system get pods -l k8s-app=aws-node -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' 2>/dev/null | \
  sort -u || echo "No running aws-node Pods found."

echo
echo "=== 3. Checking for NetworkPolicy objects (are they in use?) ==="
kubectl get networkpolicy --all-namespaces || \
  echo "No NetworkPolicy objects found in the cluster."

echo
echo "=== 4. (Optional) Detecting AWS VPC CNI addon version via aws CLI (EKS only) ==="
# Requires: AWS_REGION and CLUSTER_NAME environment variables set if using aws CLI.
if command -v aws >/dev/null 2>&1; then
  if [[ -n "${AWS_REGION:-}" && -n "${CLUSTER_NAME:-}" ]]; then
    echo "Querying EKS addon version for aws-vpc-cni in region ${AWS_REGION}, cluster ${CLUSTER_NAME}:"
    aws eks describe-addon \
      --region "${AWS_REGION}" \
      --cluster-name "${CLUSTER_NAME}" \
      --addon-name aws-vpc-cni \
      --query 'addon.{Version:addonVersion,Status:status}' \
      --output table || echo "Failed to query EKS addon; check IAM permissions."
  else
    echo "aws CLI found but AWS_REGION or CLUSTER_NAME is not set; skipping EKS addon check."
  fi
else
  echo "aws CLI not installed; skipping EKS addon (managed CNI) version check."
fi

echo
echo "=== 5. Summary guidance ==="
cat <<'EOF'
Interpretation / what indicates a potential problem:

1) Outdated or inconsistent aws-node images:
   - If 'Unique aws-node images actually running' shows more than one image tag,
     or tags known to be old (e.g., very old semantic versions), review and plan an upgrade.
   - Compare the image tag (e.g., amazon/aws-node:vX.Y.Z) or EKS addonVersion to the
     latest recommended version in the AWS VPC CNI release notes.

2) Missing aws-node DaemonSet:
   - If the aws-node DaemonSet is not found on an EKS cluster, investigate how CNI is deployed
     and verify it is the supported AWS CNI and is up to date.

3) NetworkPolicy usage:
   - If NetworkPolicy objects exist (output in section 3) you rely on policy enforcement.
     Verify that your chosen CNI (here, aws-node / AWS VPC CNI) and its configured mode
     support the level of NetworkPolicy you require, and that you are on a supported,
     current version.
   - If no NetworkPolicy objects exist, you may not currently rely on network policies,
     but you should still ensure the CNI plugin is on a supported, up-to-date version.

This script does NOT automatically fix or upgrade the CNI.
Use the reported image/addon versions and compare them with the AWS VPC CNI documentation
and release notes, then plan any upgrade through your normal deployment/IaC process.
EOF

Additional Reading:​