[[411232]]

隨意使用 root 和特權(quán)可能會(huì)帶來不必要的風(fēng)險(xiǎn)。本文展示了特權(quán)與 root 運(yùn)行方式的不同之處以及特權(quán)的實(shí)際意義。

很多熟悉 Unix 系統(tǒng)的人（例如 macOS、Linux）都習(xí)慣于通過使用 sudo 隨意提升我們的特權(quán)給 root 用戶。在調(diào)試開發(fā)工具或嘗試編輯受保護(hù)目錄中的文件時(shí)，經(jīng)常會(huì)發(fā)生這種情況，許多人在第一次嘗試之后，執(zhí)行命令不成功，都會(huì)默認(rèn)使用 sudo。

了解 Docker 安全性的基礎(chǔ)是了解實(shí)際的容器

Docker 提供了一個(gè)類似 --privileged flag，實(shí)際上這與我們隨意使用的 sudo 有很大不同，它可能會(huì)使應(yīng)用程序面臨不必要的風(fēng)險(xiǎn)。本文將展示這與 root 運(yùn)行方式有何不同（以及如何避免以 root 用戶身份運(yùn)行），并介紹特權(quán)（privileged）的實(shí)際含義。

作為 root 運(yùn)行

Docker 允許其在主機(jī)操作系統(tǒng)上隔離進(jìn)程、功能和文件系統(tǒng)，并且實(shí)際上，大多數(shù)容器默認(rèn)以 root 身份運(yùn)行。為了示例，本文將使用 DockerHub 上的三個(gè)最受歡迎鏡像。

Postgres： 

$ docker run -it postgres   
＃whoami   
root   
＃id -u   
0 

Couchbase： 

$ docker run -it couchbase sh   
＃whoami   
root   
＃id -u   
0 

Alpine： 

$ docker run -it alpine sh   
＃whoami   
root   
＃id -u   
0 

我們可以看到，默認(rèn)情況下，大多數(shù)鏡像都以 root 用戶身份運(yùn)行。通常這可以簡(jiǎn)化調(diào)試過程，尤其是在我們要 exec 到容器時(shí)。盡管 root 用戶的 Linux 功能非常有限，但最好還是避免以 root 用戶身份運(yùn)行。

避免以 root 身份運(yùn)行

盡管在容器內(nèi)部以 root 身份運(yùn)行是非常正常的事，但是如果我們想要強(qiáng)化容器，仍然需要避免這種情況。首先，違反了最小特權(quán)原則，其次，更嚴(yán)格地說，容器將成為運(yùn)行 Docker 命令的同一用戶命名空間的一部分，并且如果容器能夠轉(zhuǎn)義，它將可以訪問 volume、socket 等資源。

有兩種避免以 root 用戶身份運(yùn)行的方法。

通過調(diào)整 Dockerfile 以使用特定用戶： 

// Dockerfile   
FROM microsoft/windowsservercore  
# Create Windows user in the container  
RUN net user /add patrick  
# Set it for subsequent commands 
 USER patrick 

在運(yùn)行時(shí)重寫 User ID： 

$ docker run -it --user 4000 postgres sh  
# whoami  
whoami: cannot find name for user ID 4000  
# id -u  
4000 

關(guān)于特權(quán)

--privileged flag 將我們之前看到的用戶 ID 直接映射到主機(jī)的用戶 ID，并使其不受限制地訪問其選擇的任何系統(tǒng)調(diào)用。即使 root 在容器內(nèi)部，在正常操作中，Docker 也會(huì)限制容器的 Linux 功能，例如限制 CAP_AUDIT_WRITE，它允許覆蓋內(nèi)核的審計(jì)日志，這是容器化工作負(fù)載不太需要的功能。

實(shí)際上，特權(quán)應(yīng)該只在我們真正需要的特定設(shè)置中使用，它可以使容器訪問主機(jī)（作為 root）幾乎可以執(zhí)行所有操作。從本質(zhì)上講，這是一個(gè)通行證，可以逃避容器包含的文件系統(tǒng)、進(jìn)程、套接字和其他包含的項(xiàng)目。它有特定的用例，例如 Docker-in-Docker，其他 CI/CD 工具要求（從 Docker 容器內(nèi)部需要 Docker 守護(hù)程序）以及需要極端網(wǎng)絡(luò)的地方。

下面看一個(gè)使用 Ubuntu 鏡像的示例（在 VM 內(nèi)測(cè)試，這樣就不會(huì)破壞任何東西）：

沒有特權(quán)： 

# whoami  
root # Notice here, we are still root!  
# id -u  
0  
# hostname  
382f1c400bd  
# sysctl kernel.hostname=Attacker  
sysctl: setting key "kernel.hostname": Read-only file system  # Yet we can't do this 

有特權(quán)： 

$ docker run -it --privileged ubuntu sh  
# whoami  
root. # Root again  
# id -u  
0  
# hostname  
86c62e9bba5e  
# sysctl kernel.hostname=Attacker  
kernel.hostname = Attacker # Except now we are privileged  
# hostname  
Attacker  

Kubernetes 通過安全上下文提供相同的功能： 

apiVersion: v1  
kind: Pod  
metadata:  
  name: nginx  
spec:  
  containers:  
  - name: nginx  
    image: nginx  
    securityContext:  
      privileged: true 

此外，Kubernetes 有一個(gè)稱為 PodSecurityPolicy 的強(qiáng)制機(jī)制，它是一個(gè)準(zhǔn)入控制器（Kubernetes 在允許容器進(jìn)入集群之前會(huì)對(duì)其進(jìn)行檢查），這里強(qiáng)烈建議不允許使用特權(quán) Pod： 

apiVersion: policy/v1beta1  
kind: PodSecurityPolicy  
metadata: 
  name: example  
spec: 
  privileged: false  # Don't allow privileged pods! 

總結(jié)

到此為止，我們了解了一些有關(guān) root 和 --privileged flag 的信息，以及它們與“主機(jī)”操作系統(tǒng)的關(guān)系。無論我們是否想限制容器的安全性或調(diào)試問題，都需要確保應(yīng)用程序安全。