26

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?

Improve this question
2
  • 2
    Unless you do manage the docker host I believe you can't. What problem are you willing to solve by preventing this access?
    – Tensibai
    Commented May 6, 2017 at 16:33
  • 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
    Commented May 6, 2017 at 16:40

6 Answers 6

Reset to default
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.

Improve this answer
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...

Improve this answer
2
  • 2
    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
    Commented Sep 7, 2018 at 6:56
  • @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.
    Commented Apr 20, 2020 at 10:59
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. 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.

Improve this answer
1
  • 2
    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
    Commented May 10, 2017 at 11:47
5

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

Improve this answer
1
  • 3
    only possible/effective if you own those servers...
    – Dan Cornilescu
    Commented May 7, 2017 at 0:02
2

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

Improve this answer
1
  • 3
    How would this prevent access to the container? Try yo explain how your proposition would actually solve OP's problem.
    – Michaël Le Barbier
    Commented Jul 28, 2017 at 12:47
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.