diff --git a/content/manuals/dhi/about/available.md b/content/manuals/dhi/about/available.md index 1cf8a16e2d17..84219f7f625c 100644 --- a/content/manuals/dhi/about/available.md +++ b/content/manuals/dhi/about/available.md @@ -34,8 +34,8 @@ requirements: many language ecosystems and enterprise systems. - Alpine-based images: A smaller and more lightweight option using musl libc. - These images are faster to pull and have a reduced footprint, though you may - need to account for musl-glibc differences in some applications. + These images tend to be small and are therefore faster to pull and have a + reduced footprint. Each image maintains a minimal and secure runtime layer by removing non-essential components like shells, package managers, and debugging tools. @@ -52,8 +52,8 @@ with. Debian tends to offer the broadest compatibility. ## Development and runtime variants -To accommodate different stages of the application lifecycle, DHI offers images -in several variants: +To accommodate different stages of the application lifecycle, DHI offers all +language framework images and select application images in two variants: - Development (dev) images: Equipped with necessary development tools and libraries, these images facilitate the building and testing of applications in a diff --git a/content/manuals/dhi/about/test.md b/content/manuals/dhi/about/test.md index 4a8c122a119e..e515864b029b 100644 --- a/content/manuals/dhi/about/test.md +++ b/content/manuals/dhi/about/test.md @@ -23,7 +23,7 @@ The testing process for DHIs focuses on two main areas: - Image standards compliance: Ensuring that each image adheres to strict size, security, and compatibility standards. - Application functionality: Verifying that applications within the images - function correctly and meet expected performance benchmarks. + function correctly. ## Image standards compliance @@ -33,8 +33,8 @@ Each DHI undergoes rigorous checks to meet the following standards: unnecessary components to reduce potential vulnerabilities. - Near-zero known CVEs: Images are scanned using tools like Docker Scout to ensure they are free from known Common Vulnerabilities and Exposures (CVEs). -- Multi-architecture support: DHIs are built for multiple architectures, - including `linux/amd64` and `linux/arm64`, to ensure broad compatibility. +- Multi-architecture support: DHIs are built for multiple architectures + (`linux/amd64` and `linux/arm64`) to ensure broad compatibility. - Kubernetes compatibility: Images are tested to run seamlessly within Kubernetes clusters, ensuring they meet the requirements for container orchestration environments. diff --git a/content/manuals/dhi/about/what.md b/content/manuals/dhi/about/what.md index c0b06429bba5..6952a84b653a 100644 --- a/content/manuals/dhi/about/what.md +++ b/content/manuals/dhi/about/what.md @@ -77,9 +77,9 @@ so you don’t have to. environment while maintaining compatibility with common Linux distributions. They remove non-essential components like shells and package managers to enhance security, yet retain a small base layer built on familiar distribution - standards. You can choose between Alpine-based images (using musl libc) and - Debian-based images (using glibc) to suit your application's compatibility - requirements. + standards. Images are typically available with musl libc (Alpine-based) and + glibc (Debian-based), supporting a broad range of application compatibility + needs. ## Why use Docker Hardened Images? @@ -87,7 +87,7 @@ Docker Hardened Images (DHIs) are secure by default, minimal by design, and maintained so you don't have to. They offer: -- Images built for peace of mind: Ultra-minimal and distroless, DHIs eliminate up to 95 percent of the traditional container attack surface. +- Images built for peace of mind: Ultra-minimal and distroless, DHIs eliminate up to 95% of the traditional container attack surface. - No more patch panic: With continuous CVE scanning and SLA-backed remediation, Docker helps you stay ahead of threats. - Audit-ready images: All DHIs include signed SBOMs, VEX, and provenance that support security and compliance workflows. - Images that work with your stack: Available in Alpine and Debian flavors, DHIs drop into your existing Dockerfiles and pipelines. diff --git a/content/manuals/dhi/how-to/mirror.md b/content/manuals/dhi/how-to/mirror.md index 71c84b906428..7c9b32eff8d1 100644 --- a/content/manuals/dhi/how-to/mirror.md +++ b/content/manuals/dhi/how-to/mirror.md @@ -158,6 +158,21 @@ $ docker push registry.example.com/my-project/: > To continue receiving image updates and preserve access to Docker Hardened > Images, ensure that any copies pushed to other registries remain private. +### Include attestations when mirroring images + +Docker Hardened Images are signed and include associated attestations that +provide metadata such as build provenance and vulnerability scan results. These +attestations are stored as OCI artifacts and are not included by default when +using the Docker CLI to mirror images. + +To preserve the full security context when copying DHIs to another registry, you +must explicitly include the attestations. One tool is `regctl`, which supports +copying both images and their associated artifacts. + +For more details on how to use `regctl` to copy images and their associated +artifacts, see the [regclient +documentation](https://regclient.org/cli/regctl/image/copy/). + ## What's next After mirroring an image repository, you can you can start [using the