ci: sign CI images with ddsign (#4034)

Author: realFlowControl

.gitlab/generate-ci-images.php

@@ -11,9 +11,11 @@
  * matrix value; the `image:` tag (with env vars resolved) is the published tag.
  * This script prints a literal preamble (stages, job templates), then loops
  * over the parsed compose services to emit, per Linux OS, one build matrix job
- * over PHP versions (bake builds and pushes the multi-arch image) plus a manual
- * publish matrix job that mirrors the tags to Docker Hub. Windows is emitted the
- * same way but single-arch (no manifest) with its own build runner/script.
+ * over PHP versions (bake builds and pushes the multi-arch image, then ddsign
+ * signs it) plus a manual publish matrix job that mirrors the tags to Docker
+ * Hub. Windows is emitted the same way but single-arch (no manifest) with its
+ * own build runner/script; its images are signed by a separate Linux job
+ * (ddsign has no Windows binary), see .image_sign.
  */
 
 $root = dirname(__DIR__);
@@ -113,6 +115,11 @@ function parse_compose(string $path, array $env): array
   needs: []
   timeout: 4h
   image: 486234852809.dkr.ecr.us-east-1.amazonaws.com/docker:29.4.0-noble
+  # Requested so `ddsign sign` (run after the push, see script below) can
+  # authenticate as this CI job. https://datadoghq.atlassian.net/wiki/spaces/SECENG/pages/2744681107
+  id_tokens:
+    DDSIGN_ID_TOKEN:
+      aud: image-integrity
   variables:
     DDCI_CONFIGURE_OTEL_EXPORTER: "true"
     # Compile runs on the buildx "ci" builder instance, not this job pod, so the
@@ -138,6 +145,27 @@ function parse_compose(string $path, array $env): array
     IMG_SOURCES: "${CI_REGISTRY_IMAGE}:${TAG}"
     IMG_DESTINATIONS: "dd-trace-ci:${TAG}"
 
+# Signs an already-pushed tag in registry.ddbuild.io. Used for the Windows
+# images: they're built without buildx (see .windows_image_build), so unlike
+# the Linux builds they can't sign via `ddsign --docker-metadata-file` right
+# after the push. Runs on Linux regardless of build platform: it only needs
+# network access to inspect the pushed manifest, not the build runner itself.
+.image_sign:
+  stage: ci-publish
+  rules:
+    - when: manual
+      allow_failure: true
+  needs: []
+  image: 486234852809.dkr.ecr.us-east-1.amazonaws.com/docker:29.4.0-noble
+  tags: ["arch:amd64"]
+  id_tokens:
+    DDSIGN_ID_TOKEN:
+      aud: image-integrity
+  # $TAG is supplied per matrix entry by the generated sign jobs.
+  script:
+    - DIGEST=$(docker buildx imagetools inspect "${CI_REGISTRY_IMAGE}:${TAG}" --format '{{.Manifest.Digest}}')
+    - ddsign sign "${CI_REGISTRY_IMAGE}:${TAG}@${DIGEST}"
+
 .windows_image_build:
   stage: ci-build
   rules:
@@ -250,6 +278,15 @@ function parse_compose(string $path, array $env): array
 <?php foreach ($winServices as $tag): ?>
         - "<?= $tag ?>"
 <?php endforeach; ?>
+
+Windows sign:
+  extends: .image_sign
+  parallel:
+    matrix:
+      - TAG:
+<?php foreach ($winServices as $tag): ?>
+        - "<?= $tag ?>"
+<?php endforeach; ?>
 <?php foreach ($osList as ['name' => $os, 'dir' => $dir, 'services' => $services]): ?>
 <?php /*
   One build job per PHP version. buildx bake reads the x-bake platforms from
@@ -262,13 +299,22 @@ function parse_compose(string $path, array $env): array
   tags: ["arch:amd64"]
   parallel:
     matrix:
-      - PHP_VERSION:
-<?php foreach (array_keys($services) as $svc): ?>
-          - <?= $svc, "\n" ?>
+<?php foreach ($services as $svc => $tag): ?>
+      - PHP_VERSION: "<?= $svc ?>"
+        TAG: "<?= $tag ?>"
 <?php endforeach; ?>
   script:
     - cd <?= $dir, "\n" ?>
-    - docker buildx bake --no-cache --pull --push "${PHP_VERSION}"
+    - METADATA_FILE=$(mktemp)
+    - docker buildx bake --no-cache --pull --push --metadata-file "${METADATA_FILE}" "${PHP_VERSION}"
+    # Unlike `docker buildx build`, `bake` nests its metadata under the target
+    # name instead of writing it flat, so reslice it to what
+    # `ddsign --docker-metadata-file` expects. Take the (only) top-level key
+    # rather than looking up "${PHP_VERSION}" directly: bake sanitizes target
+    # names for the metadata file (e.g. "7.0-alpine" -> "7_0-alpine"), so the
+    # literal name doesn't always match.
+    - jq 'keys[0] as $k | .[$k]' "${METADATA_FILE}" > "${METADATA_FILE}.flat"
+    - ddsign sign "${CI_REGISTRY_IMAGE}:${TAG}" --docker-metadata-file "${METADATA_FILE}.flat"
 <?php /*
   Mirror to Docker Hub: one matrix job per OS, independent (needs: [] via
   .image_publish) so it can sync existing images without rebuilding.

dockerfiles/ci/README.md

@@ -26,6 +26,18 @@ repo.
   build never needs a separate arm64 runner. The job pod only orchestrates;
   the actual compile happens on the builder, and `MAKE_JOBS` sets its
   parallelism.
+* **Signing:** every pushed image is signed with
+  [`ddsign`](https://datadoghq.atlassian.net/wiki/spaces/SECENG/pages/2744681107/Image+Integrity+User+Guide),
+  required for it to be pullable in Kubernetes clusters that enforce image
+  signature verification. Linux images sign right after the `buildx bake`
+  push, using the build's `--metadata-file`. Unlike plain `docker buildx
+  build`, `bake` nests that file's contents under a (sanitized) target name
+  instead of writing it flat, so it's resliced with `jq` first to the shape
+  `ddsign --docker-metadata-file` expects. Windows images are built with plain
+  `docker build` on a native Windows runner that has no `ddsign` binary
+  (ddsign only ships for Linux/Mac), so they're signed by a separate `Windows
+  sign` job that runs on Linux and looks up the pushed tag's digest with
+  `docker buildx imagetools inspect` instead.
 * **Publish:** a `trigger` to the `DataDog/public-images` service mirrors the
   internal image to Docker Hub. It has no dependency on the build (see below).
 
@@ -39,13 +51,17 @@ manually start the `ci-images` job (stage `ci-build`) to spawn the child
 pipeline. Per OS it has two kinds of jobs:
 
 1. **`<OS> build: [<version>]`** (manual) — multi-arch build + push to
-   `registry.ddbuild.io/ci/dd-trace-php/dd-trace-ci:<tag>`. Run the version(s)
-   you need. Authentication to the internal registry is automatic via the
-   runner's native credentials.
+   `registry.ddbuild.io/ci/dd-trace-php/dd-trace-ci:<tag>`, then signs it with
+   `ddsign`. Run the version(s) you need. Authentication to the internal
+   registry is automatic via the runner's native credentials.
 2. **`<OS> publish`** (manual, a matrix with one instance per tag) — mirrors
    `…:<tag>` from the internal registry to the public Docker Hub
    (`datadog/dd-trace-ci`) via a downstream `public-images` pipeline.
 
+Windows has an extra manual job, **`Windows sign`** (a matrix with one
+instance per tag), since `Windows build` can't sign its own images (see
+above). Run it after `Windows build`, before `Windows publish`.
+
 ### Publishing is independent of building
 
 The `publish` jobs have **no dependencies**: they simply sync whatever currently