Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-05-10T11:47:56.873Z
Answers: As the solution about docker groups, this works if you do manage the docker host system only, OP sounds more like distributing an image...
Answers: Tensibai
Answers: CC BY-SA 4.0
Answers: 2017-05-10T11:41:45.593Z
Answers: 2021-02-09T14:07:44.433Z
Answers: 2021-02-09T14:07:44.433Z
Answers: chintan thakar
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-05-07T00:02:50.297Z
Answers: only possible/effective if you own those servers...
Answers: Dan Cornilescu
Answers: CC BY-SA 3.0
Answers: 2017-05-06T12:35:11.487Z
Answers: 2017-05-06T12:35:11.487Z
Answers: user2590
Answers: <p>Give your delivery via ansible scripts. Keep all sort of restrictions and checks in the ansible script. </p>
  
Answers: CC BY-SA 3.0
Answers: 2017-07-28T12:47:11.697Z
Answers: How would this prevent access to the container? Try yo explain how your proposition would actually solve OP's problem.
Answers: Michaël Le Barbier
Answers: CC BY-SA 3.0
Answers: 2017-07-28T12:24:51.660Z
Answers: 2017-07-28T12:24:51.660Z
Answers: lakshayk
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-05-06T21:31:31.310Z
Answers: 2017-05-06T21:31:31.310Z
Answers: Dave Swersky
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2018-09-07T06:56:24.563Z
Answers: 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?
Answers: AjaxLeung
Answers: CC BY-SA 4.0
Answers: 2020-04-20T10:59:43.597Z
Answers: @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
Answers: Michael A.
Answers: CC BY-SA 3.0
Answers: 2017-07-31T07:12:52.350Z
Answers: 2017-07-31T07:12:52.350Z
Answers: Jeeva
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2020-04-20T11:13:47.757Z
Answers: 2020-04-20T11:18:55.433Z
Answers: 2020-04-20T11:18:55.433Z
Answers: Michael A.
Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2017-05-06T16:33:53.910Z
Comments: Unless you do manage the docker host I believe you can't. What problem are you willing to solve by preventing this access?
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-05-06T16:40:06.627Z
Comments: 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.
Comments: Aurora0001
Tags: <docker><security>
Title: How to prohibit access to internals of Docker container?
UserDisplayName: Victor Mezrin
ThreadText: # 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.
  
  
  ---
  
  