Skip to main content

RFC โ€” Upgrade runtime base Alpine 3.18 (EOL) โ†’ 3.21/3.22

Bucket item: A2 ยท Class: ๐Ÿ”ด Expedite (security) ยท Jira Story: TF-3502 ยท Epic: TF-3500

Context / Problemโ€‹

Alpine 3.18 reached End of Life on 2025-05-01 โ€” it receives no further security fixes. The final runtime image is built FROM alpine:3.18 (Dockerfile:39). Upgrade the runtime base to a supported Alpine (3.21 or 3.22).

This is classed ๐Ÿ”ด Expedite because it is security-facing (an unpatched base OS reaches every paying customer). It is currently backlog; if pulled in flight it must be logged in the bucket README ## Expedite log (WIP โ‰ค 2).

Proposed changeโ€‹

Bump the final-stage base image to a supported Alpine and rebuild the native dependencies against the new musl / OpenSSL.

Execution plan (call to action)โ€‹

  1. Dockerfile:39 โ†’ FROM alpine:3.22 (or 3.21 โ€” pick the newest that all native deps support).
  2. Rebuild native deps against the new musl/OpenSSL: librdkafka, openssl-dev, zstd-dev.
  3. Verify pkg-config paths still resolve in the build stage; fix any moved .pc locations.
  4. Smoke-test the built image: Kafka connectivity (librdkafka), TLS (OpenSSL), and zstd paths.
  5. Scan the new image (Trivy/Grype) to confirm the EOL-base advisories clear.

Risks & rollbackโ€‹

  • Risk: medium โ€” native-dep ABI / musl / OpenSSL differences can break at runtime, not build time; step 4 smoke test is the gate.
  • Rollback: revert the FROM line; but note this returns to an unsupported base โ€” treat rollback as temporary only.

Open questionsโ€‹

  1. Target 3.21 or 3.22? Pick per librdkafka/zstd support in the chosen tag.
  2. Do any pinned apk package versions no longer exist in the new Alpine repo?
  3. Sequence with A1 (Go bump) if the builder image also moves.