理解用戶名、組名、用戶ID（UID）和組ID（GID）在容器內(nèi)運(yùn)行的進(jìn)程與主機(jī)系統(tǒng)之間的映射是構(gòu)建安全系統(tǒng)的重要一環(huán)。如果沒有提供其他選項(xiàng)，容器中的進(jìn)程將以root用戶身份執(zhí)行（除非在Dockerfile中提供了不同的UID）。本文將解釋這一工作原理，如何正確授予權(quán)限，并提供示例加以說明。

逐步分析uid/gid安全性

首先，讓我們回顧一下uid和gid是如何實(shí)現(xiàn)的。Linux內(nèi)核負(fù)責(zé)管理uid和gid空間，使用內(nèi)核級系統(tǒng)調(diào)用來確定是否應(yīng)該授予請求的特權(quán)。例如，當(dāng)一個(gè)進(jìn)程嘗試寫入文件時(shí)，內(nèi)核會(huì)檢查創(chuàng)建該進(jìn)程的uid和gid，以確定它是否具有足夠的特權(quán)來修改文件。這里不使用用戶名，而是使用uid。

在服務(wù)器上運(yùn)行 Docker 容器時(shí)，仍然只有一個(gè)內(nèi)核。容器化帶來的巨大價(jià)值之一是所有這些獨(dú)立的進(jìn)程可以繼續(xù)共享一個(gè)內(nèi)核。這意味著即使在運(yùn)行 Docker 容器的服務(wù)器上，整個(gè) uid 和 gid 的世界仍由一個(gè)單一內(nèi)核控制。

因此，在不同的容器中不能使用相同的 uid 分配給不同的用戶。這是因?yàn)樵诔Ｒ姷?Linux 工具中顯示的用戶名（和組名）并不是內(nèi)核的一部分，而是由外部工具（如 /etc/passwd、LDAP、Kerberos 等）管理。因此，你可能會(huì)看到不同的用戶名，但是即使在不同的容器中，對于相同的 uid/gid，你也不能擁有不同的權(quán)限。這一點(diǎn)一開始可能會(huì)讓人感到相當(dāng)困惑，所以讓我們通過幾個(gè)例子來說明一下：

簡單的Docker運(yùn)行

我將首先以普通用戶（marc）的身份登錄到一個(gè)屬于docker組的服務(wù)器上。這樣我就可以在不使用sudo命令的情況下啟動(dòng)docker容器。然后，從容器外部，讓我們來看看這個(gè)過程是如何呈現(xiàn)的。

marc@server:~$ docker run -d ubuntu:latest sleep infinity
92c57a8a4eda60678f049b906f99053cbe3bf68a7261f118e411dee173484d10
marc@server:~$ ps aux | grep sleep
root 15638 0.1 0.0 4380 808 ? Ss 19:49 0:00 sleep infinity

盡管我從未輸入過sudo，也不是root用戶，但我執(zhí)行的sleep命令以root用戶身份啟動(dòng)并具有root權(quán)限。我如何知道它具有root權(quán)限？容器內(nèi)的root是否等同于容器外的root？是的，因?yàn)檎缥姨岬降模幸粋€(gè)單一的內(nèi)核和一個(gè)共享的uid和gid池。由于容器外顯示的用戶名是“root”，我可以確定容器內(nèi)的進(jìn)程是以具有uid = 0的用戶啟動(dòng)的。

帶有定義用戶的Dockerfile

當(dāng)我在 Dockerfile 中創(chuàng)建一個(gè)不同的用戶并以該用戶身份啟動(dòng)命令時(shí)會(huì)發(fā)生什么？為了簡化這個(gè)例子，我這里沒有指定 gid，但相同的概念也適用于組 id。

首先，我正在以用戶名為“marc”的用戶身份運(yùn)行這些命令，該用戶的用戶ID為1001。

marc@server:~$ echo $UID
1001

Dockerfile文件：

FROM ubuntu:latest
RUN useradd -r -u 1001 -g appuser appuser
USER appuser
ENTRYPOINT [“sleep”, “infinity”]

構(gòu)建：

marc@server:~$ docker build -t test .
Sending build context to Docker daemon 14.34 kB
Step 1/4 : FROM ubuntu:latest
 — -> f49eec89601e
Step 2/4 : RUN useradd -r -u 1001 appuser
 — -> Running in 8c4c0a442ace
 — -> 6a81547f335e
Removing intermediate container 8c4c0a442ace
Step 3/4 : USER appuser
 — -> Running in acd9e30b4aba
 — -> fc1b765e227f
Removing intermediate container acd9e30b4aba
Step 4/4 : ENTRYPOINT sleep infinity
 — -> Running in a5710a32a8ed
 — -> fd1e2ab0fb75
Removing intermediate container a5710a32a8ed
Successfully built fd1e2ab0fb75
marc@server:~$ docker run -d test
8ad0cd43592e6c4314775392fb3149015adc25deb22e5e5ea07203ff53038073
marc@server:~$ ps aux | grep sleep
marc 16507 0.3 0.0 4380 668 ? Ss 20:02 0:00 sleep infinity
marc@server:~$ docker exec -it 8ad0 /bin/bash
appuser@8ad0cd43592e:/$ ps aux | grep sleep
appuser 1 0.0 0.0 4380 668 ? Ss 20:02 0:00 sleep infinity

這里到底發(fā)生了什么，這意味著什么？我構(gòu)建了一個(gè) Docker 鏡像，其中有一個(gè)名為“appuser”的用戶，該用戶的 uid 為 1001。在我的測試服務(wù)器上，我使用的帳戶名為“marc”，uid 也是 1001。當(dāng)我啟動(dòng)容器時(shí)，sleep 命令以 appuser 的身份執(zhí)行，因?yàn)?Dockerfile 包含了“USER appuser”這一行。但實(shí)際上這并不是以 appuser 的身份運(yùn)行，而是以 Docker 鏡像中被識別為 appuser 的用戶的 uid 運(yùn)行。

當(dāng)我檢查容器外運(yùn)行的進(jìn)程時(shí)，我發(fā)現(xiàn)它映射到用戶“marc”，但在容器內(nèi)部，它映射到用戶“appuser”。這兩個(gè)用戶名只是顯示它們的執(zhí)行上下文所知道的映射到1001的用戶名。

這并不是非常重要。但重要的是要知道，在容器內(nèi)部，用戶“appuser”獲得了來自容器外部用戶“marc”的權(quán)限和特權(quán)。在Linux主機(jī)上授予用戶marc或uid 1001的權(quán)限也將授予容器內(nèi)的appuser這些權(quán)限。

如何控制容器的訪問權(quán)限

另一種選擇是在運(yùn)行 Docker 容器時(shí)指定用戶名或用戶ID，以及組名或組ID。

再次使用上面的初始示例。

marc@server:~$ docker run -d --user 1001 ubuntu:latest sleep infinity
84f436065c90ac5f59a2256e8a27237cf8d7849d18e39e5370c36f9554254e2b
marc@server$ ps aux | grep sleep
marc     17058 0.1 0.0 4380 664 ? Ss 21:23 0:00 sleep infinity

我在這里做了什么？我創(chuàng)建了容器以1001用戶身份啟動(dòng)。因此，當(dāng)我執(zhí)行諸如ps或top（或大多數(shù)監(jiān)控工具）之類的命令時(shí)，進(jìn)程映射到“marc”用戶。

有趣的是，當(dāng)我進(jìn)入該容器時(shí)，你會(huì)發(fā)現(xiàn)1001用戶在/etc/passwd文件中沒有條目，并在容器的bash提示符中顯示為“I have no name！”。

marc@server:~$ docker exec -it 84f43 /bin/bash
I have no name!@84f436065c90:/$

重要的是要注意，在創(chuàng)建容器時(shí)指定用戶標(biāo)志也會(huì)覆蓋 Dockerfile 中的值。還記得第二個(gè)例子嗎？那時(shí)我使用了一個(gè) Dockerfile，其中的 uid 映射到本地主機(jī)上的不同用戶名。當(dāng)我們在命令行上使用用戶標(biāo)志來啟動(dòng)一個(gè)執(zhí)行“sleep infinity”進(jìn)程的容器時(shí)，會(huì)發(fā)生什么呢？

marc@server:$ docker run -d test
489a236261a0620e287e434ed1b15503c844648544694e538264e69d534d0d65
marc@server:~$ ps aux | grep sleep
marc     17689 0.2 0.0 4380 680 ? Ss 21:28 0:00 sleep infinity
marc@server:~$ docker run --user 0 -d test
ac27849fcbce066bad37190b5bf6a46cf526f56d889af61e7a02c3726438fa7a
marc@server:~$ ps aux | grep sleep
marc     17689 0.0 0.0 4380 680 ? Ss 21:28 0:00 sleep infinity
root     17783 0.3 0.0 4380 668 ? Ss 21:28 0:00 sleep infinity

在上面的最后一個(gè)示例中，您可以看到我最終得到了兩個(gè)運(yùn)行睡眠進(jìn)程的容器，一個(gè)是“marc”，另一個(gè)是“root”。這是因?yàn)榈诙€(gè)命令通過在命令行上傳遞--user標(biāo)志來更改了用戶ID。

總結(jié)

現(xiàn)在我們已經(jīng)探討了這一點(diǎn)，可以理解以有限權(quán)限運(yùn)行容器的方式都利用了主機(jī)的用戶系統(tǒng)：

• 如果容器內(nèi)部的進(jìn)程正在執(zhí)行的已知 uid，那么簡單地限制對主機(jī)系統(tǒng)的訪問，使容器中的 uid 僅具有有限訪問權(quán)限就可以了。
• 更好的解決方案是使用--user以已知 uid 啟動(dòng)容器（也可以使用用戶名，但請記住這只是提供主機(jī)用戶名系統(tǒng)中的 uid 的一種更友好的方式），然后限制主機(jī)上您決定容器將以其運(yùn)行的 uid 的訪問權(quán)限。
• 由于容器到主機(jī)的 uid 和用戶名（以及 gid 和組名）的映射，指定容器化進(jìn)程運(yùn)行的用戶可以使該進(jìn)程在容器內(nèi)部和外部看起來像是由不同的用戶擁有。