chore(recipes): bump aws-efa to v0.5.26 keeping AICR's hardened securityContext

[yuanchen8911]

Summary

Bumps the EFA device-plugin chart from v0.5.3 (2023) → v0.5.26 / app v0.5.18 (current upstream latest). AICR keeps its existing hardened securityContext override rather than accepting the chart's new upstream-default of privileged: true.

Motivation / Context

The audit in #698 flagged aws-efa as blocked on a security review because chart v0.5.4+ switched the device-plugin DaemonSet's default to privileged: true + runAsUser: 0, conflicting with AICR's narrow override (allowPrivilegeEscalation: false, capabilities.drop: [ALL], runAsNonRoot: false).

Live-cluster testing on EKS aicr2 (see Testing below) shows the narrow posture continues to work on AICR's primary target — the device-plugin binary doesn't actually require elevated privileges on Ubuntu 24.04 / kernel 6.14 / p5. This unlocks a third path beyond "accept privileged: true" or "stay on v0.5.3": bump the chart, keep the narrow override, get 23 patches of upstream fixes without expanding the security blast radius.

Fixes: follow-up #4 from #698 (aws-efa v0.5.3 → v0.5.26)
Related: #698, #715

Type of Change

• Bug fix / enhancement (component version refresh)
• Build/CI/tooling (regenerated BOM doc)

Component(s) Affected

• Recipe engine / data (recipes/registry.yaml, recipes/components/aws-efa/values.yaml)
• Docs (docs/user/container-images.md regenerated via make bom-docs)

Implementation Notes

Three changes only:

1. recipes/registry.yaml — defaultVersion: v0.5.3 → v0.5.26
2. recipes/components/aws-efa/values.yaml — image.tag: v0.5.3 → v0.5.18 (chart's bundled appVersion at v0.5.26), plus a long-form comment documenting the intentional divergence from upstream's privileged: true default
3. docs/user/container-images.md — regenerated via make bom-docs

No change to the securityContext block itself — AICR's existing override is preserved verbatim:

securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL
  runAsNonRoot: false

Why upstream went privileged. Starting in chart v0.5.4 AWS switched the daemonset to privileged: true + runAsUser: 0 to cover the full matrix of EFA driver / kernel / OS combinations they support. Their default optimizes for "works everywhere" at the cost of blast radius. AICR optimizes for the narrower OS surface we actually ship, so we can keep narrow caps and still get the fixes.

Revisit triggers documented inline in the values file:

• Plugin logs return operation not permitted on a future EFA driver version
• AICR adds an AL2023 / Bottlerocket / GB200 GPU recipe (the test below only covers Ubuntu)

Testing

make qualify    # all Go unit tests + 20/20 chainsaw + lint + scan: green
make bom-docs   # docs/user/container-images.md regenerated cleanly

Live cluster regression test on EKS aicr2 (account 615299774277, us-east-1, EKS 1.35):

Baseline (chart v0.5.3):

• p5.48xlarge GPU node (ip-10-0-185-161.ec2.internal), Ubuntu 24.04.4, kernel 6.14.0-1018-aws
• DaemonSet aws-efa-k8s-device-plugin 1/1 Running for 13d under AICR's narrow securityContext
• Node advertising vpc.amazonaws.com/efa: 32 in both Capacity and Allocatable

Test procedure:

helm upgrade aws-efa eks/aws-efa-k8s-device-plugin \
  --version v0.5.26 --reuse-values --set image.tag=v0.5.18 -n kube-system

Result:

• New pod came up 1/1 Running in ~30s
• kubectl get pod -o jsonpath='{.spec.containers[0].securityContext}' confirmed AICR's narrow override preserved: {"allowPrivilegeEscalation":false,"capabilities":{"drop":["ALL"]},"runAsNonRoot":false} (no privileged: true)
• Pod logs showed clean EFA enumeration without operation not permitted:

  EfaDeviceTopology initialized successfully with 8 GPUs and 32 EFAs
  GPU topology initialized successfully.
  Starting to serve on /var/lib/kubelet/device-plugins/aws-efa-device-plugin.sock
  Registered device plugin with Kubelet
  

• Node continued advertising vpc.amazonaws.com/efa: 32 in both Capacity and Allocatable

Rolled back via helm rollback aws-efa 1 to restore v0.5.3 — cluster returned to baseline state.

Test scope caveats (also documented in the values file comment):

• Validated only on Ubuntu 24.04 / kernel 6.14 / p5. AICR ships no *-eks-amazonlinux-* or Bottlerocket+EFA GPU recipe today, so a broader OS matrix wasn't tested.
• Test exercised plugin enumeration + Kubelet registration. Actual workload EFA usage (a pod requesting vpc.amazonaws.com/efa: N and doing RDMA traffic) was not validated in this PR — that path uses the workload's securityContext, not the plugin's, so it's out of scope for the chart bump.
• If/when an AL2023 EKS GPU recipe is added, that PR's review should re-validate aws-efa's narrow-cap posture on AL2023 and either confirm the override holds or accept upstream's privileged: true default at that time.

Risk Assessment

• Low — Single component bump, narrow blast radius. Live regression test on the actual deployment target with a documented rollback path. Existing AICR EKS bundles regenerated against this version will run the same securityContext as today, just with a newer binary that picks up 15 app-version increments of upstream fixes.

Rollout notes: Existing AICR-deployed EKS clusters running aws-efa v0.5.3 can helm-upgrade in place by regenerating the bundle and running deploy.sh. The DaemonSet rotates one pod per EFA-capable node (~30s downtime per node for that node's EFA resource advertisement; running pods that already hold EFA allocations are unaffected).

Checklist

• Tests pass locally (make test with -race)
• Linter passes (make lint)
• I did not skip/disable tests to make CI green
• I added/updated tests for new functionality (n/a — version bump only)
• I updated docs if user-facing behavior changed (docs/user/container-images.md regenerated; values-file comment added)
• Changes follow existing patterns in the codebase
• Commits are cryptographically signed (git commit -S)

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: ddb4cdd5-b59e-4b21-a064-94419a27bad0

📥 Commits

Reviewing files that changed from the base of the PR and between a4b2147 and 8f39d75.

📒 Files selected for processing (7)

• docs/user/container-images.md
• pkg/bom/extract_test.go
• recipes/components/aws-efa/values.yaml
• recipes/overlays/eks.yaml
• recipes/registry.yaml
• tests/chainsaw/ai-conformance/cluster/assert-kube-system.yaml
• tests/chainsaw/cli/cuj1-training/mock-snapshot.yaml

---

📝 Walkthrough

Walkthrough

This PR regenerates the container image inventory and updates AWS EFA from chart v0.5.3→v0.5.26 with its device plugin image tag v0.5.3→v0.5.18 (values.yaml), including an added securityContext comment and explicit fields. The EKS overlay and registry default were bumped to v0.5.26. Documentation was updated: BOM counts (22→24 components, 69→71 images), added slinky-slurm-operator and slinky-slurm-operator-crds, and refreshed kubeflow-trainer and network-operator image references.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: bumping aws-efa to v0.5.26 while maintaining AICR's hardened securityContext, which aligns with the primary objective.
Description check	✅ Passed	The description is comprehensive and directly related to the changeset, covering motivation, implementation details, testing, and risk assessment for the aws-efa version bump.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@recipes/registry.yaml`:
- Line 145: defaultVersion is set to a non-existent chart version v0.5.26;
change it to v0.5.25. Open the registry entry containing the defaultVersion key
(look for the line "defaultVersion: v0.5.26") and replace the value v0.5.26 with
v0.5.25 so the registry points to the verified upstream chart release.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: 6d3b6502-d8be-4718-9938-ab571b0ac337

📥 Commits

Reviewing files that changed from the base of the PR and between 6dfbb5d and c641209.

📒 Files selected for processing (3)

• docs/user/container-images.md
• recipes/components/aws-efa/values.yaml
• recipes/registry.yaml

[mchmarny]

Right call on the divergence — keeping the narrow securityContext is the correct posture for AICR's EKS surface, and the values-file comment is one of the better divergence rationales I've seen. CI is fully green (all Tier 2 e2e + KWOK + grype + ClamAV).

One real concern: the live cluster test used helm upgrade --reuse-values, which bypasses chart-default merging — so the new explicit privileged: false and runAsUser: null keys this PR adds weren't actually exercised on cluster. Worth a fresh-install validation before merge since that's the path AICR users actually take. Other notes are minor (BOM doc carries unrelated drift; runAsUser: null literal handling worth asserting in health check).

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

tests/chainsaw/ai-conformance/cluster/assert-kube-system.yaml (1)

22-31: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Add conformance assertions for the hardened container securityContext.

This check currently proves only DaemonSet readiness; it won’t catch regressions back to privileged defaults. Please assert privileged: false, allowPrivilegeEscalation: false, capabilities.drop: [ALL], and runAsUser unset semantics in the DaemonSet template.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/chainsaw/ai-conformance/cluster/assert-kube-system.yaml` around lines
22 - 31, Add conformance assertions to the aws-efa-k8s-device-plugin DaemonSet
template to ensure the hardened container securityContext is enforced: assert
that securityContext.privileged is false,
securityContext.allowPrivilegeEscalation is false,
securityContext.capabilities.drop includes "ALL", and that runAsUser is not set
(or explicitly tests the unset semantics) in the DaemonSet pod spec/template for
the DaemonSet named aws-efa-k8s-device-plugin in namespace kube-system.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@tests/chainsaw/ai-conformance/cluster/assert-kube-system.yaml`:
- Around line 22-31: Add conformance assertions to the aws-efa-k8s-device-plugin
DaemonSet template to ensure the hardened container securityContext is enforced:
assert that securityContext.privileged is false,
securityContext.allowPrivilegeEscalation is false,
securityContext.capabilities.drop includes "ALL", and that runAsUser is not set
(or explicitly tests the unset semantics) in the DaemonSet pod spec/template for
the DaemonSet named aws-efa-k8s-device-plugin in namespace kube-system.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: f0116c7a-2451-4328-a682-f667ef332dfc

📥 Commits

Reviewing files that changed from the base of the PR and between 637ae02 and a4b2147.

📒 Files selected for processing (7)

• docs/user/container-images.md
• pkg/bom/extract_test.go
• recipes/components/aws-efa/values.yaml
• recipes/overlays/eks.yaml
• recipes/registry.yaml
• tests/chainsaw/ai-conformance/cluster/assert-kube-system.yaml
• tests/chainsaw/cli/cuj1-training/mock-snapshot.yaml

[yuanchen8911]

Heads up on the BOM diff Mark flagged: I've split the catch-up out into #878 (pure make bom-docs regen — slinky-slurm BOM rows that #866 missed, plus upstream pytorch + busybox image drift). Will rebase this PR after #878 merges; the BOM diff here will then be just aws-efa rows. Both PRs CI green.