Provide a way to lock ENTRYPOINT

[brunoborges]

Unless I missed something, it is not possible to create an image and lock down ENTRYPOINT. With the following command, a user can bypass any instruction that may be required by the image to be performed in order to properly execute:

    $ docker run --entrypoint some-other-existing-script.sh someimage

It must be possible for an image author to define and lock an entrypoint to make sure a given image is executed by only calling that entrypoint definition and whatever operations that call allows.

It is also important to ensure that the ENTRYPOINT of an image is always called, either when creating a new container out of this image, or of an extended image. To verify this use case, I created this Test Scenario. Run the script test.sh.

Here's the output:

bruno@lenovo:~/test-lock-entrypoint$ sh test.sh 
Untagged: entrypoint:latest
Untagged: overridden:latest
Deleted: ccbeaae06c6d9236727cfa0293e26acaa912df691f7dfa9014b31d02148de66f
Deleted: 590ab72673b0e94d815d0370b53c358dce108b9c26366d32ddc70640a0909e6f
Deleted: 1427d84e7af9c86d173e852157389c7bf650d9b4e1b953e8516a15f6111cd933
Deleted: 05efde4dcccc7f9c8fdb167467424543453dbd2ade7575b316ceb3678a821932
Deleted: 2887b23be62d48d530b077e9530af2795938d9d4c528f633a3b2242d82ac3c37
Deleted: 1e625e037281571d3fd2ea08d677a56d05ae2adcbe8c566d9379281254a8d4e6
Deleted: 1c0d1742c5c7cd50be97309f3808b356bdfa1047d90a340833fe3818d8532d11
Deleted: 02c6919bae7562f30ab264c9ad68583d13d507f93b41fdc750f3f2336a38c032
Sending build context to Docker daemon 6.656 kB
Step 1 : FROM alpine
 ---> d6ead20d5571
Step 2 : COPY verify.sh ./
 ---> 883e7c374571
Removing intermediate container 83006da82f39
Step 3 : RUN chmod +x verify.sh
 ---> Running in 3ba6771d6b7b
 ---> b3fb87b1bd67
Removing intermediate container 3ba6771d6b7b
Step 4 : ENTRYPOINT ./verify.sh
 ---> Running in 3aaa08502726
 ---> e7aeda0d084d
Removing intermediate container 3aaa08502726
Step 5 : CMD sh
 ---> Running in 5acf82a75b52
 ---> 652c119975c7
Removing intermediate container 5acf82a75b52
Successfully built 652c119975c7
Sending build context to Docker daemon 6.656 kB
Step 1 : FROM entrypoint
 ---> 652c119975c7
Step 2 : COPY overridden.sh ./
 ---> a8ece7704616
Removing intermediate container a6e3bc1666d5
Step 3 : RUN chmod +x overridden.sh
 ---> Running in 2506fca8cb7d
 ---> d29bff80ded7
Removing intermediate container 2506fca8cb7d
Step 4 : ENTRYPOINT ./overridden.sh
 ---> Running in 2bb4f06c0d6e
 ---> 014226640ad5
Removing intermediate container 2bb4f06c0d6e
Step 5 : CMD sh
 ---> Running in bddb37662abb
 ---> 6e7eb9b1d4c6
Removing intermediate container bddb37662abb
Successfully built 6e7eb9b1d4c6


Docker run 'entrypoint' without VAR=ok must fail:
[entrypoint/verify.sh] Verifying variable VAR...
[entrypoint/verify.sh] Missing $VAR=ok
Test passed


Docker run 'entrypoint' with VAR=ok must pass:
[entrypoint/verify.sh] Verifying variable VAR...
[entrypoint/verify.sh] variable exists and it is 'ok'
Test passed


Docker run 'overridden' without VAR=ok must fail:
[overridden/overridden.sh] Overridden entrypoint. Should be OK to display this, but not without '-e VAR=ok'
Test failed.


Docker run 'overridden' with VAR=ok must pass:
[overridden/overridden.sh] Overridden entrypoint. Should be OK to display this, but not without '-e VAR=ok'
Test passed
bruno@lenovo:~/test-lock-entrypoint$ 

[thaJeztah]

I'm -1 on this; users of an image should be able to use that image in any way they want. Overriding an entrypoint is not something that's easily done "by accident" (you'd have to explicitly provide the --entrypoint flag).

Also, this wouldn't prevent users from using the image as FROM in a Dockerfile, and override the entrypoint.

However, I can see organizations where you don't want users to override entrypoints. With the "Authz" plugins feature, that will be part of 1.10, it would be possible to deny users to override entrypoints, depending on their role; #15365

[brunoborges]

@thaJeztah are you -1 as a user, or as image author? As a user, I understand, but this is a feature for image authors.

Image authors already decide what goes inside the image they are building. How is it a negative thing to empower them with the right to decide how their images must be executed? Besides, it is a request for an optional parameter image authors may or may not use. If a power user wants to complain for some reason, the user contacts the image author.

Now, in my first comment, if you had read it through, I do mention that such feature must guarantee that inherited images may define their own ENTRYPOINTS, but the entry point of the FROM image must be performed. This raises question tough on how to also lock some files/folders in a way that inherited images can't modify these with some RUN command. Which brings us to issue #18812.

This is an important feature for image authors.

[thaJeztah]

Well, I'm looking for a use case; point is that IMO this should be a documentation issue ("how to use this image"). If the thought here is to implement a "copy protection" system, I'm just not sure this would work. Users can compile their own version of docker that ignores the "don't override" part, or simply export the image, modify the layers, and import the image again.

Just my 0.02c, others may think differently.

[m0un10]

As an image author, I use sensible defaults in my environment variables so that it works for them out-of-the-box without the user needing to decide on how their image must be executed.

When you look at the documentation for official images, it is all centered around using ENV variables at deploy-time to allow images to be customised in a supported way and to provide the contract between the image author and the user.

The use case isn't clear to me but I could also be missing something. Is it possible to provide an example scenario where having this feature could add value for the user?

If it's just about the image author then I would put a -1 on this as well. That's only because in my own experience I've never had a problem with someone being upset with my image because they stepped off the beaten track and tried to override the ENTRYPOINT and it broke things. I'm not saying that doesn't happen but it seems to be an extreme edge case, at least in my experience.

[vdemeester]

I'm -1 on this, same as @thaJeztah said, as a user and as image author. I'm also looking for a use case, and I feel that "Authz" will cover most of this. In the end, the image is just a rootfs, it feels like it would be pretty easy to bypass this by exporting a container from this image and re-importing it (just a tiny bit more complicated than --entrypoint) — thus it feels like an overly complicated thing to implement (which could lead to bugs, …) for no gain in the end.

Image authors already decide what goes inside the image they are building. How is it a negative thing to empower them with the right to decide how their images must be executed?

For me it sounds like asking Linux distribution builder (debian/redhad/…) "that already decide what goes inside the distribution they are building", that they should be able to decide how their distribution must be executed (locking down the user) — but well, if you are root on the machine you can pretty much messing it up and doing whatever you want. That's the beauty of it so I really don't see the point.

I feel the same about that it is a documentation issue on "how to use this image" ("This image is intended to be used like that […]."). You can provides default sane behavior and a good documentation on how to run the image and how to configure/custom the runtime (i.e. container), but locking down user, it should be separate from the image (by engine/cluster) — hence the "Authz" stuff. Docker is almost all about separation of concern after all.

[calavera]

It looks like there is an agreement among maintainers. I'm sorry but we're not going to implement this.

Thanks for taking your time to write it. It's always good to hear from the community.