<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>

CC BY-SA 4.0
2024-11-21T07:36:21.963Z
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.
searchbruh
CC BY-SA 4.0
2024-11-21T03:29:40.677Z
2024-11-21T03:29:40.677Z
Ajay
<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>

<docker><kubernetes><security><devsecops>
security risk with reusing the same UID:GID for users when creating docker containers all deployed to the same cluster
searchbruh
# 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.  

---

