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?

Dawny33
  • 2,816
  • 3
  • 24
  • 62
Victor Mezrin
  • 361
  • 1
  • 3
  • 5

6 Answers6

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.

Dave Swersky
  • 4,068
  • 2
  • 21
  • 33
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...

Jeeva
  • 456
  • 4
  • 4
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.

codeforester
  • 391
  • 1
  • 5
  • 29
chintan thakar
  • 161
  • 3
5

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

user2590
  • 51
  • 1
2

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

lakshayk
  • 636
  • 1
  • 4
  • 8
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.

Michael A.
  • 101
  • 1