特权容器和功能

时间:2016-04-05 11:34:00

标签: docker linux-kernel kubernetes linux-capabilities

如果我在特权模式下运行容器,它是否具有所有内核功能,还是需要单独添加它们?

3 个答案:

答案 0 :(得分:46)

在特权模式下运行确实为容器提供了所有功能。 但优良作法是始终为容器提供所需的最低要求 如果你看看Docker文档,他们也会引用这个标志

  

完整容器功能( - 特权)

     

--privileged标志为容器提供了所有功能,它还解除了设备cgroup控制器强制执行的所有限制。换句话说,容器几乎可以完成主机可以执行的所有操作。此标志用于允许特殊用例,例如在Docker中运行Docker。

您可以使用--cap-add标志提供特定功能。有关这些功能的详细信息,请参阅man 7 capabilities。可以使用文字名称,例如--cap-add CAP_FOWNER

答案 1 :(得分:35)

由于这篇文章在谷歌搜索排名很高,我想添加一些信息,说明为什么你不想使用--privileged

来运行容器

我在具有NVMe驱动器的笔记本电脑上执行此操作,但它适用于任何主机。

docker run --privileged -t -i --rm ubuntu:latest bash

首先让我们做一些小事,来测试/ proc文件系统

从容器中:

root@507aeb767c7e:/# cat /proc/sys/vm/swappiness
60
root@507aeb767c7e:/# echo "61" > /proc/sys/vm/swappiness    
root@507aeb767c7e:/# cat /proc/sys/vm/swappiness
60

确定它是为容器还是为主机更改它?

$ cat /proc/sys/vm/swappiness
61

OOPS !,我们可以随意更改主机内核参数。但这只是DOS情况,让我们看看我们是否可以从父主机收集特权信息。

让我们走/sys树,找到启动盘的主要次要编号。

注意:我有两个NVMe驱动器,容器在另一个驱动器上的LVM下运行

root@507aeb767c7e:/proc# cat /sys/block/nvme1n1/dev
259:2

确定可以在dbus规则不会自动扫描的位置创建设备文件。

root@507aeb767c7e:/proc# mknod /devnvme1n1 b 259 2
root@507aeb767c7e:/proc# sfdisk -d /devnvme1n1 
label: gpt
label-id: 1BE1DF1D-3523-4F22-B22A-29FEF19F019E
device: /devnvme1n1
unit: sectors
first-lba: 34
last-lba: 2000409230
<SNIP>

好的,我们可以读取bootdisk,让我们为其中一个分区制作一个设备文件。虽然我们无法安装它,因为它将打开,我们仍然可以使用dd来复制它。

root@507aeb767c7e:/proc# mknod /devnvme1n1p1 b 259 3
root@507aeb767c7e:/# dd if=devnvme1n1p1 of=foo.img
532480+0 records in
532480+0 records out
272629760 bytes (273 MB, 260 MiB) copied, 0.74277 s, 367 MB/s

确定可以安装它,看看我们的努力是否有效!!!

root@507aeb767c7e:/# mount -o loop foo.img /foo
root@507aeb767c7e:/# ls foo
EFI
root@507aeb767c7e:/# ls foo/EFI/
Boot  Microsoft  ubuntu

所以基本上任何允许任何人启动--privileged容器的容器主机与给予它们对该主机上每个容器的root访问权限相同。

不幸的是,docker项目选择了可信计算模型,并且在auth插件之外没有办法防止这种情况,所以在添加所需功能方面总是出错而不是使用--privileged

答案 2 :(得分:4)

有一篇很好的文章涵盖from RedHat covering this

虽然作为“root”运行的docker容器的权限少于主机上的root权限,但仍可能需要强化,具体取决于您的用例(用作开发环境与共享生产群集)