8

I love Docker but I'm almost always screwing around with permissions and file ownership when it comes to secrets, bind mounts and making sure shit doesn't run as root while also making sure secrets are exposed and volumes aren't owned by root

Perhaps my frustration comes from the fact that I'm still learning and sometimes get impatient when things don't work within an hour or two, but still

Comments
  • 0
    Docker has great possibilities and it's really cool to work with once configured properly. But it can be a pain to get there. Hang in there!
  • 1
    Hey man don't do that, listen:

    Docker container is NOT a virtual machine, don't try to configure it like you configure the server.

    Instead, think docker container as an "app". As an app, it can do whatever the it wants in its own environment. Its ok to run as root, fuck up its own OS, deleting files within itself.

    What you can do is to make sure when running the "app", the port, volume, CPU and Memory are safely mapped, as they are the only things the "app" can hurt. Only open the port you need. Map volumes to some where safe to read/write to without damaging the host.
  • 1
    p/s: You pass secret through environment variables, just like you do with a normal "app".
  • 0
    @nam17887 Environment variables are visible in the docker inspect command, secrets on the other hand are mounted files that are not visible in commands
  • 0
    @nam17887 and running as root may be a security risk, root in a container equals root on the host. Programs like nginx and php-fpm can handle that but any file created by a root process will be owned by root and unusable in volumes or mounts without specific priviliges

    https://medium.com/@mccode/...

    I appreciate your help but I feel like your advice is going against what I've learned on Docker security and best practices
  • 1
    @alexbrooklyn Secrets pass via files also visible by volume inspect command. You can go there and see where the volume stores file.

    It is advisable for processes inside container to not run as root, however, even if you run as root, there is no known possible way to damage the host container. Look at amazon Fargate, they run my containers, can run my app as root and hack their Fargate?

    The article mount a volume to the container, giving access to the container to the volume and complaining the container has access to it - what is it trying to demonstrate?

    Re-read my post, secure the mount point and port, worry less about the things inside container.
  • 0
    @nam17887 but those secrets aren't readable through docker volumes right? My secrets are always stored in a u+rx folder that can only be accessed by root and the runuser. Sure if you exec into a container you can see the secrets as well, but normal users don't have those rights. I recall my co-worker saying that docker inspect is a command that doesn't have protection, but don't quote me on that please

    But are you saying that I should run every container as root so that they can access eachother's files in named volumes without issue? What if the application running inside container has a vulnerability and someone gaines shell access inside, they could remove everything instead of only the files used by the user running the process, or perhaps execute a dangerous uploaded file with root access

    I recall it even being mentioned during a conference on the subject of Kubernetes that :latest, root containers and another third thing are things to look out for
  • 1
    @alexbrooklyn hey mate, I was trying to convince you to not try treating containers as vm, and I admit I incorrectly expressed my view by saying "its ok to run as root":

    - It is safer to run as non root, however its not the end of the world if you run your apps as root, since your container is isolated, though contaminated container won't be able to harm your host. They can however, harm your volume and network, even with non-root, so configuring volume and network is more important.

    - We don't pass secret via volumes, in reality containers are less likely to have mounted volumes, since they need to be stateless and can be moved around.

    Instead, we use password vault(like AWS secret manager). The name of the vault passed via environment variables. No secret is stored in the container.
  • 1
    @nam17887 Ah I see! I apologise if I came off as rude or accusive, I was really confused on what you meant.

    Thanks for the information! I do desire to look for more 'real' solutions like an actual vault instead of using docker-compose's secrets top level keyword.
  • 1
    @alexbrooklyn awesome mate!
Your Job Suck?
Get a Better Job
Add Comment