feat(sandbox): add kubectl and aws cli to sbx-templates image

[maxcleme]

Installing these at each sandboxes creation is quite annoying, I'd say it makes sense to include these in the template. WDYT?

[docker-agent]

Assessment: 🟢 APPROVE

[docker-agent]

[medium/security] Mutable image tag used for kubectl COPY source — no digest pin

The COPY --from=registry.k8s.io/kubectl:v1.37.0 instruction references a mutable version tag. If this tag is ever overwritten on the registry, future builds will silently pull a different binary, which is a supply-chain integrity risk. While registry.k8s.io is the official, well-governed Kubernetes registry and the realistic risk of tag mutation for a versioned release tag is low, pinning to an immutable digest fully eliminates the risk.

To fix, pin the image to a specific digest alongside the version tag:

COPY --chmod=0755 --from=registry.k8s.io/kubectl:v1.37.0@sha256:<digest> /bin/kubectl /usr/local/bin/kubectl

You can obtain the digest by running:

crane digest registry.k8s.io/kubectl:v1.37.0

or by checking the image manifest on the registry.

Note: The existing docker/mcp-gateway:v2 line above uses the same mutable-tag pattern, so this is consistent with current project practice — but both lines carry this risk.

Confidence	Score
🟡 moderate	70/100

[aheritier]

I am afraid of the compatibility. K8s is still ensuring the compat with 2 minor versions up and down ?

[docker-agent]

Good point about Kubernetes version skew policy. You're right that digest pinning locks you to the exact binary, preventing even patch-level updates that might improve compatibility or fix bugs.

However, digest pinning doesn't prevent you from updating — it just makes updates explicit. When you need to bump kubectl (for compatibility, security, or features), you'd update both the tag and digest together. The trade-off is: mutable tags give silent updates (convenient but risky), while digest pins give explicit updates (safer but require active maintenance).

For a kubectl client used by Docker Agent, the skew policy means v1.37.0 works with clusters running 1.35–1.38. If you're comfortable with the supply-chain risk from mutable tags (especially since registry.k8s.io is well-governed), and you value the flexibility of automatic patch updates, keeping the tag-only reference is a reasonable choice. Just be aware that if the tag is ever republished, your builds will silently use the new artifact.

[docker-agent]

Assessment: 🟡 NEEDS ATTENTION

One medium-severity finding was identified in the new aws-cli integration lines.

Note: The amazon/aws-cli:2.36.42 Docker Hub tag is also pinned by a mutable tag (same pattern as the open thread on registry.k8s.io/kubectl:v1.37.0 — deduplicated against that existing thread). Consider pinning both to immutable digests together.

misclicked

[docker-agent]

Assessment: 🟢 APPROVE

Lower-confidence findings (not posted inline)

• [medium] Dockerfile:91 — Symlink chain through current may be broken — COPY --from does not dereference symlinks (confidence: weak 40/100)
• [medium] Dockerfile:90 — AWS CLI binary may be incompatible with base image's libc or target architecture (confidence: weak 40/100)

Note: A mutable-tag supply-chain finding for amazon/aws-cli:2.36.42 (the same class of risk as the open thread on kubectl:v1.37.0 at line 89) was identified but suppressed by deduplication since it is already being tracked.