Ensure Latest CNI Version Is Used

More Info:

Running the latest CNI plugin version ensures the cluster benefits from the most recent security fixes and NetworkPolicy support. Review the CNI plugin documentation and upgrade as needed.

Risk Level

Medium

Address

Security

Compliance Standards

CIS AKS

Triage and Remediation

Remediation

Remediation

Manual Steps

Identify the CNI plugin in use and its version

Run on: any machine with kubectl access

kubectl -n kube-system get daemonset -o wide
kubectl -n kube-system get pods -o wide

Look for the AWS VPC CNI DaemonSet (commonly aws-node). Then get its image:

kubectl -n kube-system get daemonset aws-node -o jsonpath='{.spec.template.spec.containers[*].image}'; echo

Map the running image to an AWS CNI release version
- Take the image from step 1 (for example 602401143452.dkr.ecr.us-west-2.amazonaws.com/amazon-k8s-cni:v1.15.4) and compare it with the current releases:
- Open in a browser:
  - AWS docs: https://docs.aws.amazon.com/eks/latest/userguide/managing-vpc-cni.html
  - GitHub releases: https://github.com/aws/amazon-vpc-cni-k8s/releases
- Determine whether the running tag (e.g. v1.15.4) is the latest stable version recommended for your EKS and Kubernetes versions.
Review compatibility and upgrade guidance
- From the AWS docs page, confirm:
  - The latest supported CNI version for your EKS/Kubernetes version.
  - Any upgrade prerequisites or migration steps (e.g., environment variables, config changes in aws-node DaemonSet, IAM permissions).
- If your current version is not the latest compatible version, plan an upgrade window (DaemonSet update causes rolling restart of CNI pods on all nodes, which can affect networking).
Upgrade the AWS CNI plugin (if not latest compatible)
- Run on: any machine with kubectl access
- If you manage CNI via eksctl/Terraform, follow that tool’s documented method instead of direct kubectl edits. If you manage it directly with manifests, update the DaemonSet image:
```
# Example: set to the desired latest tag from AWS docs / GitHub
kubectl -n kube-system set image daemonset/aws-node \
  aws-node=602401143452.dkr.ecr.us-west-2.amazonaws.com/amazon-k8s-cni:<LATEST_TAG>
```
- This triggers a rolling update of aws-node on every node; expect brief disruptions if misconfigured.

Verify the upgrade completed successfully

Run on: any machine with kubectl access

kubectl -n kube-system rollout status daemonset/aws-node
kubectl -n kube-system get daemonset aws-node -o jsonpath='{.spec.template.spec.containers[*].image}'; echo
kubectl -n kube-system get pods -l k8s-app=aws-node -o wide

Confirm all aws-node pods are running and the image tag matches the intended latest version.

Document the version and set a review cadence
- Record:
  - The CNI version now in use.
  - The date of the check/upgrade and the source (AWS docs / GitHub) you used.
- Establish a recurring review (e.g., quarterly) to repeat steps 1–5 and align with new AWS CNI releases and your EKS/Kubernetes upgrade schedule.

Using kubectl

# 1) Identify which CNI is in use
# Run on: any machine with kubectl access

kubectl -n kube-system get pods -o wide \
  -l 'k8s-app in (aws-node,calico-node,weave-net,cilium-agent)'

# Specifically check for AWS VPC CNI (aws-node)
kubectl -n kube-system get ds aws-node -o yaml | sed -n '1,120p'

What to look for:

If there is no aws-node DaemonSet in kube-system, this cluster is not using AWS VPC CNI; this particular CISAKS 4.4.1 control does not apply directly and you must review the actual CNI in use against its own documentation.
If aws-node exists, note:
- The image repository and tag under spec.template.spec.containers[].image
- Any init container images (for example, aws-vpc-cni-init)

Example snippet from the DaemonSet (trimmed):

spec:
  template:
    spec:
      containers:
      - name: aws-node
        image: amazon-k8s-cni:v1.12.0
      initContainers:
      - name: aws-vpc-cni-init
        image: amazon-k8s-cni-init:v1.12.0

Why this might indicate a problem:

A problem exists if:
- The image tag is a clearly older, pinned version (for example, v1.9.3, v1.10.0, etc.) compared to the latest version listed in the AWS VPC CNI release notes/documentation.
- The image tag is omitted or uses :latest, which makes it difficult to confirm whether the running version matches the current recommended release.
The actual determination requires manual comparison:
- Take the image tag(s) you see (for example, v1.12.0) and compare them to the latest stable version documented in the AWS VPC CNI plugin GitHub repository or AWS EKS documentation.
- If the running version is behind, assess the upgrade notes (breaking changes, required config flags, minimum Kubernetes version) before planning an upgrade.

# 2) Confirm all aws-node pods are using the same image
kubectl -n kube-system get pods -l k8s-app=aws-node -o jsonpath='{range .items[*]}{.metadata.name}{"  "}{.spec.containers[0].image}{"\n"}{end}'

What indicates a problem here:

Different aws-node pods using different image tags suggests a partial or failed rollout; this needs to be resolved before or during a version upgrade.
Any image/tag you identify still needs manual comparison with the official AWS VPC CNI documentation to determine whether it is current.

Automation

#!/usr/bin/env bash
# cisaks-4.4.1-cni-version-report.sh
# Purpose: Report AWS VPC CNI plugin versions in the cluster for manual review.

set -euo pipefail

echo "==[ CIS AKS 4.4.1 – CNI Version Report ]=="
echo

# 1) Detect which CNI DaemonSet(s) are present
echo "1) CNI-related DaemonSets (all namespaces):"
kubectl get ds -A \
  -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,IMAGES:.spec.template.spec.containers[*].image' \
  | grep -iE 'cni|aws-node|amazon-vpc' || echo "  (no DaemonSets with 'cni', 'aws-node', or 'amazon-vpc' in name)"
echo

# 2) Show detailed info for AWS VPC CNI DaemonSet(s)
echo "2) Detailed AWS VPC CNI DaemonSet info (if present):"
kubectl get ds -A \
  | awk 'NR>1 && tolower($2) ~ /aws-node|amazon-vpc/ {print $1":"$2}' | while IFS=: read -r ns name; do
    echo
    echo "---- DaemonSet ${ns}/${name} ----"
    kubectl -n "${ns}" get ds "${name}" -o wide
    echo
    echo "Images for ${ns}/${name}:"
    kubectl -n "${ns}" get ds "${name}" \
      -o jsonpath='{range .spec.template.spec.containers[*]}{.name}{"\t"}{.image}{"\n"}{end}'
    echo
    echo "Pod versions for ${ns}/${name}:"
    kubectl -n "${ns}" get pods -l "k8s-app=${name}" \
      -o custom-columns='NAME:.metadata.name,IMAGE:.spec.containers[*].image' || true
done
echo

# 3) List NetworkPolicy usage (scope of impact)
echo "3) NetworkPolicies per namespace (to understand impact area):"
kubectl get networkpolicy -A || echo "  (no NetworkPolicies found)"
echo

cat <<'EOF'

How to interpret this output:

- Identify the AWS VPC CNI DaemonSet:
  - Typically named "aws-node" in the "kube-system" namespace.
  - Note the container image(s) shown, e.g.:
      602401143452.dkr.ecr.us-west-2.amazonaws.com/amazon-k8s-cni:v1.16.0

- Potential problems indicating this control is NOT met:
  - The aws-node / amazon-k8s-cni image tag is older than the latest version
    documented by AWS for your cluster's Kubernetes version and region.
  - Multiple different CNI image versions are observed across pods for the
    same DaemonSet (incomplete rollout).
  - A non-AWS CNI plugin is in use where AWS VPC CNI is required by your design.

Next steps (manual):
  1. Check the latest recommended AWS VPC CNI version in the official AWS
     documentation for your Kubernetes version and region.
  2. Compare that to the image tags reported above.
  3. If out of date, plan and execute an upgrade of the CNI DaemonSet manifest
     (image field) following the AWS CNI upgrade guide, then rerun this script
     to confirm all pods are on the new version.

EOF

More Info:​

Risk Level​

Address​

Compliance Standards​

Triage and Remediation​

Remediation​