Because of security requirements where I work a developer should not be able to see any credentials or secrets needed to run my application but may need to attach to a running container to investigate issues.
I am trying to run a Spring Boot java application on the OpenJDK/Alpine base image. The basic command is java -jar app.jar.
I want all files to be owned and the application run by one user, appuser, and developers to attach as a second user, devuser, that only has read access to certain files.
We are new to Docker so don’t have much details on our run-time but this will probably be a blocker for us adopting Docker. I am currently learning with Docker for Mac but plan to move to Docker Swarm once we get past this hurdle.
You can checkout Docker enterprise edition(EE) that supports RBAC. Another option is to checkout Docker authorization plugin, I think this is available for community edition(CE).
Thanks. I need to spend more time to understand your two suggestions but I don’t get the sense they are an exact match for my requirements. I am trying to allow developers access to the running container but limit their access at the OS level once they are attached.
The real solution is probably to never allow developers to a running container but I am not sure if we are there. We have had access to the OS so our procedures are based on that. We should break that habit but that will take time.
Check the policy scenario in this link(https://github.com/twistlock/authz) and see if that will satisfy your requirement. I am not sure how mature this authorization plugin is.
So your usecase is for developers to attach to running containers but not modify it, like use-it in read-only mode. That was 1 of the goal of authorization plugin.
I am trying to protect the credentials that may be stored in files or as secrets. This is done at the OS level.
I am not explaining it correctly so maybe a little example will help clarify what I am trying to achieve. The application runs as appuser and I as the developer will attach to the container using exec sh as devuser where both appuser and devuser are a member of appgroup.
When I attach to the container using exec sh I expect to not to be able to see the contents of application.yml.
devuser$ ls -l
-r--r----- 1 appuser appgroup 25101769 Jun 27 12:59 app.jar
-r-------- 1 appuser appgroup 316 Jun 27 12:59 application.yml
devuser$ cat application.yml
cat: application.yml: Permission denied
Ok. Now i understand what you are saying. You want filesystem level access protection inside container based on the username. This is not possible currently.
You can do filesystem level protection using kernel features like apparmor/selinux and this is integrated with docker. But this is not user based.
Using auth plugin, you can do user level protection, but its not at filesytem level. You can actually prevent specific user writing to filesystem with auth plugin.
What you are asking for is something like integration between selinux/apparmor with auth plugin. Probably, you should raise enhancement request for this.
It’s realy, but useless in a security context because any user in the docker group can run docker exec --user root <container> /bin/bash. If you talk about non-security context you can ask developer use docker exec --user devuser <container> /bin/bash or start container with docker run --user appuser <image>.
Thanks. The --user opens a world possibilities and a world of problems. I guess I am back to trying to control users as they access the container and not what they do once they are in the container. If I can force them to only connect as --user devuser then I can protect the credentials. Otherwise there may not be much to do. I was trying to get SUID working but if you can use --user root that won’t work.