<p>I want to secure my clusters with <code>SecurityContext.RunAsUser</code>. The question is simple : which user should I use ?</p>
<p>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 <code>pod_user</code> 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.</p>
<p>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 <code>SecurityContext.RunAsUser</code> ? 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: <a href="https://stackoverflow.com/questions/50447084/kubernetes-linux-user-management">Kubernetes: Linux user management</a>.</p>

Antoine
<p>My ideal recommendation here would be:</p>
<ul>
<li>Your Dockerfile <code>RUN adduser</code> to create a non-root user, and switches the <code>USER</code> to that user after doing all of the software installation</li>
<li>You don't need to explicitly specify a user ID in the Kubernetes configuration</li>
<li>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</li>
</ul>
<p>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.</p>
<p>If you do need to use a local volume, you can specifically <a href="https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod" rel="nofollow noreferrer">configure a security policy</a> with a supplemental <code>fsGroup:</code>.  That is an arbitrary numeric <em>group</em> 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.</p>
<pre><code>apiVersion: v1
kind: Pod
spec:
  securityContext:
    fsGroup: 12345  # or any numeric gid
</code></pre>
<p>Don't use <code>hostPath</code> 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.</p>
