Docker安全性支持

Docker安全性支持

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来加固系统内核等等。

一.Docker安全评估

Docker容器的安全性,很大程度上依赖于Linux系统自身,评估Docker的安全性时,主要考虑以下几个方面:

• Linux内核的命名空间机制提供的容器隔离安全
• Linux控制组机制对容器资源的控制能力安全。
• Linux内核的能力机制所带来的操作权限安全
• Docker程序(特别是服务端)本身的抗攻击性。
• 其他安全增强机制对容器安全性的影响。

下面简单谈谈上面所说的五个方面：

• 命名空间隔离的安全
  当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进行任何配置。
  使用一些有增强安全特性的容器模板。
  用户可以自定义更加严格的访问控制机制来定制安全策略。
  在文件系统挂载到容器内部时,可以通过配置只读模式来避免容器内的应用通过文件系统破坏外部环境,特别是一些系统运行状态相关的目录。

内存控制

1.安装cgroup，可提供cgexec命令

[root@server4 gzl]# yum install libcgroup-tools -y

[root@server4 ~]# cd /sys/fs/cgroup/
[root@server4 cgroup]# ls
blkio    cpu,cpuacct  freezer  net_cls           perf_event
cpu      cpuset       hugetlb  net_cls,net_prio  pids
cpuacct  devices      memory   net_prio          systemd
[root@server4 cgroup]# cd memory/
[root@server4 memory]# mkdir gzl			##这个目录名自定义

##在/sys/fs/cgroup/memory目录中创建的目录,自动继承/sys/fs/cgroup/memory目录中的内容。
创建该目录的目的是(1)为了演示容器的运行过程。因为一旦运行容器,就会在该目录下,生成一个docker目录,
docker目录中会生成容器ID对应的目录,目录中memory目录下的内容继承于/sys/fs/cgroup/memeory目录下的内容。
##(2)直接修改/sys/fs/cgroup/memory中的文件的内容,会报错。

2.设定资源限制参数：内存+交换分区<=300M
[root@server4 gzl]# cat memory.limit_in_bytes
9223372036854771712
[root@server4 gzl]# echo 314572800 > memory.limit_in_bytes
#设定最大占用内存为300M( 314572800 =30010241024。314572800 的单位为BB)
[root@server4 gzl]# cat memory.limit_in_bytes
314572800
[root@server4 gzl]# echo 314572800 > memory.memsw.limit_in_bytes
#因为最大占用内存数和最大占 用swap分区的内存数一样。表明最大可用内存为300M,可用swap为0M。即限制了内存+交换分区<=300M
[root@server4 gzl]# cat memory.memsw.limit_in_bytes
314572800


现在可用的内存

3.测试：
[root@server4 gzl]# cd /dev/shm
[root@server4 shm]# cgexec -g memory:gzl dd if=/dev/zero of=bigfile bs=1M count=200
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 0.0692426 s, 3.0 GB/s
[root@server4 shm]# free -m
total used free shared buff/cache available
Mem: 3952 155 3207 216 589 3349
Swap: 2047 0 2047
##我们发现可用内存少了200M
[root@server4 shm]# cgexec -g memory:gzl dd if=/dev/zero of=bigfile bs=1M count=400
Killed
##因为指定的文件的大小为400M超过了限制,所以显示Killed,这就是之前我们为gzl目录设置的限制，其最多只能占用300M
[root@server4 shm]# free -m
total used free shared buff/cache available
Mem: 3952 155 3108 315 688 3250
Swap: 2047 0 2047
##内存少了300M

如果不对内存和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是取自内存，剩余的取自交换分区。

容器的内存限制
指定内存和交换分区的大小，运行容器
[root@server4 shm]# docker run -it --name vm1 --memory 314572800 --memory-swap 314572800 ubuntu
root@7e71d0f8940f:/# free -m
total used free shared buffers cached
Mem: 3952 863 3088 315 0 644
-/+ buffers/cache: 218 3733
Swap: 2047 0 2047
因为容器的隔离性并不是很好，所以在容器内使用命令"free -m"看到的内容与宿主机上使用命令"free -m"看到的内容相同。所以如果要看是否限制成功，需要进入容器对应的目录中进行查看。
查看设置是否生效
[root@server4 shm]# cd /sys/fs/cgroup/memory/docker/

查看我们刚才运行的容器的ID

[root@server4 docker]# cd 7e71d0f8940fdf2f3f3902bc199e7060c2735552eeb68170b016dda68288f945
[root@server4 7e71d0f8940fdf2f3f3902bc199e7060c2735552eeb68170b016dda68288f945]# cat memory.limit_in_bytes
314572800
[root@server4 7e71d0f8940fdf2f3f3902bc199e7060c2735552eeb68170b016dda68288f945]# cat memory.memsw.limit_in_bytes
314572800

容器资源控制（二）：CPU限额

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

[root@server4 cpu]# mkdir pro1
[root@server4 cpu]# cd pro1/
[root@server4 pro1]# ls
cgroup.clone_children cpuacct.usage_percpu cpu.shares
cgroup.event_control cpu.cfs_period_us cpu.stat
cgroup.procs cpu.cfs_quota_us notify_on_release
cpuacct.stat cpu.rt_period_us tasks
cpuacct.usage cpu.rt_runtime_us

[root@server4 pro1]# dd if=/dev/zero of=/dev/null &
[1] 1354
[root@server4 pro1]# top

top - 09:57:42 up 51 min, 1 user, load average: 0.08, 0.02, 0.01
Tasks: 94 total, 3 running, 91 sleeping, 0 stopped, 0 zombie
%Cpu(s): 10.0 us, 40.1 sy, 0.0 ni, 49.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 4046916 total, 3591104 free, 140768 used, 315044 buff/cache
KiB Swap: 2097148 total, 2097148 free, 0 used. 3660364 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1354 root 20 0 107940 608 516 R 100.0 0.0 0:09.40 dd
1 root 20 0 43164 3524 2384 S 0.0 0.1 0:01.04 systemd

[root@server4 pro1]# echo 1354 > tasks
[root@server4 pro1]# cat cpu.cfs_quota_us
-1 ##默认为-1，表示不限制
[root@server4 pro1]# echo 30000 > cpu.cfs_quota_us ##修改占用cpu的30%
[root@server4 pro1]# cat cpu.cfs_quota_us
30000

[root@server4 pro1]# top

top - 09:59:44 up 53 min, 1 user, load average: 0.62, 0.28, 0.10
Tasks: 94 total, 3 running, 91 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.3 us, 11.5 sy, 0.0 ni, 85.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 4046916 total, 3591196 free, 140680 used, 315040 buff/cache
KiB Swap: 2097148 total, 2097148 free, 0 used. 3660456 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1354 root 20 0 107940 608 516 R 29.9 0.0 1:58.91 dd
1 root 20 0 43164 3524 2384 S 0.0 0.1 0:01.04 systemd

容器CPU限额

容器资源控制（三）：Block IO限制（限制写入速度）

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

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

2.新建容器，进行测试
[root@server4 ~]# docker run -it --name vm3 --device-write-bps /dev/sda:10MB ubuntu
root@8f0d58b68a2a:/# df
Filesystem 1K-blocks Used Available Use% Mounted on
overlay 17811456 4709916 13101540 27% /
tmpfs 65536 0 65536 0% /dev
tmpfs 2023456 0 2023456 0% /sys/fs/cgroup
/dev/mapper/rhel-root 17811456 4709916 13101540 27% /etc/hosts
shm 65536 0 65536 0% /dev/shm
tmpfs 2023456 0 2023456 0% /proc/asound
tmpfs 2023456 0 2023456 0% /proc/acpi
tmpfs 2023456 0 2023456 0% /proc/scsi
tmpfs 2023456 0 2023456 0% /sys/firmware
root@8f0d58b68a2a:/# dd if=/dev/zero of=file bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.0955371 s, 1.1 GB/s ##因为这样使用了文件缓存

root@8f0d58b68a2a:/# dd if=/dev/zero of=file bs=1M count=100 oflag=direct ##不使用文件缓存
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 9.95141 s, 10.5 MB/s

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