Docker安全（cgroups对容器资源的控制）

最新推荐文章于 2024-04-24 22:22:02 发布
最新推荐文章于 2024-04-24 22:22:02 发布
阅读量342 收藏
点赞数
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/yyh_linux_note/article/details/98875671
版权

文章目录

一， 理解Docker容器的安全性

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

Linux内核的命名空间机制提供的容器隔离安全。

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

Linux控制组机制对容器资源的控制能力安全。

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

Linux内核的能力机制所带来的操作权限安全。

能力机制（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 时的参数指定。

cgroups的能力体现

限制进程组可以使用的资源数量（Resource limiting ）。

比如：memory子系统可以为进程组设定一个memory使用上限，一旦进程组使用的内存达到限额再申请内存，就会出发OOM（out of
memory）。

进程组的优先级控制（Prioritization ）。

比如：可以使用cpu子系统为某个进程组分配特定cpu share。

记录进程组使用的资源数量（Accounting ）。

比如：可以使用cpuacct子系统记录某个进程组使用的cpu时间

进程组隔离（Isolation）。

比如：使用ns子系统可以使不同的进程组使用不同的namespace，以达到隔离的目的，不同的进程组有各自的进程、网络、文件系统挂载空间。

进程组控制（Control）。

比如：使用freezer子系统可以将进程组挂起和恢复

对内存的限制

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

[root@server1 ~]# yum install libcgroup-tools.x86_64 -y
[root@server1 ~]# mount -t cgroup
[root@server1 ~]# cd /sys/fs/cgroup/memory/
[root@server1 memory]# cat memory.limit_in_bytes 
9223372036854771712		数字太大，等同于没有做限制
[root@server1 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!"，也不能保存退出。）

**注意一下： memory.limit_in_bytes 这是给内存分大小的
memory.memsw.limit_in_bytes 这是给内存+交换分区分大小的
假如两个文件都给200M，意思就是内存为200M，而交换分区大小为0，就是不开启
内存+交换分区之间的那个门，假如不开启，当给指定文件大小大于内存的话，就会killed
开启的话呢，即使内存不够了，交换分区会分担内存无法存放的那部分大小

现在给内存300M，swap分区0M
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
测试一下：

[root@server1 ~]# cd /dev/shm/
[root@server1 shm]# cgexec -g memory:snow dd if=/dev/zero of=bigfile bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.030733 s, 3.4 GB/s
[root@server1 shm]# 
[root@server1 shm]# free -m
              total        used        free      shared  buff/cache   available
Mem:           1839         125        1299         116         414        1443
Swap:           819           0         819		
##我们发现可用内存少了100M
[root@server1 shm]# cgexec -g memory:snow dd if=/dev/zero of=bigfile bs=1M count=300
Killed
###因为指定的文件的大小为300M超过了限制,所以显示Killed,这就是之前我们为snow目录设置的限制，其最多只能占用200M
[root@server1 shm]# 
[root@server1 shm]# free -m
              total        used        free      shared  buff/cache   available
Mem:           1839         127        1197         215         514        1341
Swap:           819           0         819

在这里插入图片描述

在这里插入图片描述

如果不对内存和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@server1 ~]# docker run -it --name vm1 --memory 209715200 --memory-swap 209715200 ubuntu
root@b1d8a47cd003:/# [root@server1 ~]#
##利用ubuntu镜像运行容器vm1,指定内存+交换分区<200M。并使用Ctrl+p+q退出,即不要让容器停掉

在这里插入图片描述
值的注意的是：

因为容器的隔离性并不是很好，所以在容器内使用命令"free -m"看到的内容与宿主机上使用命令"free -m"看到的内容相同，所以如果要看是否限制成功，需要进入容器对应的目录中进行查看

在这里插入图片描述

在这里插入图片描述

对cpu限额

（1）打开docker并检测cgroup是否开启

[root@server1 ~]# systemctl start docker
[root@server1 ~]# 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/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_prio,net_cls)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
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/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)

（2）建立一个CPU控制组群

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

在这里插入图片描述

（3）测试限制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@server1 x1]# cat cpu.cfs_period_us 
100000
[root@server1 x1]# cat cpu.cfs_quota_us 					##默认为-1，表示不限制
-1
[root@server1 x1]# echo 20000 > cpu.cfs_quota_us			##修改占用时间为20%
[root@server1 x1]# cat cpu.cfs_quota_us
20000

在这里插入图片描述

（4）测试

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

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述
（5）创建容器限制使用cpu

[root@server1 x1]# echo 2123 > tasks 			##dd命令的进程号
[root@server1 x1]# fg
dd if=/dev/zero of=/dev/null
^C456424541+0 records in
456424541+0 records out
233689364992 bytes (234 GB) copied, 201.225 s, 1.2 GB/s
[root@server1 ~]# docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
[root@server1 x1]# docker run -it --name vm1 --cpu-quota=20000 ubuntu
root@9431d483af1e:/# dd if=/dev/zero of=/dev/null

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

假如在创建容器时不做限制，那么占用率会达到100%

[root@server1 ~]# docker run -it --name vm1 ubuntu
root@cc62dd927ede:/# dd if=/dev/zero of=/dev/null

在这里插入图片描述

在这里插入图片描述

对 Block IO写入速度的限制

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

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

[root@server1 ~]# docker run -it --rm --privileged=true ubuntu	##--rm参数指容器退出后，自动删除容器
root@d3bc318587e7:/# fdisk -l
Disk /dev/sda: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 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: 0x000a8154
Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048     2099199     1048576   83  Linux
/dev/sda2         2099200    16777215     7339008   8e  Linux LVM
root@d3bc318587e7:/#

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

![\[root@server1 ~\]# docker run -it --rm --device-write-bps /dev/sda:30M ubuntu		##写入速度为每秒30M
root@d3f749bb200d:/# 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, 9.91935 s, 31.7 MB/s			##用时约10秒
root@d3f749bb200d:/# dd if=/dev/zero of=file bs=1M count=300             
300+0 records in
300+0 records out
314572800 bytes (315 MB) copied, 0.130683 s, 2.4 GB/s		##用时不到一秒
root@d3f749bb200d:/#](https://img-blog.csdnimg.cn/20190808233240951.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3l5aF9saW51eF9ub3Rl,size_16,color_FFFFFF,t_70)

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

小杨118709
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
企业版Docker<17>——Docker安全性支持（使用Cgroups机制实现对容器的资源控制）
AmourHaiti的博客
10-12 273
以下所有的操作都是在redhat 7.5上操作 Docker作为最重视安全的容器技术之一，在很多方面都提供了强安全性的默认配置，其中包括：容器root用户的Capability能力限制、Seccomp系统调用过滤、Apparmor的 MAC 访问控制、ulimit限制、pid-limits的支持，镜像签名机制等。这篇文章我们就带大家详细了解一下。Docker利用Namespace实现了6项隔离，...
Docker---资源控制之cgroups
qq_42761527的博客
04-07 336
一.cgroup的介绍 二.stress工具测试容器cpu和内存 三.cpu周期限制 四.cpu core控制 五.cpu配额控制参数混合使用 六.内存限制 七.Block IO的限制 八.bps和iops的限制 ...
《自己动手写Docker》书摘之二： Linux Cgroups
weixin_34149796的博客
11-27 236
Linux Cgroups介绍 上面是构建Linux容器的namespace技术，它帮进程隔离出自己单独的空间，但Docker又是怎么限制每个空间的大小，保证他们不会互相争抢呢？那么就要用到Linux的Cgroups技术。 概念 Linux Cgroups(Control Groups) 提供了对一组进程及将来的子进程的资源的限制，控制和统计的能力，这些...
Docker Cgroups资源控制
m0_71931851的博客
12-01 865
Docker Cgroups资源控制
Docker cgroups资源控制
weixin_45305723的博客
07-09 491
cgroups，是一个非常强大的linux内核工具，他不仅可以限制被namespace隔离起来的资源，还可以为资源设置权、计算使用量、操控进程启停等等。所以cgroups（Control groups）实现了对资源的配额和度量。 另一个终端查看CPU使用率停止运行脚本再查看cpu使用率..................
Docker网络原理及Cgroup硬件资源占用控制
最新发布
qq_57093716的博客
04-24 909
Docker网络原理及Cgroup硬件资源占用控制
详解Docker 容器使用 cgroups 限制资源使用
09-30
Docker容器技术极大地简化了应用的打包、分发和部署过程，而cgroups（control groups）是Linux内核的一个特性，用于限制、记录和隔离进程组所使用的物理资源（如CPU、内存、磁盘I/O等）。本文将深入探讨Docker容器是...
docker容器资源配额控制详解
09-30
总结来说，Docker通过cgroups实现了对容器资源的灵活控制，使得用户可以根据实际需要合理分配CPU、内存等资源给容器，以确保应用的高效运行和资源的合理使用。通过深入学习和实践这些知识点，可以更好地掌握Docker...
浅谈Docker安全机制内核安全与容器之间的网络安全 原创
01-11
内核为容器提供两种技术 cgorups和namespaces，分别对容器进行资源限制和资源隔离，使容器感觉像是在用一台独立主机环境。 ·cgroups资源限制 容器本质上是进程，cgroups的存在就是为了限制宿主机上不同容器的资源的...
docker入门之容器介绍
01-10
docker采用的是LXC(Namespace+CGroups)，即在Linux内核的Namespace[资源隔离]和CGroups[资源控制]技术的基础上通过镜像管理机制来实现轻量化设计。 docker组成 docker的组成包括docker server和dockerclient，其中...
容器基础(三): 使用Cgroups进行资源限制
dnet30833的博客
12-04 361
Linux Cgroups Linux Cgroups 是 Linux 内核中用来为进程设置资源限制的一个重要功能. Cgroups将进程进行分组, 然后对这一组进程进行统一的资源监控和限制。Cgroups当前有V1和V2版本，为了后续用于实现简单容器sdocker，这里只验证V1版本的cpu和memory子系统。 Linux可以通过如下命令来查看当前系统支持的cgroup子系统：...
docker(14)——安全性支持（使用Cgroups机制实现对容器的资源控制）
qq_42024433的博客
06-03 258
对Docker安全的理解 Docker作为最重视安全的容器技术之一，在很多方面都提供了强安全性的默认配置 其中包括：容器root用户的Capability能力限制、Seccomp系统调用过滤、Apparmor的 MAC访问控制、ulimit限制、pid-limits的支持镜像签名机制等。这篇文章我们就带大家详细了解一下 Docker利用Namespace实现了6项隔离，看似完整，实际上依旧没有完全隔离Linux资源，比如/proc 、/sys 、/dev/sd*等目录未完全隔离，SELinux、time、s
CPU资源控制
sea_bunch的博客
04-24 1621
cgroups（control groups）是一个非常强大的linux内核工具，他不仅可以限制被namespace隔离起来的资源， 还可以为等等。。
容器基础——Cgroups
weixin_42574365的博客
10-30 236
Cgroups 制造约束 Linux Cgroups 的全称是 Linux Control Group。它最主要的作用，就是限制一个进程组能够使用的资源上限，包括 CPU、内存、磁盘、网络带宽等等。 Cgroups 给用户暴露出来的操作接口是文件系统，即它以文件和目录的方式组织 在操作系统的 /sys/fs/cgroup 路径下。在系统中执行mount -t cgroup 可以看到如下结果： 可以看到，在 /sys/fs/cgroup 下面有很多诸如 cpuset、cpu、 memory 这样的子目录，也
Docker容器基础(cGroups、namespace)（一）
fengy_jav的博客
01-10 471
标题Docker容器技术基础 进程 隔离与限制 容器技术的兴起起源于PaaS技术的普及，Docker项目对此具有里程碑式的意义，Docker项目通过容器镜像解决应用打包这个根本性难题。 接下来通过Linux操作系统层面的知识简要介绍一下Docker的实现 进程 容器其实就是一个沙盒技术，顾名思义，沙盒就像是集装箱，可以将我们的应用装起来的技术。这样，应用与应用之间，就因为有了边界而可以相互之间不干扰，这样被装进集装箱的应用就可以被随意的搬来搬去，而不受外界所影响。 说起来容易，但是实现起来可能就无从下手
解决echo 0 ＞ /proc/sys/vm/drop_caches报错
Hassang的博客
04-10 4001
找了半天都没搜到解决方法，只说重启之后就会恢复成默认值0，可是生产环境的服务器哪是说重启就能重启的呢？突然想起之前有一台服务器恢复默认值的操作时成功了的，万幸terminal还没关掉，翻了下历史命令，发现其实这个报错的原因和解决方法简直不要太简单——去掉0和>之间之间的空格就好了！配置文件：/proc/sys/vm/drop_caches 该文件记录了缓存释放的参数，默认值为0，也就是不释放缓存。cat发现值已经变成0了！清理缓存时，我们会使用。附：linux缓存释放。
Linux下清除缓存 drop_caches，sysctl（备忘）
SDKLHKJAS的博客
03-19 1831
1. 用命令 free -m 查看一下内存的使用情况： 然后清除缓存后再来查看一下内存的使用情况： 前后对比可发现，缓存由之前的110M缩小到了25M，效果比较明显。 2. 下面说一下 drop_caches： 清空 pagecache： sync echo 1 > /proc/sys/vm/drop_caches 或者： sync sysctl -w vm.drop_caches=1...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值