【Docker】Docker的安全优化简介
Docker容器的安全性,很大程度上依赖于Linux系统自身
评估Docker的安全性时,主要考虑以下几个方面:
-
Linux内核的命名空间机制提供的容器隔离安全
-
Linux控制组机制对容器资源的控制能力安全。
-
Linux内核的能力机制所带来的操作权限安全
-
Docker程序(特别是服务端)本身的抗攻击性。
-
其他安全增强机制对容器安全性的影响
cgroup和cgroup2是什么,有什么区别
cgroup(Control Groups)是 Linux 内核的「资源调度器」,v1 是分散式老版本,v2 是统一式新版本——它把 CPU/内存/IO 等资源像水电表一样装进进程的「计量箱」,让系统管理员能精准限流、防止单个进程吃垮整台服务器。没有 cgroup,容器技术(如 Docker)根本无法实现资源隔离。
| 对比维度 | cgroup v1 | cgroup v2 | 为什么 v2 是未来 |
|---|---|---|---|
| 架构设计 | 分散式:CPU/内存/IO 各自为政,需挂载多个独立层级(如 /sys/fs/cgroup/cpu 和 /sys/fs/cgroup/memory) | 统一式:所有资源管理仅需一个层级(/sys/fs/cgroup) | 避免冲突:v1 中 CPU 和内存限制可能互相干扰,v2 从设计根治此问题 |
| 资源控制精度 | CPU 带宽单位为 us(微秒),易因浮点精度丢失控制粒度 | 纳秒级精度 + 层级权重继承(子组自动继承父组比例) | 精细调度:数据库容器可稳定获得 70% CPU,绝不被日志进程挤占 |
| 关键特性支持 | 无统一内存核算(网络内存/内核内存分离统计) 无 PSI(压力阻塞信息) | 统一内存核算(含缓存/网络/内核内存) PSI 实时监控:精准识别“CPU 等待 IO 导致卡顿” | 深度诊断:Kubernetes 的 MemoryQoS 特性必须依赖 v2 |
| 配置复杂度 | 需为每个子系统单独写文件(如 cpu.shares + memory.limit_in_bytes) | 单一接口文件:cpu.weight 控制权重,memory.max 控制上限 | 运维友好:配置量减少 50%+,错误率骤降 |
#在rhel9中默认使用cgroup-v2 但是cgroup-v2中不利于观察docker的资源限制情况,所以推荐使用cgroup-v1
#切换到cgroup-v1
[root@docker ~]# grubby --update-kernel=/boot/vmlinuz-$(uname -r) \
--args="systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller"
# 更改系统cgroup版本
[root@docker-node1 ~]# mount -t cgroup
[root@docker-node1 ~]# mount -t cgroup2
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
[root@docker-node1 ~]# grubby --update-kernel=/boot/vmlinuz-$(uname -r) \
--args="systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller"
[root@docker-node1 ~]# reboot
[root@docker-node1 ~]# 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_cls,net_prio)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/misc type cgroup (rw,nosuid,nodev,noexec,relatime,misc)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
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)
1 命名空间隔离的安全
-
当docker run启动一个容器时,Docker将在后台为容器创建一个独立的命名空间。命名空间提供了最基础也最直接的隔离。
-
与虚拟机方式相比,通过Linux namespace来实现的隔离不是那么彻底。
-
容器只是运行在宿主机上的一种特殊的进程,那么多个容器之间使用的就还是同一个宿主机的操作系统内核。
-
在 Linux 内核中,有很多资源和对象是不能被 Namespace 化的,比如:磁盘等等
[root@docker ~]# docker run -d --name web nginx
3c6b649a200fc56afafe9f47494903fe56e71cabcd534d6c9e6f8b5854f29cac
[root@docker ~]# docker inspect web | grep Pid
"Pid": 4328,
"PidMode": "",
"PidsLimit": null,
[root@docker ~]# cd /proc/4328/ns/ #进程的namespace
[root@docker ns]# ls
cgroup ipc mnt net pid pid_for_children time time_for_children user uts
[root@docker ns]# ls -d /sys/fs/cgroup/memory/docker/3c6b649a200fs省略部分854f29cac/ #资源隔离信息
/sys/fs/cgroup/system.slice/docker-ecb8abbbfc85bf3d62fc82afb3950ab6b6a2e80092738274a233bbb8db0c5ce2.scope
/sys/fs/cgroup/system.slice/docker.service
/sys/fs/cgroup/system.slice/docker.socket
2 控制组资源控制的安全
-
当docker run启动一个容器时,Docker将在后台为容器创建一个独立的控制组策略集合。
-
Linux Cgroups提供了很多有用的特性,确保各容器可以公平地分享主机的内存、CPU、磁盘IO等资源。
-
确保当发生在容器内的资源压力不会影响到本地主机系统和其他容器,它在防止拒绝服务攻击(DDoS)方面必不可少
[root@docker ~]# docker run -it --name test busybox #内存资源默认没有被隔离
/ # free -m
total used free shared buff/cache available
Mem: 3627 648 516 16 2463 2678
Swap: 2063 1 2062
/ # exit
[root@docker ~]# free -m
total used free shared buff/cache available
Mem: 3627 907 557 15 2463 2719
Swap: 2062 1 2061
3 内核能力机制
-
能力机制(Capability)是Linux内核一个强大的特性,可以提供细粒度的权限访问控制。
-
大部分情况下,容器并不需要“真正的”root权限,容器只需要少数的能力即可。
-
默认情况下,Docker采用“白名单”机制,禁用“必需功能”之外的其他权限。
4 Docker服务端防护
-
使用Docker容器的核心是Docker服务端,确保只有可信的用户才能访问到Docker服务。
-
将容器的root用户映射到本地主机上的非root用户,减轻容器和主机之间因权限提升而引起的安全问题。
-
允许Docker 服务端在非root权限下运行,利用安全可靠的子进程来代理执行需要特权权限的操作。这些子进程只允许在特定范围内进行操作。
[root@docker ~]# ls -ld /var/lib/docker/ #默认docker是用root用户控制资源的
drwx--x--- 12 root root 171 8月 20 13:21 /var/lib/docker/
更多推荐

所有评论(0)