K
Q

How to manage linux users with Kubernetes?

9/25/2020

I want to secure my clusters with SecurityContext.RunAsUser. The question is simple : which user should I use ?

I know the user with the UID 1001 (for example) inside a container is the user with the UID 1001 on the host. So should I create a user with UID 1001 called pod_user on all my hosts and force all pods to use this user ? Or should I verify there is no user with this UID on all my hosts ? I didn't find best practices guide about this.

I have the same type of question about the Dockerfile : should I declare a user in the Dockerfile with a specific UID and reuse it in SecurityContext.RunAsUser ? Some official images are running with a specific hardcoded user in Dockerfile, and others are running as nobody. I found this interesting post but there is no clear answer: https://stackoverflow.com/questions/50447084/kubernetes-linux-user-management.

-- Antoine
docker
kubernetes
linux

Similar Questions

How do I connect to a remote mysql kubernetes pod using mysql client
Azure Service Bus Message Subscription stops working after container restart
sudo: eval: command not found
Kubernetes sizing consideration
Is it possible to use PodPresets in OpenShift 3.11 (3.7+)?

1 Answer

9/25/2020

My ideal recommendation here would be:

  • Your Dockerfile RUN adduser to create a non-root user, and switches the USER to that user after doing all of the software installation
  • You don't need to explicitly specify a user ID in the Kubernetes configuration
  • It doesn't matter what that user name or numeric ID is, or if it's the same user ID that exists in another container or on the host, just so long as the numeric uid isn't 0

The only place there's a practical problem is if the container tries to store data in a volume. Again, the ideal case would be to avoid this entirely; prefer using a database or cloud storage if that's a possibility.

If you do need to use a local volume, you can specifically configure a security policy with a supplemental fsGroup:. That is an arbitrary numeric group ID (not user ID) which will own the files in the volume, and also will be added to the group list for the main container process.

apiVersion: v1
kind: Pod
spec:
  securityContext:
    fsGroup: 12345  # or any numeric gid

Don't use hostPath volumes at all: you can't guarantee that the same contents will be on every node if the pod gets rescheduled, and if the node fails, content that lives only on that node will be lost.

-- David Maze
Source: StackOverflow