使用 root 用戶執(zhí)行Docker、K8s命令？No!!!
隨意使用 root 和特權(quán)可能會帶來不必要的風險。本文展示了特權(quán)與 root 運行方式的不同之處以及特權(quán)的實際意義。
很多熟悉 Unix 系統(tǒng)的人（例如 macOS、Linux）都習慣于通過使用 sudo 隨意提升我們的特權(quán)給 root 用戶。在調(diào)試開發(fā)工具或嘗試編輯受保護目錄中的文件時，經(jīng)常會發(fā)生這種情況，許多人在第一次嘗試之后，執(zhí)行命令不成功，都會默認使用 sudo。
了解 Docker 安全性的基礎是了解實際的容器
Docker 提供了一個類似 --privileged flag，實際上這與我們隨意使用的 sudo 有很大不同，它可能會使應用程序面臨不必要的風險。本文將展示這與 root 運行方式有何不同（以及如何避免以 root 用戶身份運行），并介紹特權(quán)（privileged）的實際含義。
作為 root 運行
Docker 允許其在主機操作系統(tǒng)上隔離進程、功能和文件系統(tǒng)，并且實際上，大多數(shù)容器默認以 root 身份運行。為了示例，本文將使用 DockerHub 上的三個最受歡迎鏡像。
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
我們可以看到，默認情況下，大多數(shù)鏡像都以 root 用戶身份運行。通常這可以簡化調(diào)試過程，尤其是在我們要 exec 到容器時。盡管 root 用戶的 Linux 功能非常有限，但最好還是避免以 root 用戶身份運行。
避免以 root 身份運行
盡管在容器內(nèi)部以 root 身份運行是非常正常的事，但是如果我們想要強化容器，仍然需要避免這種情況。首先，違反了最小特權(quán)原則，其次，更嚴格地說，容器將成為運行 Docker 命令的同一用戶命名空間的一部分，并且如果容器能夠轉(zhuǎn)義，它將可以訪問 volume、socket 等資源。
有兩種避免以 root 用戶身份運行的方法。
通過調(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
在運行時重寫 User ID：
- $ docker run -it --user 4000 postgres sh
- # whoami
- whoami: cannot find name for user ID 4000
- # id -u
- 4000
關于特權(quán)
--privileged flag 將我們之前看到的用戶 ID 直接映射到主機的用戶 ID，并使其不受限制地訪問其選擇的任何系統(tǒng)調(diào)用。即使 root 在容器內(nèi)部，在正常操作中，Docker 也會限制容器的 Linux 功能，例如限制 CAP_AUDIT_WRITE，它允許覆蓋內(nèi)核的審計日志，這是容器化工作負載不太需要的功能。
實際上，特權(quán)應該只在我們真正需要的特定設置中使用，它可以使容器訪問主機（作為 root）幾乎可以執(zhí)行所有操作。從本質(zhì)上講，這是一個通行證，可以逃避容器包含的文件系統(tǒng)、進程、套接字和其他包含的項目。它有特定的用例，例如 Docker-in-Docker，其他 CI/CD 工具要求（從 Docker 容器內(nèi)部需要 Docker 守護程序）以及需要極端網(wǎng)絡的地方。
下面看一個使用 Ubuntu 鏡像的示例（在 VM 內(nèi)測試，這樣就不會破壞任何東西）：
沒有特權(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 有一個稱為 PodSecurityPolicy 的強制機制，它是一個準入控制器（Kubernetes 在允許容器進入集群之前會對其進行檢查），這里強烈建議不允許使用特權(quán) Pod：
- apiVersion: policy/v1beta1
- kind: PodSecurityPolicy
- metadata:
- name: example
- spec:
- privileged: false # Don't allow privileged pods!
總結(jié)
到此為止，我們了解了一些有關 root 和 --privileged flag 的信息，以及它們與“主機”操作系統(tǒng)的關系。無論我們是否想限制容器的安全性或調(diào)試問題，都需要確保應用程序安全。
