云安全和容器安全已经成为安全从业者绕不开的新战场。如果你已经掌握了Web渗透的基础想拓宽技能边界、增加就业竞争力那么Docker与Kubernetes的漏洞环境搭建就是一条高效的切入点。相比传统渗透测试里找SQL注入、XSS这些“代码级”漏洞云安全更关注配置错误、权限滥用和供应链污染——攻击面从单点应用扩展到了整个基础设施层。下面我会从Docker环境准备、容器逃逸漏洞复现到Kubernetes基础概念和镜像安全扫描带你走完一套可落地的实验流程。最后还会给出一个完整的动手实验搭建一个存在错误配置的Docker环境用Trivy扫出漏洞并理解修复逻辑。在这里插入图片描述Docker环境准备与基础操作先确保你的实验环境干净可控。推荐在虚拟机里装一套Linux比如Ubuntu 22.04 LTS然后安装Docker CE。# 更新源并安装依赖sudoaptupdatesudoaptinstall-yca-certificatescurlgnupg# 添加Docker官方GPG密钥和仓库sudoinstall-m0755-d/etc/apt/keyringscurl-fsSLhttps://download.docker.com/linux/ubuntu/gpg|sudogpg--dearmor-o/etc/apt/keyrings/docker.gpgechodeb [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# 安装Dockersudoaptupdatesudoaptinstall-ydocker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin# 验证安装sudodockerrun hello-world装完后把当前用户加到docker组避免每次都用sudosudousermod-aGdocker$USERnewgrpdocker几个核心概念快速过一下**镜像Image**是只读模板**容器Container**是镜像的运行实例**仓库Registry**用来存储和分发镜像。日常操作离不开这几条dockerpull ubuntu:22.04# 从仓库拉取镜像dockerimages# 查看本地镜像dockerrun-itubuntu:22.04bash# 交互式启动容器dockerps-a# 查看所有容器含停止的dockerexec-it容器IDbash# 进入运行中的容器容器逃逸从隔离突破到宿主机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-addNET_ADMIN --cap-addSYS_TIME...Kubernetes基础从单机到集群Docker解决的是单机容器化KubernetesK8s解决的是容器编排。理解K8s的核心概念对云安全至关重要因为配置错误往往发生在集群层面。核心组件速览Pod最小调度单元一个Pod可包含多个容器Deployment声明式管理Pod的副本数量、更新策略Service为Pod提供稳定的网络访问入口Namespace资源隔离的虚拟集群RBACRole-Based Access Control基于角色的权限控制配置错误是常见攻击面快速体验可以用minikube在本地搭单节点集群# 安装minikubecurl-LOhttps://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64sudoinstallminikube-linux-amd64 /usr/local/bin/minikube# 启动集群minikube start--driverdocker# 验证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把加固后的配置自动化就是一份能写在简历上的实战经历了。