skip to Main Content

I have hosted a docker image on the gitlab repo.

I have some sensitive data in one of the image layers.

Now if someone pulls the image, can he sees the sensitive date on the intermediate layer.

Also can he know the Dockerfile commands I have used for the image.

I want the end user to only have the image and dont have any other info about its Dockerfile

But atleast i dont want him to see the intermediate files

2

Answers


    1. You can use multi-stage builds,

    manage secrets in an intermediate image layer that is later disposed off ,so that no sensitive data reaches the final image build.

    such as in the following example:

    FROM: ubuntu as intermediate
    WORKDIR /app
    COPY secret/key /tmp/
    RUN scp -i /tmp/key build@acme/files .
    
    
    FROM ubuntu
    WORKDIR /app
    COPY --from intermediate /app .
    

    Another options to maintain secret are

    1. docker secret : you can use docker secret if you are using docker swarm

    2. secrets in docker-compose file (without swarm)

    version: "3.6"

    services:

    my_service:
        image: centos:7
        entrypoint: "cat /run/secrets/my_secret"
        secrets:
          - my_secret
    
    secrets:
      my_secret:
        file: ./super_duper_secret.txt
    
    Login or Signup to reply.
  1. If someone pulls the image, can he sees the sensitive date on the intermediate layer?

    Yes.

    Also can he know the Dockerfile commands I have used for the image.

    Yes.

    You should take these into account when designing your image build system. For example, these mean you should never put any sort of credentials into your Dockerfile, because anyone who has the image can easily retrieve them. You can mitigate this somewhat with @RavindraBagale’s suggestion to use a multi-stage build but even so it’s risky. Run commands like git clone that need real credentials from outside the Dockerfile.

    The further corollary to this is, if you think your code is sensitive, Docker on its own is not going to protect it. Using a compiled language (Go, C++, Rust) will mean you can limit yourself to distributing the compiled binary, which is harder to reverse-engineer; JVM languages (Java, Scala, Kotlin) can only distribute the jar file, though IME the bytecode is relatively readable; for interpreted languages (Python, Ruby, Javascript) you must distribute human-readable code. This may influence your initial language choice.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search