> ## Documentation Index
> Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# 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

<Tabs>
  <Tab title="Remediation">
    ### Remediation

    <AccordionGroup>
      <Accordion title="Manual Steps" defaultOpen="true">
        1. **Identify the CNI plugin in use and its version**
           * Run on: any machine with `kubectl` access
           ```bash theme={null}
           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:
           ```bash theme={null}
           kubectl -n kube-system get daemonset aws-node -o jsonpath='{.spec.template.spec.containers[*].image}'; echo
           ```

        2. **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](https://docs.aws.amazon.com/eks/latest/userguide/managing-vpc-cni.html)
             * GitHub releases: [https://github.com/aws/amazon-vpc-cni-k8s/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.

        3. **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).

        4. **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:
           ```bash theme={null}
           # 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.

        5. **Verify the upgrade completed successfully**
           * Run on: any machine with `kubectl` access
           ```bash theme={null}
           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.

        6. **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.
      </Accordion>

      <Accordion title="Using kubectl">
        ```bash theme={null}
        # 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):

        ```yaml theme={null}
        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.

        ```bash theme={null}
        # 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.
      </Accordion>

      <Accordion title="Automation">
        ```bash theme={null}
        #!/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
        ```
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>