进入容器根目录_只是对根说不（在容器中）

最新推荐文章于 2024-05-02 01:42:38 发布

cumj63710

最新推荐文章于 2024-05-02 01:42:38 发布

阅读量856

点赞数

原文链接：https://opensource.com/article/18/3/just-say-no-root-containers

版权

本文探讨了为何大多数容器映像需要root用户，包括修改主机系统、绑定低端口和安装软件的需求。然而，大部分应用并不需要以root权限运行。文中建议使用端口转发、分离构建和运行时权限以及推动软件包管理系统支持非root安装，以提高容器安全性。底线是，大多数软件在容器中不应以root身份运行。

摘要由CSDN通过智能技术生成

进入容器根目录

我一直被问到用于控制系统上的容器进程可以执行的不同安全措施。我在Opensource.com上的先前文章中介绍了其中的大多数内容：

以上几乎所有文章都是关于控制系统上的特权进程可以在容器中执行的操作。例如：如何在容器中运行root而不让它爆发？

OpenShift是Red Hat的容器平台，建立在Kubernetes ，Red Hat Enterprise Linux和OCI容器的基础上，它具有强大的安全性功能：默认情况下，不允许任何容器以root身份运行。管理员可以覆盖此设置，否则所有用户容器都无需root就可以运行。这在多租户OpenShift Kubernetes集群中尤其重要，在该集群中，一个集群可能为多个应用程序和多个开发团队提供服务。管理员为每个集群运行单独的集群并不总是可行甚至是不明智的。遗憾的是，有关OpenShift的最大抱怨之一是用户无法轻松运行docker.io上所有可用的社区容器映像。这是因为当今世界上绝大多数的容器映像都需要根目录。

为什么所有这些映像都需要root用户？

如果您实际上检查了成为根源的原因，那么在系统上，它们是非常有限的。

修改主机系统：

成为系统根用户的一个主要原因是更改系统的默认设置，例如修改内核的配置。
在Fedora，CentOS和Red Hat Enterprise Linux中，我们有系统容器的概念，它们是特权容器，可以使用atomic命令安装在系统上。它们可以完全特权运行，并且可以修改系统和内核。对于系统容器，我们将容器映像用作内容交付系统，而不是真正寻找容器分离。与大多数容器运行的用户应用程序服务相反，系统容器更多地用于核心操作系统主机服务。
在应用程序容器中，我们几乎从不希望容器内的进程修改内核。默认情况下绝对不需要。

Unix / Linux传统：

操作系统软件供应商和开发人员长期以来一直以root用户身份运行进程是众所周知的，因此内核添加了许多Linux功能，以允许进程以root用户身份启动，然后尽快放弃特权。大多数UID / GID功能允许Web服务之类的进程以root用户身份启动，然后成为非root用户身份。这样做是为了绑定到低于1024的端口（稍后会对此进行更多介绍）。
容器运行时可以以非root用户身份启动应用程序。真相是众所周知的，systemd也是如此，但是在过去20年中构建的大多数软件都假定它以root特权和放弃特权开始。

绑定到<1024的端口

追溯到1960年代和1970年代，当时计算机很少，无特权用户无法绑定到<1024的网络端口被认为是一种安全功能。因为只有管理员才能执行此操作，所以您可以信任在这些端口上侦听的应用程序。端口> 1024可以被系统上的任何用户绑定，因此它们不能被信任。这样做的安全性优势已基本消失，但我们仍然可以承受此限制。
这种限制的最大问题是人们喜欢让Web服务器在端口80上监听的Web服务。这意味着apache或nginx开始以root用户身份运行的主要原因是，它们可以绑定到端口80，然后变为非端口。根。
使用端口转发的容器运行时可以解决此问题。您可以设置一个容器以侦听任何网络端口，然后使容器运行时将该端口映射到主机上的端口80。

在此命令中， podman运行时将在您的计算机上运行apache_unpriv容器，侦听主机上的端口80，而该容器内的Apache进程从不root，以apache用户身份启动，并告诉其侦听端口8080。


podman run -d -p 80:8080 -u apache apache_unpriv

或者：


docker run -d -p 80:8080 -u apache apache_unpriv

将软件安装到容器映像中

当Docker通过docker build引入构建容器时，容器中的内容只是用于分发的标准打包软件。该软件通常通过rpm软件包或Debian软件包来提供。好了，分发软件包将由root安装。软件包希望能够通过添加用户来完成诸如操作/etc/passwd文件之类的操作，并希望将具有不同UID / GID的内容放到文件系统中。许多软件还期望通过init系统（systemd）启动，并以root身份启动，然后在启动后放弃特权。
可悲的是，进入集装箱革命已经五年了，这仍然是现状。几年前，我试图让httpd软件包知道非root用户何时安装它，并进行其他配置。但是我为此丢下了球。我们需要让打包程序和程序包管理系统开始了解它们之间的区别，然后我们可以使运行良好的容器而无需root用户。
我们现在可以解决此问题的一件事是将构建系统与安装系统分开。 #nobigfatdaemons的问题之一是Docker守护程序导致以相同的privs运行容器以运行容器，而该privs则与构建容器映像相同。
如果我们更改系统或使用其他工具（例如Buildah ）来构建具有较宽松约束的容器，并使用CRI-O / Kubernetes / OpenShift来在生产环境中运行容器，那么我们可以使用提升的特权进行构建，但是随后可以在运行容器的同时使用很多特权严格的限制，或者希望成为非root用户。