0

Went through a crash course in Docker and Compose to learn how to deploy a small automated application with security in mind. Problem is, I needed to feed the script sensitive values and did not want to hardcode them in. After a lot of research, I settled on Compose and setting my env var's at runtime rather than using the standard Docker build. I also have some JSON files that contain web cookies as a form of login that are passed as volumes. My understanding was that the values would not be visible while inspecting the container. Yet, when I inspect it, they are clearly visible along with the contents of the JSON files. Unless I am the only one that knows how to access the specific container, I am pretty sure that this is NOT a safe option.

From the yaml:

services:
  frontend:
    image: SOME IMAGE
    build: .
    volumes:
      - ./script.py:/app/script.py
      - ./words.txt:/app/words.txt
      - ./.some.json:/app/.some.json
      - ./.another.json:/app/.another.json
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - ./some.env
    container_name: name
volumes:
  .:
    external: true

Why are the values and files clearly visible? I do not want to go the Swarm direction and its SECRETS at this time.

EDIT: this is not being pushed to Hub or a repository, so I am not worried about security in that regard.

Michael Gambrell
  • 11
  • 2
  • To clarify: is the json file a secret, or is the filename itself also a secret? – Nick ODell Feb 10 '22 at 00:36
  • just the contents of the file; they contain specific cookies for sites I am accessing in the application – Michael Gambrell Feb 10 '22 at 00:37
  • I don't think docker volumes expose the secret to docker inspect, do they? Can you post output of docker inspect that shows what you mean? – Nick ODell Feb 10 '22 at 00:49
  • "Config": { "Hostname": "container ID", "Domainname": "", "User": "", "AttachStdin": false, "AttachStdout": true, "AttachStderr": true, "Tty": false, "OpenStdin": false, "StdinOnce": false, "Env": [ "SEND1=[num1]", "SEND2=[num2]", "GROUP1=[group1]", "GROUP2=[group2]", "TW_ACCTSID=[id]", "TW_AUTHTOK=[token]", "TW_NUM=[num3]", – Michael Gambrell Feb 10 '22 at 01:50
  • this is from inspect... the env key shows all my variables – Michael Gambrell Feb 10 '22 at 01:51
  • That would come from the `env_file: [some.env]` setting most likely. As @rzlvmp's answer notes, though, anyone who can `docker inspect` the container can also `docker exec` a shell inside it, and for that matter, can `docker run` a new container with unrestricted root access to the host; if the Docker metadata is your big concern, restricting the Docker socket to require `sudo` access is probably the best approach. – David Maze Feb 10 '22 at 12:20

1 Answers1

2

Unless I am the only one that knows how to access the specific container, I am pretty sure that this is NOT a safe option

If someone else knows how to access container he/she will be able to run:

# to get contents of JSON file
docker exec container_name cat /app/.some.json

# to print all env vars inside container
docker exec container_name env

I am pretty sure that this is NOT a safe option

Not safe option is an allowing to control/access server side for unknown persons. Container contents is a last destination, if someone get access to it here is game over and no reasons to hide information

Setting variables and secrets inside ENVs and config files only helps to

  • reuse same code at different configurations/environments without changing itself
  • share code at public places (like GitHub) without leaking sensitive information (I recommend to add all config file paths inside .gitignore)

Also this article may be helpful for you

rzlvmp
  • 7,512
  • 5
  • 16
  • 45
  • Thank you... I do not plan to give out control or access, but I was more or less looking to protect as much as possible with Compose from hacks and hackers. – Michael Gambrell Feb 10 '22 at 02:09
  • Inspecting the container from Docker Desktop also clearly shows the env var's that were run with Compose config – Michael Gambrell Feb 10 '22 at 02:12
  • As I said in answer, if you have rights to run `docker inspect` here is a million ways how to get your data without using inspection. What is a reason to lock door if all windows are open? Also it is impossibly physically to hide secrets that needed for application. If you have full access to server you able to see 100% of what server can see – rzlvmp Feb 10 '22 at 02:16
  • So then I need to make sure that no one gets to docker inspect... I've had a problem with hackers sitting on my system before. – Michael Gambrell Feb 10 '22 at 03:10
  • `I've had a problem with hackers sitting on my system before` → hiding of envs won't solve this problem in future :) – rzlvmp Feb 10 '22 at 03:21
  • Noted... I'll continue to research security within Docker if it is even possible. Next step is security on my network however. – Michael Gambrell Feb 10 '22 at 04:12