Docker Engine 29.2 adds host policy through NRI

Docker Engine 29.2.0, released on January 26, adds experimental Node Resource Interface support. The release notes also introduce an Identity field in image inspection responses. I find these changes interesting because they expose two different parts of the container execution contract. NRI lets host plugins participate in container creation. Image identity gives operators information about where the image contents came from.

My preference remains a multi-stage build ending in a scratch image containing one static Go binary. Docker's repeatable build file and layered image format make that arrangement straightforward to understand. Host-side adjustments introduce another source of configuration, however. I want those adjustments to be explicit enough that the image remains a useful description of the software being shipped.

The first integration has a limited scope

The initial implementation issue describes a deliberately restricted integration. It calls for plugins to modify environment variables and add mounts during container creation. Requests to modify unsupported fields or perform asynchronous updates should return errors. NRI starts disabled by default, and the release labels support experimental.

Those limits matter when interpreting the name. An interface concerned with node resources does not imply that Docker's first implementation supports every resource-management operation a plugin might request. A plugin written for another runtime needs examination against Docker's supported operations. I would begin an evaluation with the exact changes the plugin asks the daemon to apply, including what happens when the daemon rejects a request.

Docker imports containerd's NRI adaptation package in the integration change. That creates a shared implementation dependency for plugin communication. It does not make the host's policy identical across runtimes. Docker still decides which adjustments it supports and how they interact with its own container lifecycle.

The mount integration passes container state to plugins and allows them to modify mounts. An operator evaluating this capability should therefore inspect the resulting container configuration as well as the original request. An image can describe its filesystem contents while a host plugin introduces an additional mount at creation. My concern is whether deployment records explain that additional input well enough to reproduce a problem.

Configuration belongs to the daemon

The configuration pull request adds nri-opts to daemon.json, with an equivalent daemon command-line option. Its example supplies explicit plugin and configuration directories and a listening socket. A configuration shaped like that example is:

{
  "nri-opts": {
    "enable": true,
    "plugin-path": "/path/to/plugins",
    "plugin-config-path": "/path/to/plugin-config",
    "socket-path": "/path/to/nri.sock"
  }
}

These are illustrative paths that an operator must replace. The plugin directory contains executables named with a two-digit prefix, such as 00-my-plugin, which dockerd starts when it starts. Configuration snippets in the second directory pass to those plugins. The socket also permits independently started plugins to connect. That last option gives the deployment another lifecycle to manage because the daemon need not be the process supervisor for every connected plugin.

The same pull request explains that specifying nri-opts in both the configuration file and the daemon flags causes a duplicate-directive error. I would keep these settings in one configuration authority. Splitting related values between service arguments and a JSON file makes an operational change harder to review even before the daemon's duplicate check rejects it.

Reload behavior deserves particular attention. The reload implementation always restarts the NRI adaptation layer when reloading with NRI enabled. Daemon-started plugins restart and synchronize again, which rereads their configuration. Independently started plugins lose their connections and must reconnect and synchronize. A configuration reload therefore includes work that may depend on plugin registration and synchronization time.

For an initial evaluation, I would test a reload while the chosen plugin is connected, then inspect its reconnection behavior. I would also test an unsupported adjustment and check that the failure reaches the operator in a useful form. These are proposed acceptance checks. Docker also adds an NRI section to docker info, giving the operator a place to inspect the integration's status.

Image identity records origin separately from names

The image identity change adds daemon-verified origin information that users cannot rewrite by retagging an image. Its explanation distinguishes local build references, registry repositories associated with pulls, and verified signature properties. These records answer different questions, so a policy needs to examine the kind of identity it receives.

A local build reference can connect an image to BuildKit history. The implementation notes that collecting this reference is new, so it appears only for images built with the change. A pulled image can report the repository it came from using information already stored for existing pulls. Signed provenance provides signature information after verification against trust roots.

For example, the pull request shows this part of an inspection response for a pulled Alpine image:

{
  "Identity": {
    "Pull": [
      {
        "Repository": "docker.io/library/alpine"
      }
    ]
  }
}

That repository record should not be interpreted as an assertion that a particular source revision produced the image. The same implementation shows richer signature properties for signed images, including signer information and source repository details when the signature provides them. I would make an admission rule state which evidence it requires. Otherwise, an application could collapse different forms of origin information into a single boolean and lose the distinction the API supplies.

The implementation also explains why transport matters. Signatures persist through docker save and a subsequent load on another machine. It identifies signatures as the available way to securely identify images created through docker load. An operator moving archives should account for that difference when choosing which identity information to require.

I see a practical connection between these additions, although they remain separate mechanisms. Image identity can explain the origin of the artifact. NRI configuration explains host-side changes requested during container creation. A deployment review that uses both should record the accepted identity evidence and the plugin configuration that applied to the container. For a small static service image, that keeps the additional host behavior visible alongside the build inputs I already care about.