通過我之前的文章已經(jīng)可以驗證，在root用戶下安裝啟動的容器存在安全問題。究其原因是因為：

• 容器內(nèi)的root用戶就是宿主機的root用戶，容器內(nèi)uid=1000的用戶就是宿主機uid=1000的用戶
• docker的守護進程是root權(quán)限的

既然我們知道了原因，那么我們就來解決一下這兩個問題。

一、容器用戶與宿主機用戶映射

docker是使用--userns-remap容器用戶映射宿主機用戶的方式來解決問題，具體的方法描述如下：

用戶和組的映射由兩個配置文件來控制，分別是/etc/subuid和/etc/subgid。

echo "zimug:100000:65536" | tee /etc/subuid;
echo "zimug:100000:65536" | tee /etc/subgid;

subuid(sub子uid用戶id)：對于subuid的這一行表示，宿主機用戶zimug的用戶ip段為[100000,10000+65535]。也就是說，使用zimug這個宿主機啟動容器，容器內(nèi)的用戶uid與宿主機內(nèi)的用戶uid存在關(guān)系。也就是說按照上面的配置：

• zimug這個用戶的容器子用戶id(subuid)，只能在[100000-165535]之間進行分配。[0-99999]這個區(qū)間范圍內(nèi)的uid仍然保留給宿主機進行使用。
• 使用zimug啟動的第一個容器，容器用戶root(uid=0)對應(yīng)的宿主機用戶應(yīng)該是uid=100000(不是宿主機root用戶)
• 使用zimug啟動的第二個容器，容器用戶root(uid-0)對應(yīng)的宿主機用戶可能是uid=101000(也不是宿主機root用戶)
• subgid表示的是用戶組id的映射關(guān)系，映射原理和uid是一致的。

二、在非root用戶下運行docker守護進程

2.1.docker版本要求

既然root用戶的提權(quán)問題解決了，我們就要解決下一個問題：docker的守護進程是root權(quán)限的，即運行docker守護進程的用戶仍然是root。我們需要做如下修正：

也就是我們要在非root用戶下安裝docker，并啟動docker守護進程，這種安裝及運行模式被稱為“RootLess”模式?？梢园惭b但是存在先決條件：“RootLess”模式是在 Docker Engine v19.03 中作為實驗性功能引入的，從 Docker Engine v20.10 開始提供正式使用。

2.2. 前置條件

需要安裝newuidmap和newgidmap工具shadow-utils,即配置上文中的/etc/subuid和/etc/subuid需要這兩個工具的支持。安裝之前使用yum list installed shadow-utils確認下是否已經(jīng)安裝過或者操作系統(tǒng)自帶，如果存在就不要安裝了,但第三步的配置是需要的。
第一步：添加一個軟件包安裝源，該源下面包含shadow-utils46-newxidmap

curl -o /etc/yum.repos.d/vbatts-shadow-utils-newxidmap-epel-7.repo https://copr.fedorainfracloud.org/coprs/vbatts/shadow-utils-newxidmap/repo/epel-7/vbatts-shadow-utils-newxidmap-epel-7.repo

第二步： yum install -y shadow-utils46-newxidmap
第三步：在/etc/sysctl.conf文件中修改系統(tǒng)參數(shù)user.max_user_namespaces = 28633，修改完成之后執(zhí)行sysctl --system命令讓參數(shù)生效。

echo user.max_user_namespaces=28633 >> /etc/sysctl.d/userns.conf;
sudo sysctl -p /etc/sysctl.d/userns.conf;

該參數(shù)默認值是0，即不允許操作系統(tǒng)用戶存在subuid空間。上面的操作完成之后使用sysctl --all --pattern user_namespaces命令驗證修改的結(jié)果。

2.3.開始rootless模式安裝

root用戶下確保已經(jīng)執(zhí)行下列命令進行用戶id關(guān)系配置

echo "zimug:100000:65536" | tee /etc/subuid;
echo "zimug:100000:65536" | tee /etc/subgid;

我已經(jīng)新建了一個linux用戶zimug，使用su - zimug切換到該用戶下，執(zhí)行安裝腳本，該安裝腳本需要連網(wǎng)。

curl -fsSL https://get.docker.com/rootless | sh

腳本執(zhí)行完成之后，顯示的內(nèi)容如下：

將上圖中安裝過程提示的export內(nèi)容添加到 ~/.bashrc 文件中，添加完使用source ~/.bashrc命令使環(huán)境變量生效。注意：你的環(huán)境變量和我的一定不一致，要copy上圖中紅色部分。

export XDG_RUNTIME_DIR=/home/zimug/.docker/run
export PATH=/home/zimug/bin:$PATH
export DOCKER_HOST=unix:///home/zimug/.docker/run/docker.sock

2.4.啟動守護進程運行容器

在zimug用戶下使用下面的腳本啟動docker守護進程，該腳本在上文中的環(huán)境變量PATH目錄下，所以我們不用寫全路徑。注意：我們這里使用了 --experimental --storage-driver vfs參數(shù)啟動，因為我的linux內(nèi)核版本比較低所以需要加這個參數(shù)，后文我會說明原因。

dockerd-rootless.sh --experimental --storage-driver vfs

啟動一個容器我們嘗試一下，注意宿主機映射的端口不能小于1024，因為linux非root用戶不能使用1024以下的端口。

docker run -d --name nginx-zimug -p  8080:80  nginx

訪問nginx服務(wù)看到界面就證明nginx服務(wù)沒有問題，同時注意宿主機防火墻開放8080端口訪問，這個我就不說了。

三、存在若干已知的限制。

官方文檔說的是known-limitations，也就是已知的受限因素是下面這些，未知的受限因素還不一定有多少呢。所以筆者針對rootless模式目前也只是研究，還沒有在生產(chǎn)上能夠正式使用（2022年4月6日）。雖然它很安全，但是如果坑太多的話，我也受不了啊。

• 目前僅支持以下存儲驅(qū)動程序：
• overlay2（僅當使用內(nèi)核 5.11 或更高版本或 Ubuntu 發(fā)行版本的內(nèi)核運行時，才能夠支持這個存儲驅(qū)動）。上文中我的內(nèi)核版本是3.10達不到要求。
• fuse-overlayfs（僅當使用內(nèi)核 4.18 或更高版本運行并fuse-overlayfs被安裝時）
• btrfs（僅當使用內(nèi)核 4.18 或更高版本運行，或者~/.local/share/docker使用user_subvol_rm_allowed掛載選項掛載時）
• vfs 兼容性最好，但這個存儲驅(qū)動目前僅能用于實驗，不能用于生產(chǎn)。
• 只有在使用 cgroup v2 和 systemd 運行時才支持 Cgroup。
• 不支持以下功能：
• AppArmor
• Checkpoint
• Overlay網(wǎng)絡(luò)模式
• 暴漏SCTP 端口

四、卸載Rootless docker

在非root用戶(我用的是zimug用戶)下執(zhí)行下列命令，完成docker rootless卸載
第一步：

rootlesskit rm -rf ~/.local/share/docker

第二步：

$ cd ~/bin 
$ rm -f containerd containerd-shim containerd-shim-runc-v2 ctr docker docker-init docker-proxy dockerd dockerd-rootless-setuptool.sh dockerd-rootless.sh rootlesskit rootlesskit-docker-proxy runc vpnkit

第三步： 把上文中在 ~/.bashrc 文件中添加的環(huán)境變量刪掉。