chore: migrate base images to Chainguard - #5
Conversation
Replace public base images with Chainguard equivalents from cgr.dev/spotdraft.com. - Uses -fips variants where available - Build stages use :latest-dev (shell available) - Runtime stages use :latest (minimal) - Platform pinned to linux/amd64
![baz-reviewer[bot]](https://avatars.githubusercontent.com/in/933528?s=60&v=4){kind=small}
| # the platform/security team to publish a runner image for this service first. | ||
| # Track as a follow-up ticket. | ||
| FROM python:3.12-slim | ||
| FROM --platform=linux/amd64 cgr.dev/spotdraft.com/python-fips:3.12 |
There was a problem hiding this comment.
cgr.dev/spotdraft.com/python-fips:3.12 is a minimal runtime image without /bin/sh, but the Dockerfile still runs shell-form RUN uv sync --locked --no-install-project, so the build fails before /app/.venv or a runnable image is produced — should we run uv sync in the documented 3.12-dev/latest-dev builder stage and copy the resulting venv into this runtime stage?
Want Baz to fix this for you? Activate Fixer
Prompt for AI Agents
Before applying, verify this suggestion against the current code. In Dockerfile around
line 9 (`FROM --platform=linux/amd64 cgr.dev/spotdraft.com/python-fips:3.12`), this
minimal runtime image has no `/bin/sh`, but the rest of the Dockerfile still runs
shell-form commands like `RUN uv sync --locked --no-install-project` which require a
shell, so the build fails before producing a runnable image. Refactor into a multi-stage
build: use the documented `3.12-dev` (or `latest-dev`) image as a builder stage where
`uv sync` runs and the venv is created, then copy the resulting `/app/.venv` (and any
needed app files) into the minimal `python-fips:3.12` runtime stage, ensuring the final
image can start Uvicorn without relying on `/bin/sh -c`. Verify the artifact paths you
copy match where `uv sync` actually writes them, and confirm the runtime stage has
whatever executables are needed to run without a shell.
|
✅ Dockerfile(s) updated to pull from GCP Artifact Registry ( |
| # the platform/security team to publish a runner image for this service first. | ||
| # Track as a follow-up ticket. | ||
| FROM python:3.12-slim | ||
| FROM --platform=linux/amd64 us-central1-docker.pkg.dev/spotdraft-qa/sd-us-chainguard/python-fips:3.12 |
There was a problem hiding this comment.
FROM us-central1-docker.pkg.dev/spotdraft-qa/sd-us-chainguard/python-fips:3.12 replaces python:3.12-slim but is both unauthenticated-inaccessible and tag-only, so builders without Artifact Registry access fail entirely, and even authenticated builds can silently pick up a different image if the tag moves on the registry. Should we pin this to the approved @sha256:... digest (or lock it via the deployment pipeline) and update the README's stale docker build -t tars ./python:3.12-slim references to document the required registry login and network access?
Want Baz to fix this for you? Activate Fixer
Prompt for AI Agents
Before applying, verify this suggestion against the current code. In Dockerfile around
line 9, the `FROM` instruction was changed from `python:3.12-slim` to
`us-central1-docker.pkg.dev/spotdraft-qa/sd-us-chainguard/python-fips:3.12`, which is
(a) not publicly resolvable without Artifact Registry authentication, and (b) referenced
by a mutable tag with no digest pin, so a registry tag move can silently change what
gets built. 1. Replace the FROM line to reference the approved immutable `@sha256:...`
digest for `python-fips:3.12` (or ensure the deployment/build pipeline resolves and
locks to an immutable promoted digest per org policy). 2. Update the project's developer
documentation (README and any migration/workflow text) to explicitly state the required
`docker login`/GCP Artifact Registry permissions and any required network/VPC access
before `docker build -t tars .` will succeed. Remove any claim that `python:3.12-slim`
is the base image or that the build works without registry login. Verify the resulting
image builds reproducibly and matches the approved security baseline.
2 participants
User description
Summary
cgr.dev/spotdraft.com:latest-dev(includes shell):latest(minimal, no shell)linux/amd64Images updated
See Dockerfile diffs above.
🤖 Generated by chainguard-migrate.sh
Generated description
Below is a concise technical summary of the changes proposed in this PR:
Migrate the Python runtime to the Chainguard FIPS image while pinning builds to
linux/amd64. Preserve the existing Python environment configuration for the FastAPI service.Latest Contributors(2)