Answers: <p>When containers with the same UID share a volume, they inherit mutual access to the files created by others. This is necessary for the functionality you describe but can pose a security risk.
  If a vulnerability in <code>container_1</code> allows an attacker to execute commands as the user <code>1000:1000</code>, they can access and modify the shared files, which may affect <code>container_2</code>.</p>
  <p>You can try these practices to mitigate those risks:</p>
  <p><strong>Limit UID Sharing:</strong></p>
  <p>Use unique UID pairs for containers that do not share volumes. This limits the scope of access to only containers that need it.</p>
  <p><strong>Restrict Volume Access:</strong></p>
  <p>To limit the modification of shared data, use volume mounts with <strong>read-only</strong> access whenever possible. You can also use <strong>subPath</strong> mounts to isolate portions of a shared volume.</p>
  
Answers: CC BY-SA 4.0
Answers: 2024-11-21T07:36:21.963Z
Answers: Thanks for your response. 
  
  I understand the shared volume access issue. My question was more about the "lateral movement" risk with containers that share UID:GID's but do not share volume mounts.
  
  If container_1 is compromised, but it's immutable (can't be modified), how can an attacker use the same UID to move laterally to container_2 (immutable) where container_1 and container_2 do not share any volumes.
Answers: searchbruh
Answers: CC BY-SA 4.0
Answers: 2024-11-21T03:29:40.677Z
Answers: 2024-11-21T03:29:40.677Z
Answers: Ajay
Body: <p>Thanks for taking the time to read my question.</p>
  <p>I am having trouble understanding the risks with using the same UID and GID for multiple containers deployed in the same kubernetes cluster. Lets say there are multiple apps running as either a daemon set, statefulset or deployments where the dockerfile creates a single user (lets say 1000:1000) to run the application. Example below:</p>
  <pre><code>FROM python:3.10.15-bullseye
  
  # Build ARGs
  ARG USER_ID=1000
  ARG GROUP_ID=1000
  ARG USER_NAME=app
  ARG GROUP_NAME=app
  
  COPY --from=builder /wheels /wheels
  COPY --chown=${USER_ID}:${GROUP_ID} app/ /app/
  
  RUN set -ex \
      &amp;&amp; groupadd --gid ${GROUP_ID} ${GROUP_NAME} \
      &amp;&amp; useradd --uid ${USER_ID} --gid ${GROUP_NAME} --shell /bin/bash --no-create-home ${USER_NAME} \
      &amp;&amp; pip install --no-cache /wheels/*
  
  ENV LOG_LEVEL=DEBUG
  ENV PYTHONUNBUFFERED=TRUE
  
  USER ${USER_NAME}
  
  CMD [ &quot;bash&quot;, &quot;/app/entrypoint.sh&quot;, &quot;--prod&quot; ]
  
  EXPOSE 7611
  </code></pre>
  <p>The containers with shared volume mounts must be running as the same UID:GID so container_1 can access files written by container_2. However, there are other containers that do not share any volume mounts with other containers.</p>
  <p>I've been advised that this is poor security practice as this leaves room for lateral movement between containers that do not share volume mounts. Please help me understand if/how this is possible.</p>
  <p>Much appreciated.</p>
  
Tags: <docker><kubernetes><security><devsecops>
Title: security risk with reusing the same UID:GID for users when creating docker containers all deployed to the same cluster
UserDisplayName: searchbruh
ThreadText: # security risk with reusing the same UID:GID for users when creating docker containers all deployed to the same cluster
  
  (Asked by: username_0 on 2024-11-20)
  
  Thanks for taking the time to read my question.
  
  I am having trouble understanding the risks with using the same UID and GID for multiple containers deployed in the same kubernetes cluster. Lets say there are multiple apps running as either a daemon set, statefulset or deployments where the dockerfile creates a single user (lets say 1000:1000) to run the application. Example below:
  
  ```
  FROM python:3.10.15-bullseye
  
  # Build ARGs
  ARG USER_ID=1000
  ARG GROUP_ID=1000
  ARG USER_NAME=app
  ARG GROUP_NAME=app
  
  COPY --from=builder /wheels /wheels
  COPY --chown=${USER_ID}:${GROUP_ID} app/ /app/
  
  RUN set -ex \
      && groupadd --gid ${GROUP_ID} ${GROUP_NAME} \
      && useradd --uid ${USER_ID} --gid ${GROUP_NAME} --shell /bin/bash --no-create-home ${USER_NAME} \
      && pip install --no-cache /wheels/*
  
  ENV LOG_LEVEL=DEBUG
  ENV PYTHONUNBUFFERED=TRUE
  
  USER ${USER_NAME}
  
  CMD [ "bash", "/app/entrypoint.sh", "--prod" ]
  
  EXPOSE 7611
  
  ```
  
  The containers with shared volume mounts must be running as the same UID:GID so container\_1 can access files written by container\_2. However, there are other containers that do not share any volume mounts with other containers.
  
  I've been advised that this is poor security practice as this leaves room for lateral movement between containers that do not share volume mounts. Please help me understand if/how this is possible.
  
  Much appreciated.
  
  **Tags:** docker, kubernetes, security, devsecops
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2024-11-21. Score: 0
  
  When containers with the same UID share a volume, they inherit mutual access to the files created by others. This is necessary for the functionality you describe but can pose a security risk.
  If a vulnerability in `container_1` allows an attacker to execute commands as the user `1000:1000`, they can access and modify the shared files, which may affect `container_2`.
  
  You can try these practices to mitigate those risks:
  
  **Limit UID Sharing:**
  
  Use unique UID pairs for containers that do not share volumes. This limits the scope of access to only containers that need it.
  
  **Restrict Volume Access:**
  
  To limit the modification of shared data, use volume mounts with **read-only** access whenever possible. You can also use **subPath** mounts to isolate portions of a shared volume.
  
  > **Comments:**
  > **username_0**: Thanks for your response.   I understand the shared volume access issue. My question was more about the "lateral movement" risk with containers that share UID:GID's but do not share volume mounts.  If container_1 is compromised, but it's immutable (can't be modified), how can an attacker use the same UID to move laterally to container_2 (immutable) where container_1 and container_2 do not share any volumes.  
  
  ---
  
  