默認(rèn)情況下，容器中的進(jìn)程以 root 用戶權(quán)限運(yùn)行，并且這個(gè) root 用戶和宿主機(jī)中的 root 是同一個(gè)用戶。聽起來是不是很可怕，因?yàn)檫@就意味著一旦容器中的進(jìn)程有了適當(dāng)?shù)臋C(jī)會(huì)，它就可以控制宿主機(jī)上的一切！本文我們將嘗試了解用戶名、組名、用戶 id(uid)和組 id(gid)如何在容器內(nèi)的進(jìn)程和主機(jī)系統(tǒng)之間映射，這對(duì)于系統(tǒng)的安全來說是非常重要的。

說明：本文的演示環(huán)境為 ubuntu 16.04 (下圖來自互聯(lián)網(wǎng))。

先來了解下?uid?和?gid

uid 和 gid 由 Linux 內(nèi)核負(fù)責(zé)管理，并通過內(nèi)核級(jí)別的系統(tǒng)調(diào)用來決定是否應(yīng)該為某個(gè)請(qǐng)求授予特權(quán)。比如當(dāng)進(jìn)程試圖寫入文件時(shí)，內(nèi)核會(huì)檢查創(chuàng)建進(jìn)程的 uid 和 gid，以確定它是否有足夠的權(quán)限修改文件。注意，內(nèi)核使用的是** uid?和?gid****，而不是用戶名和組名**。簡單起見，本文中剩下的部分只拿 uid 進(jìn)行舉例，系統(tǒng)對(duì)待 gid 的方式和 uid 基本相同。

很多同學(xué)簡單地把 docker 容器理解為輕量的虛擬機(jī)，雖然這簡化了理解容器技術(shù)的難度但是也容易帶來很多的誤解。事實(shí)上，與虛擬機(jī)技術(shù)不同：同一主機(jī)上運(yùn)行的所有容器共享同一個(gè)內(nèi)核(主機(jī)的內(nèi)核)。容器化帶來的巨大價(jià)值在于所有這些獨(dú)立的容器(其實(shí)是進(jìn)程)可以共享一個(gè)內(nèi)核。這意味著即使由成百上千的容器運(yùn)行在 docker 宿主機(jī)上，但**內(nèi)核控制的**** uid?和?gid **則仍然只有一套。所以同一個(gè) uid 在宿主機(jī)和容器中代表的是同一個(gè)用戶(即便在不同的地方顯示了不同的用戶名)。注意，由于普通的用來顯示用戶名的 Linux 工具并不屬于內(nèi)核(比如 id 等命令)，所以我們可能會(huì)看到同一個(gè) uid 在不同的容器中顯示為不同的用戶名。但是對(duì)于相同的 uid 不能有不同的特權(quán)，即使在不同的容器中也是如此。

如果你已經(jīng)了解了 Linux 的 user namespace 技術(shù)，參考《Linux Namespace :User》，你需要注意的是到目前為止，docker 默認(rèn)并沒有啟用 user namesapce，這也是本文討論的情況。筆者會(huì)在接下來的文章中介紹如何配置 docker 啟用 user namespace。

容器中默認(rèn)使用** root **用戶

如果不做相關(guān)的設(shè)置，容器中的進(jìn)程默認(rèn)以 root 用戶權(quán)限啟動(dòng)，下面的 demo 使用 ubuntu 鏡像運(yùn)行 sleep 程序：

注意上面的命令中并沒有使用 sudo。筆者在宿主機(jī)中的登錄用戶是 nick，uid 為 1000：

在宿主機(jī)中查看 sleep 進(jìn)程的信息：

sleep 進(jìn)程的有效用戶名稱是 root，也就是說 sleep 進(jìn)程具有 root 權(quán)限。然后進(jìn)入容器內(nèi)部看看，看到的情況和剛才一樣，sleep 進(jìn)程也具有 root 權(quán)限：

那么，容器內(nèi)的 root 用戶和宿主機(jī)上的 root 用戶是同一個(gè)嗎？答案是：是的，它們對(duì)應(yīng)的是同一個(gè) uid。原因我們?cè)谇懊嬉呀?jīng)解釋過了：整個(gè)系統(tǒng)共享同一個(gè)內(nèi)核，而內(nèi)核只管理一套 uid 和 gid。

其實(shí)我們可以通過數(shù)據(jù)卷來簡單的驗(yàn)證上面的結(jié)論。在宿主機(jī)上創(chuàng)建一個(gè)只有 root 用戶可以讀寫的文件：

然后掛載到容器中：

在容器中可以讀寫該文件：

我們可以通過 Dockerfile 中的 USER 命令或者是 ?docker run 命令的 --user 參數(shù)指定容器中進(jìn)程的用戶身份。下面我們分別來探究這兩種情況。

在** Dockerfile **中指定用戶身份

我們可以在 Dockerfile 中添加一個(gè)用戶 appuser，并使用 USER 命令指定以該用戶的身份運(yùn)行程序，Dockerfile 的內(nèi)容如下：

編譯成名稱為 test 的鏡像：

用 test 鏡像啟動(dòng)一個(gè)容器：

在宿主機(jī)中查看 sleep 進(jìn)程的信息：

這次顯示的有效用戶是 nick，這是因?yàn)樵谒拗鳈C(jī)中，uid 為 1000 的用戶的名稱為 nick。再進(jìn)入到容器中看看：

容器中的當(dāng)前用戶就是我們?cè)O(shè)置的 appuser，如果查看容器中的 /etc/passwd 文件，你會(huì)發(fā)現(xiàn) appuser 的 uid 就是 1000，這和宿主機(jī)中用戶 nick 的 uid 是一樣的。讓我們?cè)賱?chuàng)建一個(gè)只有用戶 nick 可以讀寫的文件：

同樣以數(shù)據(jù)卷的方式把它掛載到容器中：

在容器中** testfile?的所有者居然變成了?appuser**，當(dāng)然 appuser 也就有權(quán)限讀寫該文件。

這里到底發(fā)生了什么？而這些又這說明了什么？首先，宿主機(jī)系統(tǒng)中存在一個(gè) uid 為 1000 的用戶 nick。其次容器中的程序是以 appuser 的身份運(yùn)行的，這是由我們通過 USER appuser 命令在 Dockerfile 程序中指定的。事實(shí)上，系統(tǒng)內(nèi)核管理的 uid 1000 只有一個(gè)，在宿主機(jī)中它被認(rèn)為是用戶 nick，而在容器中，它則被認(rèn)為是用戶 appuser。所以有一點(diǎn)我們需要清楚：在容器內(nèi)部，用戶 appuser 能夠獲取容器外部用戶 nick 的權(quán)利和特權(quán)。在宿主機(jī)上授予用戶 nick 或 uid 1000 的特權(quán)也將授予容器內(nèi)的 appuser。

從命令行參數(shù)中自定用戶身份

我們還可以通過 docker run 命令的 --user 參數(shù)指定容器中進(jìn)程的用戶身份。比如執(zhí)行下面的命令：

因?yàn)槲覀冊(cè)诿钚猩现噶盍藚?shù) --user 1000，所以這里 sleep 進(jìn)程的有效用戶顯示為 nick。進(jìn)入到容器內(nèi)部看一下：

這是個(gè)什么情況？用戶名稱居然顯示為 "I have noname!"！去查看 /etc/passwd 文件，里面果然沒有 uid 為 1000 的用戶。即便沒有用戶名稱，也絲毫不影響該用戶身份的權(quán)限，它依然可以讀寫只有 nick 用戶才能讀寫的文件，并且用戶信息也由 uid 代替了用戶名：

需要注意的是，在創(chuàng)建容器時(shí)通過 docker run --user指定的用戶身份會(huì)覆蓋掉 Dockerfile 中指定的值。我們重新通過 test 鏡像來運(yùn)行兩個(gè)容器：

查看 sleep 進(jìn)程信息：

再次查看 sleep 進(jìn)程信息：

文章轉(zhuǎn)載：Devops技術(shù)棧
（版權(quán)歸原作者所有，侵刪）