Docker安全（使用Cgroups机制实现容器资源控制）

文章目录

• 前言
• 理解docker安全
• 命名空间隔离的安全
• 控制组资源控制的安全
• 内核能力机制
• Docker服务端防护
• 其他安全特性
• 容器资源控制
• CPU限制
• 内存限制
• Block IO限制

https://www.cnblogs.com/wish123/p/5573098.html

前言

• Docker作为最重视安全的容器技术之一，在很多方面都提供了强安全性的默认配置，其中包括：容器root用户的Capability能力限制、Seccomp系统调用过滤、Apparmor的 MAC 访问控制、ulimit限制、pid-limits的支持，镜像签名机制等。

• Docker利用Namespace实现了6项隔离，看似完整，实际上依旧没有完全隔离Linux资源，比如/proc 、/sys 、/dev/sd*等目录未完全隔离，SELinux、time、syslog等所有现有Namespace之外的信息都未隔离。 其实Docker在安全性上也做了很多工作，大致包括下面几个方面：
  

• 1、Linux内核 Capability 能力限制
  Docker支持为容器设置Capabilities，指定开放给容器的权限。这样在容器中的root用户比实际的root少很多权限。Docker 在0.6版本以后支持将容器开启超级权限，使容器具有宿主机的root权限。

• 2、镜像签名机制
  Docker 1.8版本以后提供了镜像签名机制来验证镜像的来源和完整性，这个功能需要手动开启，这样镜像制作者可以在push镜像前对镜像进行签名，在镜像pull的时候，Docker不会pull验证失败或者没有签名的镜像标签。

• 3、Apparmor的MAC访问控制
  Apparmor可以将进程的权限与进程Capabilities能力联系在一起，实现对进程的强制性访问控制（MAC）。在Docker中，我们可以使用Apparmor来限制用户只能执行某些特定命令、限制容器网络、文件读写权限等功能。

• 4、Seccomp系统调用过滤
  使用Seccomp可以限制进程能够调用的系统调用（system call）的范围，Docker提供的默认Seccomp配置文件已经禁用了大约44个超过300+的系统调用，满足大多数容器的系统调用诉求。

• 5、User Namespace隔离
  Namespace为运行中进程提供了隔离，限制他们对系统资源的访问，而进程没有意识到这些限制，为防止容器内的特权升级攻击的最佳方法是将容器的应用程序配置为作为非特权用户运行，对于其进程必须作为容器中的root用户运行的容器，可以将此用户重新映射到Docker主机上权限较低的用户。映射的用户被分配了一系列UID，这些UID在命名空间内作为从0到65536的普通UID运行，但在主机上没有特权。

• 6、SELinux
  SELinux主要提供了强制访问控制（MAC），即不再是仅依据进程的所有者与文件资源的rwx权限来决定有无访问能力。能在攻击者实施了容器突破攻击后增加一层壁垒。Docker提供了对SELinux的支持。

• 7、pid-limits的支持
  在说pid-limits前，需要说一下什么是fork炸弹（fork bomb），fork炸弹就是以极快的速度创建大量进程，并以此消耗系统分配予进程的可用空间使进程表饱和，从而使系统无法运行新程序。说起进程数限制，大家可能都知道ulimit的nproc这个配置，nproc是存在坑的，与其他ulimit选项不同的是，nproc是一个以用户为管理单位的设置选项，即他调节的是属于一个用户UID的最大进程数之和。这部分内容下一篇会介绍。Docker从1.10以后，支持为容器指定–pids-limit 限制容器内进程数，使用其可以限制容器内进程数。

• 8、其他内核安全特性工具支持
  在容器生态的周围，还有很多工具可以为容器安全性提供支持，比如可以使用Docker bench audit tool（工具地址：https://github.com/docker/docker-bench-security）检查你的Docker运行环境，使用Sysdig Falco（工具地址：https://sysdig.com/opensource/falco/） 来检测容器内是否有异常活动，可以使用GRSEC 和 PAX来加固系统内核等等。

Linux内核Capability能力限制
1.Capabilities简单来说，就是指开放给进程的权限，比如允许进程可以访问网络、读取文件等。Docker容器本质上就是一个进程，默认情况下，Docker会删除必须的Capabilities外的所有Capabilities，可以在Linux手册页 中看到完整的可用Capabilities列表。Docker 0.6版本以后支持在启动参数中增加–privileged选项为容器开启超级权限。
2.Docker支持Capabilities对于容器安全意义重大，因为在容器中我们经常会以root用户来运行，使用Capability限制后，容器中的root比真正的root用户权限少得多。这就意味着，即使入侵者设法在容器内获取了root权限，也难以做到严重破坏或获得主机root权限。

当我们在docker run时指定了–privileded选项，Docker其实会完成两件事情：
1.获取系统root用户所有能力赋值给容器；
2.扫描宿主机所有设备文件挂载到容器内。

理解docker安全

• Docker容器的安全性，很大程度上依赖于Linux系统自身，评估Docker的安全性时，主要考虑以下几个方面：
  1.Linux内核的命名空间机制提供的容器隔离安全
  2.Linux控制组机制对容器资源的控制能力安全。
  3.Linux内核的能力机制所带来的操作权限安全
  4.Docker程序（特别是服务端）本身的抗攻击性。
  5.其他安全增强机制对容器安全性的影响。

命名空间隔离的安全

• 当docker run启动一个容器时，Docker将在后台为容器创建一个独立的命名空间。命名空间提供了最基础也最直接的隔离。
• 与虚拟机方式相比，通过Linux namespace来实现的隔离不是那么彻底。
• 容器只是运行在宿主机上的一种特殊的进程，那么多个容器之间使用的就还是同一个宿主机的操作系统内核。
• 在 Linux 内核中，有很多资源和对象是不能被 Namespace 化的，比如：时间。

控制组资源控制的安全

• 当docker run启动一个容器时，Docker将在后台为容器创建一个独立的控制组策略集合。
• Linux Cgroups提供了很多有用的特性，确保各容器可以公平地分享主机的内存、CPU、磁盘IO等资源。
• 确保当发生在容器内的资源压力不会影响到本地主机系统和其他容器，它在防止拒绝服务攻击（DDoS）方面必不可少。

内核能力机制

• 能力机制（Capability）是Linux内核一个强大的特性，可以提供细粒度的权限访问控制。
• 大部分情况下，容器并不需要“真正的”root权限，容器只需要少数的能力即可。
• 默认情况下，Docker采用“白名单”机制，禁用“必需功能”之外的其他权限。

Docker服务端防护

• 使用Docker容器的核心是Docker服务端，确保只有可信的用户才能访问到Docker服务。
• 将容器的root用户映射到本地主机上的非root用户，减轻容器和主机之间因权限提升而引起的安全问题。
• 允许Docker 服务端在非root权限下运行，利用安全可靠的子进程来代理执行需要特权权限的操作。这些子进程只允许在特定范围内进行操作。

其他安全特性

• 在内核中启用GRSEC和PAX，这将增加更多的编译和运行时的安全检查；并且通过地址随机化机制来避免恶意探测等。启用该特性不需要Docker进行任何配置。
• 使用一些有增强安全特性的容器模板。
• 用户可以自定义更加严格的访问控制机制来定制安全策略。
• 在文件系统挂载到容器内部时，可以通过配置只读模式来避免容器内的应用通过文件系统破坏外部环境，特别是一些系统运行状态相关的目录。

容器资源控制

• Linux Cgroups 的全称是 Linux Control Group。是限制一个进程组能够使用的资源上限，包括 CPU、内存、磁盘、网络带宽等等。对进程进行优先级设置、审计，以及将进程挂起和恢复等操作。
• Linux Cgroups 给用户暴露出来的操作接口是文件系统。它以文件和目录的方式组织在操作系统的 /sys/fs/cgroup 路径下。执行此命令查看：mount -t cgroup 。
• 在 /sys/fs/cgroup 下面有很多诸如 cpuset、cpu、 memory 这样的子目录，也叫子系统。在每个子系统下面，为每个容器创建一个控制组（即创建一个新目录）。控制组下面的资源文件里填上什么值，就靠用户执行 docker run 时的参数指定。

CPU限制

• 打开docker并监测cgroup是否开启。（都显示on则表示开启）

[root@server2 ns]# systemctl start docker
[root@server2 ns]# mount -t cgroup
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_prio,net_cls)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)

• 查看cgroup子系统的层级路径
  
• 建立一个CPU控制族群
  首先进入cpu子系统对应的层级路径下：cd /sys/fs/cgroup/cpu
  通过新建文件夹创建一个cpu控制族群：mkdir x2，即新建了一个cpu控制族群：x2
  新建x2之后，可以看到目录下自动建立了相关的文件，这些文件是伪文件

[root@server2 ~]# cd /sys/fs/cgroup/
[root@server2 cgroup]# pwd
/sys/fs/cgroup
[root@server2 cgroup]# cd cpu
[root@server2 cpu]# ls
cgroup.clone_children  cpuacct.usage         cpu.rt_runtime_us  release_agent
cgroup.event_control   cpuacct.usage_percpu  cpu.shares         system.slice
cgroup.procs           cpu.cfs_period_us     cpu.stat           tasks
cgroup.sane_behavior   cpu.cfs_quota_us      docker             user.slice
cpuacct.stat           cpu.rt_period_us      notify_on_release
[root@server2 cpu]# mkdir x2    ##新建x2目录
[root@server2 cpu]# cd x2/    
[root@server2 x2]# ll   #目录里自动生成相关文件

• （4）测试限制cpu的使用
  我们的测试示例主要用到cpu.cfs_period_us和cpu.cfs_quota_us两个文件。
  cpu.cfs_period_us：cpu分配的周期(微秒），默认为100000。
  cpu.cfs_quota_us：表示该control group限制占用的时间（微秒），默认为-1，表示不限制。
  如果设为20000，表示占用20000/100000=20%的CPU。

[root@server2 x2]# cat cpu.cfs_period_us 
100000
[root@server2 x2]# cat cpu.cfs_quota_us    ##默认为-1，表示不限制
-1
[root@server2 x2]# echo 20000 > cpu.cfs_quota_us  ##修改占用率为20%
[root@server2 x2]# cat cpu.cfs_quota_us 
20000

• （5）测试

[root@server2 x2]# dd if=/dev/zero of=/dev/null &   ##开启任务。打入后台，然后使用【top】命令查看查看占用了百分之100
[1] 7269

• （6）创建一个容器，并限制cpu的使用

[root@server2 x2]# echo 7269 > tasks   #dd的进程号
[root@server2 x2]# fg
dd if=/dev/zero of=/dev/null
^C284939879+0 records in
284939879+0 records out
145889218048 bytes (146 GB) copied, 125.765 s, 1.2 GB/s

[root@server2 x2]# docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
55812d272e99        ubuntu              "/bin/bash"         15 minutes ago      Up 15 minutes                           vm1
[root@server2 x2]# docker run -it --name vm2 --cpu-quota=20000 ubuntu
root@4df74ed95346:/# [root@server2 x2]# 
[root@server2 x2]# docker attach vm2
root@4df74ed95346:/# dd if=/dev/zero of=/dev/null &
[1] 15

• 再开一个shell查看 top > cpu 使用率20%
  
  假如在创建容器时不做限制，那么占用率会达到100%

[root@server2 x2]# docker run -it --name vm3 ubuntu
root@33da6039575f:/# dd if=/dev/zero of=/dev/null

内存限制

示例：
容器可用内存包括两个部分:物理内存和swap交换分区。
docker run -it --memory 200M --memory-swap=200M ubuntu
–memory设置内存使用限额
–memory-swap设置swap交换分区限额

• 具体过程如下：
  （1）安装cgroup，可提供cgexec命令。

[root@server2 ~]# yum install libcgroup-tools -y
[root@server2 ~]# cd /sys/fs/cgroup/memory/
[root@erver2 memory]# ls

[root@server2 memory]# cat memory.limit_in_bytes 
9223372036854771712    #数字太大，等同于没有限制。
[root@server2 memory]# cat memory.memsw.limit_in_bytes 
9223372036854771712

• （2）设定资源限制参数：内存+交换分区<=300M

[root@server1 ~]# cd /sys/fs/cgroup/memory/
[root@server1 memory]# mkdir ##snow 创建目录snow,该目录的名字随意给。 ##在/sys/fs/cgroup/memory目录创建的目录,自动继承/sys/fs/cgroup/memory目录中的内容。创建该目录的目的是(1)为了演示容器的运行过程。因为一旦运行容器,就会在该目录下,生成一个docker目录, docker目录中会生成容器ID对应的目录,目录中memory目录下的内容继承于/sys/fs/cgroup/memeory目录下的内容。 ##(2)直接修改/sys/fs/cgroup/memory中的文件的内容,会报错。
[root@server1 memory]# echo 209715200 > memory.limit_in_bytes 
-bash: echo: write error: Invalid argument
[root@server1 memory]# cd snow/ 
[root@server1 snow]# echo 209715200 > memory.limit_in_bytes #设定最大占用内存为200M(209715200=200*1024*1024。209715200的单位为BB) 
[root@server1 snow]# echo 209715200 > memory.memsw.limit_in_bytes #因为最大占用内存数和最大占 用swap分区的内存数一样。表明最大可用内存为200M,可用swap为0M。即限制了内存+交换分区<=200M 
[root@server1 snow]# cat memory.limit_in_bytes 209715200 
[root@server1 snow]# cat memory.memsw.limit_in_bytes 209715200 
值的注意的是：/sys/fs/cgroup/memory目录中的文件，不能用vim进行编辑， 利用vim进行编辑，无法进行保存退出（即使使用"wq!"，也不能保存退出。）

• 现在可用内存为300M，测试：

[root@server2 shm]# pwd
/dev/shm
[root@server2 shm]# cgexec -g memory:x1 dd if=/dev/zero of=file bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.0959029 s, 1.1 GB/s
[root@server2 shm]# free -m
              total        used        free      shared  buff/cache   available
Mem:           3791         285        2956         116         549        3154     #我们发现可用内存少了100M
Swap:           499           0         499
[root@server2 shm]# cgexec -g memory:x1 dd if=/dev/zero of=file bs=1M count=400   #因为指定的文件的大小为400M超过了限制,所以显示Killed,这就是之前我们为目录设置的限制，其最多只能占用300M
Killed
[root@server2 shm]# free -m
              total        used        free      shared  buff/cache   available
Mem:           3791         287        2755         315         748        2952
Swap:           499           0         499
[root@server2 shm]# du -sh file 
299M	file

• 注意：如果不对内存和swap分区进行限制，即不修改/sys/fs/cgroup/memory/memory.limit_in_bytes和/sys/fs/cgroup/memory/memory.memsw.limit_in_bytes文件中的内容。那么不管要生成的bigfile文件的大小为多少，dd命令永远会成功。
• 如果只是对内存进行限制（限制为200M），而没有对交换f分区进行限制，即只修改/sys/fs/cgroup/memory/memory.limit_in_bytes文件中的内容，而并没有修改/sys/fs/cgroup/memory/memory.memsw.limit_in_bytes文件中的内容。那么如果要生成的bigfile文件的大小大于200M，dd命令会成功，但是只有200M是取自内存，剩余的取自交换分区。
• （1）指定内存和交换分区的大小，运行容器

[root@server2 ~]# docker run -it --name vm1 --memory 104857600 --memory-swap 104857600 ubuntu
root@55812d272e99:/# [root@server2 ~]#      ##利用ubuntu镜像运行容器vm1,指定内存+交换分区<100M。并使用Ctrl+p+q退出,即不要让容器停掉。

• 查看设置是否生效。

[root@server2 ~]# cd /sys/fs/cgroup/memory/docker/
[root@server2 docker]# ls
[root@server2 docker]# cd 55812d272e9989c571fecf38b05745e8330130677027144d913b0396e6ac74ac
[root@server2 55812d272e9989c571fecf38b05745e8330130677027144d913b0396e6ac74ac]# ls

• 上面的字符串是我们查看到的内存和交换分区大小符合我们设置的大小，我们确认一下容器ID，以确保我们查看的确实是我们运行的容器
• 值的注意的是：因为容器的隔离性并不是很好
  所以在容器内使用命令"free -m"看到的内容与宿主机上使用命令"free -m"看到的内容相同
  所以如果要看是否限制成功，需要进入容器对应的目录中进行查看

[root@server2 55812d272e9989c571fecf38b05745e8330130677027144d913b0396e6ac74ac]# cat memory.limit_in_bytes 
104857600
[root@server2 55812d272e9989c571fecf38b05745e8330130677027144d913b0396e6ac74ac]# cat memory.memsw.limit_in_bytes
104857600
[root@server2 55812d272e9989c571fecf38b05745e8330130677027144d913b0396e6ac74ac]# cd
[root@server2 ~]# docker ps 

• 上面的字符串是我们查看到的内存和交换分区大小符合我们设置的大小，我们确认一下容器ID，以确保我们查看的确实是我们运行的容器
  

Block IO限制

docker run -it --device-write-bps /dev/sda:30MB ubuntu
–device-write-bps限制写设备的bps
目前的block IO限制只对direct IO有效(不能使用文件系统缓存)

• （1）首先可以查看一下分区，确定写入的位置

[root@server2 ~]# docker run -it --rm --privileged=true ubuntu
root@a2996186323a:/# fdisk -l

Disk /dev/vda: 8589 MB, 8589934592 bytes
16 heads, 63 sectors/track, 16644 cylinders, total 16777216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0008af01

   Device Boot      Start         End      Blocks   Id  System
/dev/vda1   *        2048      411647      204800   83  Linux
/dev/vda2          411648    16777215     8182784   8e  Linux LVM

• （2）新建容器，进行测试

[root@server2 ~]# docker run -it --rm --device-write-bps /dev/vda:30M ubuntu
root@860272c843f0:/# dd if=/dev/zero of=file bs=1M count=300 oflag=direct
300+0 records in
300+0 records out
314572800 bytes (315 MB) copied, 10.355 s, 30.4 MB/s   #用时约10s
root@860272c843f0:/# dd if=/dev/zero of=file bs=1M count=300             
300+0 records in
300+0 records out
314572800 bytes (315 MB) copied, 0.337771 s, 931 MB/s   #用时不到1s

• 由上图可见，我们对容器IO限制奏效，至于在演示操作中，为什么第二次的写入速度如此之快
  这取决于参数【oflag=direct】，它的意思是指：读写数据采用直接IO方式

标签：容器,Cgroups,server2,cgroup,memory,Docker,root
来源： https://blog.csdn.net/even160941/article/details/98748796