chore: migrate base images to Chainguard - #1
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}
| # Stage 1: Define base image that will be used for production | ||
|
|
||
| FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base | ||
| FROM --platform=linux/amd64 cgr.dev/spotdraft.com/dotnet-runtime:6.0-dev AS base |
There was a problem hiding this comment.
base pulls the mutable, dev-tooling cgr.dev/spotdraft.com/dotnet-runtime:6.0-dev tag and final inherits from it, so production is deployed with dev tooling and its runtime can change silently whenever :6.0-dev is retagged, since .github/workflows/main.yaml neither pins nor verifies its digest — should we switch base to the approved non-dev runtime tag pinned to its reviewed digest (moving any build-only tools to a separate -dev stage) and add signature/provenance verification in the pipeline?
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 3 (`FROM --platform=linux/amd64 cgr.dev/spotdraft.com/dotnet-runtime:6.0-dev AS
base`), the `base` stage is inherited by `final`, so production deploys with dev tooling
and is exposed to a mutable, unverified tag. Fix by switching `base` to the approved
non-dev runtime tag pinned to its exact reviewed digest (moving any build-only tools
needed for `dotnet publish` into a separate `-dev` stage used only during build), and
update `.github/workflows/main.yaml` to verify image provenance/signature (e.g.
cosign/SLSA) for the pinned base before building/pushing. Confirm no other stage still
propagates the `-dev` tag into `final`, and keep base selection consistent across stages
so the final image is reproducibly tied to the reviewed digest.
There was a problem hiding this comment.
Commit 45b071a addressed this comment by switching the production base from a dev/runtime image to a non-dev dotnet-runtime image. However, it still uses the mutable :latest tag and adds no digest pinning or provenance/signature verification.
These Dockerfile lines were left unchanged. |
| # Stage 1: Define base image that will be used for production | ||
|
|
||
| FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base | ||
| FROM --platform=linux/amd64 us-central1-docker.pkg.dev/spotdraft-qa/sd-us-chainguard/dotnet-runtime:latest AS base |
There was a problem hiding this comment.
This FROM switches to a private us-central1-docker.pkg.dev/.../dotnet-runtime:latest image, but .github/workflows/main.yaml only authenticates to ghcr.io, so docker/build-push-action will fail with a 401 while resolving the base image. Even if pulled, that image is runtime-only and lacks Microsoft.AspNetCore.App, which datadog-rum-proxy.csproj (targeting net6.0 with Microsoft.NET.Sdk.Web) needs for its framework-dependent publish, so dotnet datadog-rum-proxy.dll would fail with a missing framework error — should we add scoped Artifact Registry auth to the workflow and switch to an ASP.NET-capable, version-pinned image (or publish self-contained)?
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 3 (`FROM --platform=linux/amd64
us-central1-docker.pkg.dev/.../dotnet-runtime:latest AS base`), two issues need
addressing: 1. Authentication: The build depends on a private Google Artifact Registry
image, but `.github/workflows/main.yaml` only authenticates to `ghcr.io` before
`docker/build-push-action` runs. Update the workflow to authenticate to the Artifact
Registry repository (via service account/Workload Identity) with scoped read permission
for the `us-central1` repo, or switch to a publicly pullable, approved base image (e.g.,
the existing `mcr.microsoft.com/...` one) if auth isn't feasible. 2. Runtime
compatibility: `datadog-rum-proxy.csproj` targets `net6.0` with `Microsoft.NET.Sdk.Web`
and is framework-dependent published, but the `dotnet-runtime` image lacks the
`Microsoft.AspNetCore.App` shared framework needed to run it. Replace the base image
with an ASP.NET-capable image explicitly pinned to a .NET 6.x version (providing
`Microsoft.AspNetCore.App`), ensuring the subsequent stage still runs the same published
`datadog-rum-proxy.dll` entrypoint. Alternatively, change the build/publish to produce a
self-contained deployment for .NET 6 and copy/run that self-contained output instead.
1 participant
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 production container base from Microsoft’s ASP.NET image to the Chainguard .NET runtime image. Pin the build platform to
linux/amd64while preserving the application entrypoint and runtime deployment flow.Latest Contributors(2)