<p>If your client is ready to invest money then you should go with Docker enterprise edition. In Docker EE you have one tool that is <code>UCP(Universal Control Plane)</code> <a href="https://docs.docker.com/datacenter/ucp/1.1/" rel="nofollow noreferrer">UCP</a>. By UCP you can create roles and access rights and restrict the user to change/modify containers.</p>
<p>If you want to test UCP than DDC(Docker Data Center) having one month trial license which will help you to elaborate the things as per your requirements.</p>

CC BY-SA 3.0
2017-05-10T11:47:56.873Z
As the solution about docker groups, this works if you do manage the docker host system only, OP sounds more like distributing an image...
Tensibai
CC BY-SA 4.0
2017-05-10T11:41:45.593Z
2021-02-09T14:07:44.433Z
2021-02-09T14:07:44.433Z
chintan thakar
<p>You can remove the users from the docker group and create sudos for the <code>docker start</code> and <code>docker stop</code>. </p>

CC BY-SA 3.0
2017-05-07T00:02:50.297Z
only possible/effective if you own those servers...
Dan Cornilescu
CC BY-SA 3.0
2017-05-06T12:35:11.487Z
2017-05-06T12:35:11.487Z
user2590
<p>Give your delivery via ansible scripts. Keep all sort of restrictions and checks in the ansible script. </p>

CC BY-SA 3.0
2017-07-28T12:47:11.697Z
How would this prevent access to the container? Try yo explain how your proposition would actually solve OP's problem.
Michaël Le Barbier
CC BY-SA 3.0
2017-07-28T12:24:51.660Z
2017-07-28T12:24:51.660Z
lakshayk
<p>In short, you cannot prevent your customers from modifying containers they run in their own infrastructure.  Containers are not like binaries that can be obfuscated; they are runtime environments.  The code you distribute inside the container, however, can be obfuscated.</p>

<p>Your question alludes to a third-party support issue: clients modifying software they run in their own environments.  If you provide tools to <em>operate</em> the containers you supply (e.g. monitoring and logging) then the clients should agree (as part of a software license) not to make unauthorized modifications to them.  This applies to all types of third-party software, not just containers.  </p>

<p>Depending on your situation, you may also have the option to provide your app as Software As A Service (SaaS) running in a cloud infrastructure.</p>

<p>If your client requires your containers be run on their infrastructure, and refuses to abide by modification restrictions, then you probably don't want to try to support their use of your software.</p>

CC BY-SA 3.0
2017-05-06T21:31:31.310Z
2017-05-06T21:31:31.310Z
Dave Swersky
<p>Docker doesn't provide any means to preclude user access to the container, however as the image developer you could follow a few strategy </p>

<ul>
<li>Obfuscate your software (ruby, python and etc)</li>
<li>Build your image from a base image that doesn't have shell, and other binaries that the user can use to tramper the image.</li>
</ul>

<p>Of course they can always export the container and repackage it but those are extreme measures... </p>

CC BY-SA 4.0
2018-09-07T06:56:24.563Z
Why are Ruby and Python given as examples for obfuscating code? Code in those languages are usually kept as clear-text source files on the executing OS. Wouldn't it be preferred to use a compiled language like C++, C#, Java or one which can be "minified" like JS?
AjaxLeung
CC BY-SA 4.0
2020-04-20T10:59:43.597Z
@AjaxLeung sorry for necroposting :)
echo "print('Hello')" > test.pyx;
cython test.pyx --embed;
gcc -Os -I /usr/include/python3.8/ -o test test.c -lpython3.8 -lpthread -lm -lutil -ldl
Michael A.
CC BY-SA 3.0
2017-07-31T07:12:52.350Z
2017-07-31T07:12:52.350Z
Jeeva
<p>You have no problem at the first place. An image in Docker is not like a monolithic ISO. It has layers. And layers in Docker, when you run them, are immutable. </p>

<p>For example: </p>

<ul>
<li>Somebody built Alpine image with hash abc123</li>
<li>Then somebody build a Python image based on Alpine (FROM alpine:abc123) with hash def456.</li>
<li>Now you've build your image atop of Python (FROM python:def456) and result in hash ghi789.</li>
</ul>

<p>Now your customer is pulling the image: </p>

<pre><code>docker pull flask:ghi789
</code></pre>

<p>When he runs his container he gets three read-only layers in memory (abc123, def456 and ghi789) and one new read-write layer jkl357 that is initially empty. It will be filled later with some data during app activity, for example - logs, or external connections like "docker exec ...".
Thus, no matter what customer does in his new layers, all precommitted layers are safe.</p>

<p>The layer jkl357 become immutable (readonly) only upon commit. But this is already not your image SHA and not related to you app:</p>

<pre><code>docker commit -t my-altered-flask:tag
</code></pre>

<hr>

<p>All said is relevant unless your goal is to protect from modifying, not from read at all.</p>

CC BY-SA 4.0
2020-04-20T11:13:47.757Z
2020-04-20T11:18:55.433Z
2020-04-20T11:18:55.433Z
Michael A.
<p>I want to deliver my app to customers in form of docker image. But it is crucial to ensure that end-user do not alter anything inside the container. User should only be able to run/stop the container and interact with the container via network.</p>

<p>Is it possible to prohibit access to internals of container?
Is it possible to verify integrity of image that container made from?</p>

CC BY-SA 3.0
2017-05-06T16:33:53.910Z
Unless you do manage the docker host I believe you can't. What problem are you willing to solve by preventing this access?
Tensibai
CC BY-SA 3.0
2017-05-06T16:40:06.627Z
As Tensibai mentions, it depends. If you **need** to know that the container is unmodified for security reasons, you basically have to run it on your own servers. If you just want to discourage people from modifying it so they don't break things, there probably are ways you could do that. Describing your use case will help here.
Aurora0001
<docker><security>
How to prohibit access to internals of Docker container?
Victor Mezrin
# How to prohibit access to internals of Docker container?

(Asked by: username_0 on 2017-05-06)

I want to deliver my app to customers in form of docker image. But it is crucial to ensure that end-user do not alter anything inside the container. User should only be able to run/stop the container and interact with the container via network.

Is it possible to prohibit access to internals of container?
Is it possible to verify integrity of image that container made from?

**Tags:** docker, security

> **Comments:**
> **username_1**: Unless you do manage the docker host I believe you can't. What problem are you willing to solve by preventing this access?  
> **username_2**: As username_1 mentions, it depends. If you **need** to know that the container is unmodified for security reasons, you basically have to run it on your own servers. If you just want to discourage people from modifying it so they don't break things, there probably are ways you could do that. Describing your use case will help here.  

---

## 6 answers

### Answer by username_8 on 2017-05-06. Score: 18

In short, you cannot prevent your customers from modifying containers they run in their own infrastructure. Containers are not like binaries that can be obfuscated; they are runtime environments. The code you distribute inside the container, however, can be obfuscated.

Your question alludes to a third-party support issue: clients modifying software they run in their own environments. If you provide tools to *operate* the containers you supply (e.g. monitoring and logging) then the clients should agree (as part of a software license) not to make unauthorized modifications to them. This applies to all types of third-party software, not just containers.

Depending on your situation, you may also have the option to provide your app as Software As A Service (SaaS) running in a cloud infrastructure.

If your client requires your containers be run on their infrastructure, and refuses to abide by modification restrictions, then you probably don't want to try to support their use of your software.


---

### Answer by username_9 on 2017-07-31. Score: 9

Docker doesn't provide any means to preclude user access to the container, however as the image developer you could follow a few strategy

* Obfuscate your software (ruby, python and etc)
* Build your image from a base image that doesn't have shell, and other binaries that the user can use to tramper the image.

Of course they can always export the container and repackage it but those are extreme measures...

> **Comments:**
> **username_10**: Why are Ruby and Python given as examples for obfuscating code? Code in those languages are usually kept as clear-text source files on the executing OS. Wouldn't it be preferred to use a compiled language like C++, C#, Java or one which can be "minified" like JS?  
> **username_11**: @username_10 sorry for necroposting :) echo "print('Hello')" > test.pyx; cython test.pyx --embed; gcc -Os -I /usr/include/python3.8/ -o test test.c -lpython3.8 -lpthread -lm -lutil -ldl  

---

### Answer by username_3 on 2017-05-10. Score: 6

If your client is ready to invest money then you should go with Docker enterprise edition. In Docker EE you have one tool that is `UCP(Universal Control Plane)` [UCP](https://docs.docker.com/datacenter/ucp/1.1/). By UCP you can create roles and access rights and restrict the user to change/modify containers.

If you want to test UCP than DDC(Docker Data Center) having one month trial license which will help you to elaborate the things as per your requirements.

> **Comments:**
> **username_1**: As the solution about docker groups, this works if you do manage the docker host system only, OP sounds more like distributing an image...  

---

### Answer by username_4 on 2017-05-06. Score: 5

You can remove the users from the docker group and create sudos for the `docker start` and `docker stop`.

> **Comments:**
> **username_5**: only possible/effective if you own those servers...  

---

### Answer by username_6 on 2017-07-28. Score: 2

Give your delivery via ansible scripts. Keep all sort of restrictions and checks in the ansible script.

> **Comments:**
> **username_7**: How would this prevent access to the container? Try yo explain how your proposition would actually solve OP's problem.  

---

### Answer by username_11 on 2020-04-20. Score: 0

You have no problem at the first place. An image in Docker is not like a monolithic ISO. It has layers. And layers in Docker, when you run them, are immutable. 
For example: 

Somebody built Alpine image with hash abc123
Then somebody build a Python image based on Alpine (FROM alpine:abc123) with hash def456.
Now you've build your image atop of Python (FROM python:def456) and result in hash ghi789.

Now your customer is pulling the image: 
docker pull flask:ghi789

When he runs his container he gets three read-only layers in memory (abc123, def456 and ghi789) and one new read-write layer jkl357 that is initially empty. It will be filled later with some data during app activity, for example - logs, or external connections like "docker exec ...".
Thus, no matter what customer does in his new layers, all precommitted layers are safe.
The layer jkl357 become immutable (readonly) only upon commit. But this is already not your image SHA and not related to you app:
docker commit -t my-altered-flask:tag


All said is relevant unless your goal is to protect from modifying, not from read at all.


---

