Feature Request: Optional Image-Level Protection to Restrict docker cp for Shared Images.

[mubininnoctive]

Tell us about your request
Introduce an opt-in image-level protection mechanism that allows Docker image authors to request restricted filesystem extraction (e.g. disabling docker cp, docker export, and docker save) at runtime, with explicit acknowledgment or override from the operator.

This would not change Docker’s default behavior, but instead provide a voluntary, transparent way for image authors to raise the bar against casual or accidental extraction of proprietary application code when images are distributed to third parties.

Which service(s) is this request for?

1. Docker Engine
2. Docker CLI
3. Image runtime / container lifecycle behavior

(Primarily relevant to on-prem and offline Docker deployments)

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Docker is increasingly used as a commercial software distribution format, especially for on-prem deployments where the image author and the runtime operator are different parties.

Today, when a Docker image is delivered to a customer:

The container filesystem can always be extracted using:

docker cp

docker export

docker save

This is possible regardless of:

Running containers as non-root

Removing shells

Locking down filesystem permissions

Because the Docker daemon runs as host root, there is no way for image authors to even request limited protection of their filesystem contents.

While we understand Docker’s trust model (host root is trusted), this creates a real challenge for commercial vendors who want to distribute Docker images without making casual code extraction trivial.

The problem is not about preventing a fully malicious administrator, but about:

1. Preventing accidental misuse
2. Raising the bar against casual inspection
3. Making operators explicitly aware when an image requests stronger protections

Are you currently working around the issue?
Current workarounds are all sub-optimal:

1. Legal enforcement and licensing terms (non-technical)
2. Moving to VM-based runtimes (Kata Containers, Firecracker)
3. Avoiding Docker image distribution entirely
4. Obfuscation or encryption inside the container (complex and fragile)

None of these are Docker-native solutions, and most significantly increase operational or maintenance complexity.

Additional context
Proposed idea (opt-in, prompt-based model)
An example approach could be:
An image label or manifest flag, e.g.:

org.docker.security.restrict-copy=true

When present, Docker could:
Prompt the operator at docker run time:

“This image requests restricted filesystem access (disables docker cp / export). Do you want to allow this?”
Or require an explicit override flag:

docker run --allow-fs-extract myimage

Important clarifications

This proposal does not aim to break Docker’s security model
This does not claim to stop a fully malicious host administrator
The goal is opt-in transparency and friction, not absolute protection
Even partial enforcement (e.g. blocking common CLI paths) would be valuable

Why this matters

A Docker-native, opt-in mechanism would:
Improve Docker’s viability as a commercial software delivery platform
Preserve Docker’s existing defaults and principles
Give operators clear visibility and control
Provide meaningful value to vendors distributing proprietary software