了解uid和gid如何在Docker容器中工做

​

了解用户名，组名，用户ID（uid）和组ID（gid）如何在容器内运行的进程与主机系统之间进行映射对于构建安全系统很是重要。若是没有提供任何其余选项，容器中的进程将以root身份执行（除非在Dockerfile中提供了不一样的uid）。本文将解释这是如何工做的，如何正确授予权

逐步分析uid/god安全性

首先，让咱们回顾一下如何实现 uid 和 gids.linux 内核负责管理 uid 和 gid 空间，它的内核级系统调用用于肯定是否应该授予所请求的权限。例如，当进程尝试写入文件时，内核会检查建立该进程的 uid 和 gid,以肯定它是否具备足够的权限来修改该文件。这里不使用用户名，使用 uid.

在服务器上运行 Docker 容器时，仍然只有一个内核。容器化带来的巨大价值在于全部这些独立的进程能够继续共享单个内核。这意味着即便在运行 Docker 容器的服务器上，整个 uids 和 gids 也由单个内核控制。

因此你不能让不一样的用户在不一样的容器中使用相同的 uid.这是由于在常见的 linux工具中显示的用户名（和组名）不是内核的一部分，而是由外部工具（/ etc / passwd，LDAP，Kerberos等）管理。所以，您可能会看到不一样的用户名，但即便在不一样的容器内，您也没法为同一个 uid / gid 拥有不一样的权限。这一开始看起来很混乱，因此咱们举几个例子说明一下：

简单的Docker运行

我将首先以 docker 组中的普通用户（marc）身份登陆服务器。这容许我在不使用 sudo 命令的状况下启动 docker 容器。而后，从容器外部，让咱们看看这个过程是如何出现的。

marc@server:~$ docker run -d ubuntu:latest sleep infinity92c57a8a4eda60678f049b906f99053cbe3bf68a7261f118e411dee173484d10marc@server:~$ ps aux | grep sleeproot 15638 0.1 0.0 4380 808 ? Ss 19:49 0:00 sleep infinity复制代码

有趣。即便我从未输入 sudo 而且我不是 root 用户，我执行的 sleep 命令也以root 用户身份启动并具备 root 权限。我怎么知道它有 root 权限？容器内的 root = =容器外的 root 吗？是的，由于正如我所提到的，有一个内核和一个共享的 uids 和 gids 池。由于用户名在容器外部显示为“root”，因此我能够确定地知道容器内的进程是由具备uid = 0的用户启动的。

具备已定义用户的Dockerfile

当我在 Dockerfile 中建立不一样的用户并以该用户身份启动命令时会发生什么？为了简化这个例子，我没有在这里指定一个gid，但一样的概念适用于组ID.

首先，我将这些命令做为用户“marc”运行，其 uid 为1001。

marc@server:~$ echo $UID1001复制代码

和 Dockerfile：

FROM ubuntu:latestRUN useradd -r -u 1001 -g appuser appuserUSER appuserENTRYPOINT [“sleep”, “infinity”]复制代码

让咱们构建并运行它：

marc@server:~$ docker build -t test .Sending build context to Docker daemon 14.34 kBStep 1/4 : FROM ubuntu:latest — -> f49eec89601eStep 2/4 : RUN useradd -r -u 1001 appuser — -> Running in 8c4c0a442ace — -> 6a81547f335eRemoving intermediate container 8c4c0a442aceStep 3/4 : USER appuser — -> Running in acd9e30b4aba — -> fc1b765e227fRemoving intermediate container acd9e30b4abaStep 4/4 : ENTRYPOINT sleep infinity — -> Running in a5710a32a8ed — -> fd1e2ab0fb75Removing intermediate container a5710a32a8edSuccessfully built fd1e2ab0fb75marc@server:~$ docker run -d test8ad0cd43592e6c4314775392fb3149015adc25deb22e5e5ea07203ff53038073marc@server:~$ ps aux | grep sleepmarc 16507 0.3 0.0 4380 668 ? Ss 20:02 0:00 sleep infinitymarc@server:~$ docker exec -it 8ad0 /bin/bashappuser@8ad0cd43592e:/$ ps aux | grep sleepappuser 1 0.0 0.0 4380 668 ? Ss 20:02 0:00 sleep infinity复制代码

到底发生了什么，这代表了什么？我构建了一个 Docker 镜像，其用户名为“appuser”，该用户的定义 uid 为1001。在个人测试服务器上，我正在使用的账户名为“marc”，它的 uid 为1001。我启动容器，sleep 命令做为 appuser 执行，由于 Dockerfile 包含“USER appuser”行。但这实际上并无使它做为 appuser 运行，它使它做为用户的 uid 运行，Docker 镜像知道appuser.

当我检查在容器外部运行的进程时，我看到它被映射到用户“marc”，可是在容器内部它被映射到用户“appuser”。这两个用户名只显示其执行上下文知道的用户名映射到1001。

这不是很是重要的。但重要的是要知道在容器内部，用户“appuser”从容器外获取用户“marc”的权限和特权。在linux主机上向用户 marc 或uid 1001授予权限也将授予容器内 appuser 的这些权限。

如何控制容器的访问权限

另外一种选择是运行 docker 容器并指定用户名或 uid,以及运行时的组名或gid。

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

marc@server:~$ docker run -d --user 1001 ubuntu:latest sleep infinity84f436065c90ac5f59a2256e8a27237cf8d7849d18e39e5370c36f9554254e2bmarc@server$ ps aux | grep sleepmarc     17058 0.1 0.0 4380 664 ? Ss 21:23 0:00 sleep infinity复制代码

我在这作什么 我建立了容器以做为1001用户启动。所以，当我执行诸如 ps 或top（或大多数监视工具）之类的命令时，该过程将映射到“marc”用户。

有趣的是，当我执行到该容器时，您能够看到1001用户在/ etc / passwd 文件中没有条目，并在容器的 bash 提示符中显示为“我没有名字！”。

marc@server:~$ docker exec -it 84f43 /bin/bashI have no name!@84f436065c90:/$复制代码

须要注意的是，在建立容器时指定用户标志也会覆盖 Dockerfile 中的该值。还记得第二个例子，我使用的 Dockerfile 有一个映射到本地主机上不一样用户名的uid吗？当咱们在命令行上使用用户标志运行它以启动执行“睡眠无限”过程的容器时会发生什么？

marc@server:$ docker run -d test489a236261a0620e287e434ed1b15503c844648544694e538264e69d534d0d65marc@server:~$ ps aux | grep sleepmarc     17689 0.2 0.0 4380 680 ? Ss 21:28 0:00 sleep infinitymarc@server:~$ docker run --user 0 -d testac27849fcbce066bad37190b5bf6a46cf526f56d889af61e7a02c3726438fa7amarc@server:~$ ps aux | grep sleepmarc     17689 0.0 0.0 4380 680 ? Ss 21:28 0:00 sleep infinityroot     17783 0.3 0.0 4380 668 ? Ss 21:28 0:00 sleep infinity复制代码

在上面的最后一个例子中，你能够看到我最终有2个容器运行睡眠过程，一个用做“marc”，另外一个用做“root”。这是由于第二个命令经过--user 在命令行上传递标志来更改uid.

这意味着什么？

如今咱们已经探讨了这一点，有意义的是，运行具备有限权限的容器的方法都利用来自主机的用户系统：

一、若是已知的 uid 表示容器内的进程正在执行，则可能就像限制对主机系统的访问同样简单，以便容器中的 uid 有有限的访问权限。

二、更好的解决方案是使用已知的 uid 启动容器--user（您也可使用用户名，但请记住，它只是从主机的用户名系统提供uid的更友好的方式），而后限制对主机上的 uid 的访问你决定容器将运行为。

三、因为 uid 和用户名（以及gid和组名称）如何从容器映射到主机，所以指定容器化进程运行的用户可使进程看起来由内部和容器外部的不一样用户拥有。

注意这些测试

我在 Ubuntu 16.04服务器上运行这些测试。虽然能够在 Docker for OSX 上执行相同的命令和测试，但您会看到不一样的结果，由于 Docker for OSX 其实是在基于 Alpine Linux 的虚拟机上执行 docker-engine，而且您执行的命令正在OSX 上执行。

- end -

做者：Marc Campbell

本文转载于外网，转载请标明出处