{"id":3301,"date":"2026-01-25T18:00:20","date_gmt":"2026-01-25T18:00:20","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/01\/25\/making-the-most-of-your-docker-hardened-images-enterprise-trial-part-3\/"},"modified":"2026-01-25T18:00:20","modified_gmt":"2026-01-25T18:00:20","slug":"making-the-most-of-your-docker-hardened-images-enterprise-trial-part-3","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/01\/25\/making-the-most-of-your-docker-hardened-images-enterprise-trial-part-3\/","title":{"rendered":"Making the Most of Your Docker Hardened Images Enterprise Trial \u2013 Part 3"},"content":{"rendered":"

Customizing Docker Hardened Images<\/h2>\n

In Part 1<\/a> and Part 2<\/a>, we established the baseline. You migrated a service to a Docker Hardened Image (DHI)<\/a>, witnessed the vulnerability count drop to zero, and verified the cryptographic signatures and SLSA provenance<\/a> that make DHI a compliant foundation.<\/p>\n

But no matter how secure a base image is, it is useless if you can\u2019t run your application on it. This brings us to the most common question engineers ask during a DHI trial: what if I need a custom image?<\/em><\/p>\n

Hardened images are minimal by design. They lack package managers (apt, apk, yum), utilities (wget, curl), and even shells like bash or sh. This is a security feature: if a bad actor breaks into your container, they find an empty toolbox.<\/p>\n

However, developers often need these tools during setup. You might need to install a monitoring agent, a custom CA certificate, or a specific library.<\/p>\n

In this final part of our series, we will cover the two strategies for customizing DHI: the Docker Hub UI (for platform teams creating \u201cGolden Images\u201d) and the multi-stage build pattern (for developers building applications).<\/p>\n

Option 1: The Golden Image (Docker Hub UI)<\/h3>\n

If you are a Platform or DevOps Engineer, your goal is likely to provide a \u201cblessed\u201d base image for your internal teams. For example, you might want a standard Node.js image that always<\/em> includes your corporate root CA certificate and your security logging agent.The Docker Hub UI<\/a> is the preferred path for this. The strongest argument for using the Hub UI is maintenance automation.<\/p>\n

The Killer Feature: Automatic Rebuilds<\/h3>\n

When you customize an image via the UI, Docker understands the relationship between your custom layers and the hardened base. If Docker releases a patch for the underlying DHI base image (e.g., a fix in glibc or openssl), Docker Hub automatically rebuilds your custom image.<\/p>\n

You don\u2019t need to trigger a CI pipeline. You don\u2019t need to monitor CVE feeds. The platform handles the patching and rebuilding, ensuring your \u201cGolden Image\u201d is always compliant with the latest security standards.<\/p>\n

How It Works<\/h3>\n

Since you have an Organization setup for this trial, you can explore this directly in Docker Hub.First, navigate to Repositories<\/strong> in your organization dashboard. Locate the image you want to customize (e.g., dhi-node), then the Customizations tab and click the \u201cCreate customization\u201d action. This initiates a customization workflow as follows:<\/p>\n

\n \"Screenshot\n <\/div>\n

In the \u201cAdd packages\u201d section, you can search for and select OS packages directly from the distribution\u2019s repository. For example, here we are adding bash to the image for debugging purposes. You can also add \u201cOCI Artifacts\u201d to inject custom files like certificates or agents.<\/p>\n

\n \"Screenshot\n <\/div>\n

Finally, configure the runtime settings (User, Environment Variables) and review your build. Docker Hub will verify the configuration and queue the build. Once complete, this image will be available in your organization\u2019s private registry and will automatically rebuild whenever the base DHI image is updated.<\/p>\n

\n \"Screenshot\n <\/div>\n

This option is best suited for creating standardized \u201cgolden\u201d base images that are used across the entire organization. The primary advantage is zero-maintenance security patching<\/strong> due to automatic rebuilds by Docker Hub. However, it is less flexible for rapid, application-specific iteration by individual development teams.<\/p>\n

Option 2: Multi-Stage Build<\/h2>\n

If you are an developper, you likely define your environment in a Dockerfile that lives alongside your code. You need flexibility, and you need it to work locally on your machine.<\/p>\n

Since DHI images don\u2019t have apt-get or curl, you cannot simply RUN apt-get install my-lib in your Dockerfile. It will fail.<\/p>\n

Instead, we use the multi-stage build pattern. The concept is simple:<\/p>\n

    \n
  1. Stage 1 (Builder): Use a standard \u201cfat\u201d image (like debian:bookworm-slim) to download, compile, and prepare your dependencies.<\/li>\n
  2. Stage 2 (Runtime): Copy only<\/em> the resulting artifacts into the pristine DHI base.<\/li>\n<\/ol>\n

    This keeps your final image minimal, non-root, and secure, while still allowing you to install whatever you need.<\/p>\n

    Hands-on Tutorial: Adding a Monitoring Agent<\/h3>\n

    Let\u2019s try this locally. We will simulate a common real-world scenario: adding the Datadog APM library (dd-trace) globally to a Node.js DHI image.<\/p>\n

    1. Setup<\/h4>\n

    Create a new directory for this test and add a simple server.js file. This script attempts to load the dd-trace library to verify our installation.<\/p>\n

    app\/server.js<\/p>\n

    \n
    \n\/\/ Simple Express server to demonstrate DHI customization\nconsole.log('Node.js version:', process.version);\ntry {\n  require('dd-trace');\n  console.log('dd-trace module loaded successfully!');\n} catch (e) {\n  console.error('Failed to load dd-trace:', e.message);\n  process.exit(1);\n}\nconsole.log('Running as UID:', process.getuid(), 'GID:', process.getgid());\nconsole.log('DHI customization test successful!');\n\n<\/pre>\n<\/div>\n
    2. Hardened Dockerfile<\/h4>\n
    Now, create the Dockerfile. We will use a standard Debian image to install the library, and then copy it to our DHI Node.js image. Create a new directory for this test and add a simple server.js file. This script attempts to load the dd-trace library to verify our installation.<\/p>\n
    \n
    \n# Stage 1: Builder - a standard Debian Slim image that has apt, curl, and full shell access.\nFROM debian:bookworm-slim AS builder\n\n\n# Install Node.js (matching our target version) and tools\nRUN apt-get update &amp;&amp; \n    apt-get install -y curl &amp;&amp; \n    curl -fsSL https:\/\/deb.nodesource.com\/setup_24.x | bash - &amp;&amp; \n    apt-get install -y nodejs\n\n\n# Install Datadog APM agent globally (we force the install prefix to \/usr\/local so we know exactly where files go)\nRUN npm config set prefix \/usr\/local &amp;&amp; \n    npm install -g dd-trace@5.0.0\n\n\n# Stage 2: Runtime - we switch to the Docker Hardened Image.\nFROM &lt;your-org-namespace&gt;\/dhi-node:24.11-debian13-fips\n\n\n# Copy only the required library from the builder stage\nCOPY --from=builder \/usr\/local\/lib\/node_modules\/dd-trace \/usr\/local\/lib\/node_modules\/dd-trace\n\n\n# Environment Configuration\n# DHI images are strict. We must explicitly tell Node where to find global modules.\nENV NODE_PATH=\/usr\/local\/lib\/node_modules\n\n\n# Copy application code\nCOPY app\/ \/app\/\n\n\nWORKDIR \/app\n\n\n# DHI Best Practice: Use the exec form ([\"node\", ...]) \n# because there is no shell to process strings.\nCMD [\"node\", \"server.js\"]\n\n<\/pre>\n<\/div>\n
    3. Build and Run<\/h4>\n
    Build the custom image:<\/p>\n
    \n
    \ndocker build -t dhi-monitoring-test .\n<\/pre>\n<\/div>\n
    Now run it. If successful, the container should start, find the library, and exit cleanly.<\/p>\n
    \n
    \ndocker run --rm dhi-monitoring-test\n<\/pre>\n<\/div>\n
    Output:<\/p>\n
    \n
    \nNode.js version: v24.11.0\ndd-trace module loaded successfully!\nRunning as UID: 1000 GID: 1000\nDHI customization test successful!\n\n<\/pre>\n<\/div>\n
    Success! We have a working application with a custom global library, running on a hardened, non-root base.<\/p>\n
    Security Check<\/h2>\n
    We successfully customized the image. But did we compromise its security?<\/p>\n
    This is the most critical lesson of operationalizing DHI: hardened base images protect the OS, but they do not protect you from the code you add.Let\u2019s verify our new image with Docker Scout<\/a>.<\/p>\n
    \n
    \ndocker scout cves dhi-monitoring-test --only-severity critical,high\n<\/pre>\n<\/div>\n
    Sample Output:<\/p>\n
    \n
    \n    \u2717 Detected 1 vulnerable package with 1 vulnerability\n...\n   0C     1H     0M     0L  lodash.pick 4.4.0           \npkg:npm\/lodash.pick@4.4.0                               \n                                                        \n    \u2717 HIGH CVE-2020-8203 [Improperly Controlled Modification of Object Prototype Attributes]\n\n<\/pre>\n<\/div>\n
    This result is accurate and important. The base image (OS, OpenSSL, Node.js runtime) is still secure. However, the dd-trace library we just installed pulled in a dependency (lodash.pick) that contains a High severity vulnerability.<\/p>\n
    This proves that your verification pipeline works.<\/p>\n
    If we hadn\u2019t scanned the custom<\/em> image, we might have assumed we were safe because we used a \u201cHardened Image.\u201d By using Docker Scout on the final artifact, we caught a supply chain vulnerability introduced by our<\/em> customization.<\/p>\n
    Let\u2019s check how much \u201cbloat\u201d we added compared to the clean base.<\/p>\n
    \n
    \ndocker scout compare --to &lt;your-org-namespace&gt;\/dhi-node:24.11-debian13-fips dhi-monitoring-test\n\n<\/pre>\n<\/div>\n
    You will see that the only added size corresponds to the dd-trace library (~5MB) and our application code. We didn\u2019t accidentally inherit apt, curl, or the build caches from the builder stage. The attack surface remains minimized.<\/p>\n
    A Note on Provenance: Who Signs What?<\/h2>\n
    In Part 2, we verified the SLSA Provenance and cryptographic signatures of Docker Hardened Images. This is crucial for establishing a trusted supply chain. When you customize an image, the question of who \u201cowns\u201d the signature becomes important.<\/p>\n
      \n
    1. Docker Hub UI Customization<\/strong>: When you customize an image through the Docker Hub UI, Docker itself acts as the builder for your custom image. This means the resulting customized image inherits signed provenance and attestations directly from Docker\u2019s build infrastructure. If the base DHI receives a security patch, Docker automatically rebuilds and re-signs your custom image, ensuring continuous trust. This is a significant advantage for platform teams creating \u201cgolden images.\u201d<\/li>\n<\/ol>\n
        \n
      1. Local Dockerfile<\/strong>: When you build a custom image using a multi-stage Dockerfile locally (as we did in our tutorial), you<\/em> are the builder. Your docker build command produces a new<\/em> image with a new<\/em> digest. Consequently, the original DHI signature from Docker does not apply to your final custom image (because the bits have changed and you are the new builder).
        However, the chain of trust is not entirely broken:<\/li>\n<\/ol>\n