云安全和容器安全入门，Docker与K8s漏洞环境怎么搭
云安全和容器安全已经成为安全从业者绕不开的新战场。如果你已经掌握了Web渗透的基础，想拓宽技能边界、增加就业竞争力，那么Docker与Kubernetes的漏洞环境搭建就是一条高效的切入点。相比传统渗透测试里找SQL注入、XSS这些“代码级”漏洞，云安全更关注配置错误、权限滥用和供应链污染——攻击面从单点应用扩展到了整个基础设施层。
下面我会从Docker环境准备、容器逃逸漏洞复现，到Kubernetes基础概念和镜像安全扫描，带你走完一套可落地的实验流程。最后还会给出一个完整的动手实验：搭建一个存在错误配置的Docker环境，用Trivy扫出漏洞并理解修复逻辑。
在这里插入图片描述
Docker环境准备与基础操作
先确保你的实验环境干净可控。推荐在虚拟机里装一套Linux，比如Ubuntu 22.04 LTS，然后安装Docker CE。
# 更新源并安装依赖sudoaptupdate&&sudoaptinstall-yca-certificatescurlgnupg# 添加Docker官方GPG密钥和仓库sudoinstall-m0755-d/etc/apt/keyringscurl-fsSLhttps://download.docker.com/linux/ubuntu/gpg|sudogpg--dearmor-o/etc/apt/keyrings/docker.gpgecho"deb [arch=$(dpkg --print-architecture)signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu$(lsb_release-cs)stable"|sudotee/etc/apt/sources.list.d/docker.list>/dev/null# 安装Dockersudoaptupdate&&sudoaptinstall-ydocker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin# 验证安装sudodockerrun hello-world装完后把当前用户加到docker组，避免每次都用sudo：
sudousermod-aGdocker$USERnewgrpdocker几个核心概念快速过一下：**镜像（Image）**是只读模板，**容器（Container）**是镜像的运行实例，**仓库（Registry）**用来存储和分发镜像。日常操作离不开这几条：
dockerpull ubuntu:22.04# 从仓库拉取镜像dockerimages# 查看本地镜像dockerrun-itubuntu:22.04bash# 交互式启动容器dockerps-a# 查看所有容器（含停止的）dockerexec-it<容器ID>bash# 进入运行中的容器容器逃逸：从隔离突破到宿主机
Docker的隔离依赖Linux内核的namespace和cgroups，但配置不当或内核漏洞都可能导致“容器逃逸”——攻击者从容器内部拿到宿主机的root权限。这是云安全里最高危的场景之一，也是和传统渗透测试差异最大的地方：你攻击的不再是应用层，而是底层基础设施。
常见逃逸场景分类
| 场景 | 原理 | 典型利用条件 |
|---|---|---|
| 特权模式逃逸 | 容器以--privileged启动，拥有几乎所有宿主机设备访问权限 | 管理员图方便开启特权模式 |
| 危险挂载逃逸 | 将宿主机敏感目录（如//、/var/run/docker.sock）挂载进容器 | 配置时未限制挂载范围 |
| 内核漏洞逃逸 | 利用Linux内核CVE（如Dirty COW） | 宿主机内核未打补丁 |
| 容器运行时漏洞 | runc等容器运行时本身的漏洞 | 运行时版本过旧 |
动手复现：特权模式逃逸
这是最容易搭建也最具教学意义的场景。启动一个特权容器：
dockerrun--rm-it--privilegedubuntu:22.04bash进入容器后，查看当前挂载的设备：
ls/dev# 能看到大量宿主机设备fdisk-l# 直接看到宿主机磁盘分区利用特权模式挂载宿主机的根文件系统：
mkdir/hostmount/dev/sda1 /host# 根据fdisk -l结果调整设备名chroot/host此时你已经以root身份进入了宿主机的文件系统，可以任意读写。修复方案很简单：永远不要在生产环境使用--privileged，如果确实需要某些能力，用--cap-add精确授权：
# 错误做法dockerrun--privileged...# 正确做法：只给需要的权限dockerrun --cap-add=NET_ADMIN --cap-add=SYS_TIME...Kubernetes基础：从单机到集群
Docker解决的是单机容器化，Kubernetes（K8s）解决的是容器编排。理解K8s的核心概念对云安全至关重要，因为配置错误往往发生在集群层面。
核心组件速览
- Pod：最小调度单元，一个Pod可包含多个容器
- Deployment：声明式管理Pod的副本数量、更新策略
- Service：为Pod提供稳定的网络访问入口
- Namespace：资源隔离的虚拟集群
- RBAC（Role-Based Access Control）：基于角色的权限控制，配置错误是常见攻击面
快速体验可以用minikube在本地搭单节点集群：
# 安装minikubecurl-LOhttps://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64sudoinstallminikube-linux-amd64 /usr/local/bin/minikube# 启动集群minikube start--driver=docker# 验证kubectl get nodes kubectl get pods-AK8s安全的关键在于RBAC最小权限原则。一个经典错误是给Service Account绑定cluster-admin角色，导致任意Pod都能获取集群全部权限。审计时重点检查：
# 查看高风险绑定kubectl get clusterrolebindings-owide|grepcluster-admin# 查看Secret（常包含凭证）kubectl get secrets-A镜像安全扫描：用Trivy发现供应链风险
容器镜像层层叠加，基础镜像里的漏洞、应用依赖的过时包，都会成为攻击入口。Trivy是Aqua Security开源的轻量级扫描器，支持镜像、文件系统、Git仓库等多种扫描目标。
安装Trivy
# 用官方脚本安装curl-sfLhttps://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh|sudosh-s---b/usr/local/bin trivy version扫描存在漏洞的镜像
先故意拉取一个老旧镜像：
dockerpull vulhub/tomcat:8.5.43# 已知存在多个CVE执行扫描：
trivy image vulhub/tomcat:8.5.43输出会按严重程度（CRITICAL/HIGH/MEDIUM/LOW）列出漏洞，包含CVE编号、当前版本、修复版本。重点关注CRITICAL和HIGH级别的RCE（远程代码执行）漏洞。
扫描本地Dockerfile和文件系统
Trivy也能在构建前扫描依赖，把风险左移：
# 扫描Dockerfile引用的基础镜像trivy image--inputDockerfile# 扫描本地项目依赖（支持npm/pip/maven等）trivy fs--scannersvuln ./my-project综合实验：搭建错误配置环境并修复
下面把前面内容串起来，完成一个完整的实验闭环。
步骤1：编写存在问题的Dockerfile
# 故意使用有漏洞的基础镜像 FROM tomcat:8.5.43-jdk8 # 以root运行（另一个错误配置） USER root # 复制存在已知漏洞的旧版组件 COPY old-log4j-1.2.17.jar /usr/local/tomcat/lib/ EXPOSE 8080 CMD ["catalina.sh", "run"]步骤2：构建并扫描
dockerbuild-tvulnerable-app:1.0.trivy image vulnerable-app:1.0你会看到大量CVE，包括Log4j相关的远程代码执行漏洞。
步骤3：分析并修复
根据Trivy报告，逐条修复：
# 使用官方修复后的镜像 FROM tomcat:9.0.82-jdk17-temurin # 切换到非root用户 RUN addgroup --system tomcat && adduser --system --group tomcat USER tomcat # 移除有漏洞的组件，改用最新版 COPY log4j-2.20.0.jar /usr/local/tomcat/lib/ EXPOSE 8080 CMD ["catalina.sh", "run"]重新构建扫描，确认高危漏洞清零。
步骤4：运行时加固
启动时避免特权模式，限制资源和能力：
dockerrun-d\--read-only\--tmpfs/tmp\--cap-drop ALL\--cap-add CHOWN\--security-opt no-new-privileges:true\-p8080:8080\vulnerable-app:2.0| 参数 | 作用 |
|---|---|
--read-only | 根文件系统只读，防止运行时篡改 |
--tmpfs /tmp | 临时目录挂载为内存文件系统 |
--cap-drop ALL | 丢弃所有Linux capabilities |
--cap-add CHOWN | 只添加必要的权限 |
--security-opt no-new-privileges:true | 禁止提升权限 |
云安全与传统渗透测试的思维差异
做完上面的实验，你应该能体会到云安全的几个特点：
攻击面从“代码”转向“配置”。传统Web渗透找的是注入点、逻辑缺陷，云安全里更常见的是存储桶公开、安全组0.0.0.0/0、IAM过度授权这些配置问题。工具用Trivy、 Scout、Checkov这类扫描器，比Burp Suite更多。
影响范围从“单点”到“全局”。一个容器的逃逸可能导致整个集群沦陷，一个IAM角色的错误绑定可能让攻击者横向移动所有云资源。防御上要强调零信任和最小权限。
供应链成为新战场。基础镜像、第三方依赖、Helm Chart都可能引入漏洞。安全左移意味着在CI/CD阶段就介入扫描，而不是等上线后再补救。
如果你已经熟悉Web渗透，建议把云安全作为第二曲线来培养。从Docker和K8s的漏洞环境入手，理解容器隔离的边界和突破方式，再扩展到云平台本身的配置审计，这条路径在招聘市场上越来越吃香。动手把上面的实验跑通，再尝试用Terraform或Ansible把加固后的配置自动化，就是一份能写在简历上的实战经历了。