云安全实战

第一章 Docker 安全

1.1 Docker 核心概念与架构

Docker 是目前最主流的容器化平台。容器化不是虚拟机——它利用 Linux 内核的 Namespace 和 Cgroups 特性实现了轻量级的进程隔离。

核心概念：

镜像（Image）：只读模板，包含了运行应用的全部内容——代码、运行时、库、环境变量。镜像分层构建，每一层代表一个 Dockerfile 指令。镜像是不可变的——一旦构建完成就不能修改。

容器（Container）：镜像的运行实例。在镜像的只读层之上添加了一个可读写层。容器之间互相隔离，共享宿主机内核。

仓库（Registry）：镜像的存储和分发中心。Docker Hub 是默认公共仓库。企业通常搭建私有 Registry（如 Harbor）。

架构分层：

┌──────────────────────────────┐
│  docker CLI（用户输入命令）    │
├──────────────────────────────┤
│  dockerd（Docker 守护进程）    │ ← 以 root 运行，监听 /var/run/docker.sock
├──────────────────────────────┤
│  containerd（容器运行时管理）   │
├──────────────────────────────┤
│  runc（OCI 容器运行时）        │ ← 实际创建容器进程
└──────────────────────────────┘

dockerd 以 root 权限运行。任何能访问 Docker Socket（/var/run/docker.sock）的用户或进程，都等同于拥有宿主机的 root 权限——这是 Docker 安全的核心风险点。

1.2 Docker 安全隔离机制

Docker 不是"安全的虚拟机"——它是一组 Linux 内核特性的组合包装。

**Namespace（命名空间）——实现"看到的隔离"**：

Namespace	隔离内容	安全意义
PID	进程树	容器内只能看到自己的进程
Network	网络栈	容器有自己独立的网卡、IP、路由表
Mount	挂载点	容器有自己的文件系统树
UTS	主机名和域名	容器可以有自己的 hostname
IPC	进程间通信	容器间的共享内存、信号量隔离
User	用户和组 ID	容器内 root 映射为宿主机普通用户（默认未启用）
Cgroup	控制组视图	容器看到自己的资源限制

**Cgroups（控制组）——实现"资源的限制"**：

限制容器可使用的 CPU 核心数、内存大小、磁盘 I/O 速率。防止一个容器耗尽宿主机全部资源。

Capabilities（能力）——拆分的 root 权力：

传统 Linux 中，root 拥有全部权力。Capabilities 将 root 的权力拆分为细粒度的能力单元。Docker 默认启动容器时，会去掉以下危险能力：

CAP_SYS_ADMIN（系统管理操作——包括 mount）
CAP_NET_RAW（原始套接字——包括网络嗅探）
CAP_SYS_PTRACE（进程追踪——包括 ptrace 调试其他进程）
CAP_SYS_MODULE（加载/卸载内核模块）
等共 14 项

Seccomp（安全计算模式）——系统调用过滤：

限制容器内进程可以调用的 Linux 系统调用。Docker 默认的 Seccomp 策略禁用了约 44 个危险调用（如 reboot、kexec_load、clock_settime）。

1.3 容器逃逸

容器逃逸是指从容器内部突破多重隔离机制，获取宿主机访问权限。本质是用户给了容器太多的权限，导致隔离被打破。

路径一：特权容器（--privileged）

BASH

# 启动特权容器
docker run -d --privileged --name test nginx:1.25

--privileged 参数赋予容器的不是"多了几项 Capability"，而是允许容器做任何宿主机能做的事。这包括：加载内核模块、访问所有设备（/dev/）、修改内核参数等。

在特权容器内：

BASH

# 1. 查看宿主机磁盘设备
fdisk -l/df -h
# 输出：
# /dev/sda1  → 宿主机的系统盘
# 2. 挂载宿主机根分区
mkdir /tmp/host
mount /dev/sda1 /tmp/host
# 3. 切换到宿主机环境
chroot /tmp/host
# 4. 此时已在宿主机上，可以：
# - 读取 /etc/shadow（密码哈希）
# - 安装 SSH 后门
# - 修改任何文件

快速检测脚本：

BASH

docker ps --quiet | xargs docker inspect --format ''{{.Name}}: Privileged={{.HostConfig.Privileged}}''
# 示例输出：/test: Privileged=true  ← 危险

路径二：挂载 Docker Socket

BASH

docker run -d -v /var/run/docker.sock:/var/run/docker.sock --name test nginx:1.25

Docker Socket（/var/run/docker.sock）是 dockerd 的 API 入口。任何能访问这个 Socket 的进程都可以完全控制 Docker——创建容器、删除容器、拉取镜像、执行命令。把它挂载进容器 = 把宿主机 Docker 的控制权给了容器。

这是目前 Kubernetes 集群中最常见、最容易被利用的逃逸路径。

1. 为什么这个 Socket 这么厉害？
/var/run/docker.sock 是 Docker 守护进程（dockerd）的 UNIX 套接字。dockerd 始终以 root 用户运行。访问这个 Socket，就等于拥有了宿主机的 Root 级 API 权限。

在容器内利用：

BASH

# 在容器内安装 Docker CLI
apt update && apt install -y docker.io

# 通过挂载的 Socket 在宿主机上创建新容器
docker -H unix:///var/run/docker.sock run -it --privileged -v /:/host ubuntu chroot /host
# 这行命令的含义：
# -H unix:///var/run/docker.sock → 连接宿主机的 Docker 守护进程
# --privileged → 新容器拥有全部权限
# -v /:/host → 将宿主机根目录挂载到新容器的 /host
# chroot /host → 切换到宿主机根文件系统→ 获得宿主机完全控制

4. 防御措施
如果业务必须挂载该 Socket（例如 CI/CD 容器），请采用以下方案降低风险：

禁用 root 用户：在容器内使用 USER 1000 运行进程（虽然 Socket 被挂载，但非 root 用户的权限受限，无法执行破坏性 API）。
**使用 --group-add**：将容器用户加入宿主机 docker 组（但依旧危险，仅限低环境）。
终极方案：使用 Rootless Docker 或 Podman，移除守护进程的 root 权限。

路径三：CAP_SYS_ADMIN + cgroup

如果容器有 CAP_SYS_ADMIN 能力且 cgroup 可写，可以通过 cgroup 的 notify_on_release 机制在宿主机上执行任意命令。此路径涉及较复杂的内核机制，但在条件满足时极其危险。

1.4 镜像安全

CVE 漏洞扫描：

Docker 镜像基于 Linux 发行版（如 Debian、Alpine），其中包含数百个系统包。过期镜像可能包含已知的严重漏洞。

真实案例——依赖混淆攻击：2023 年，攻击者上传了名为 python-dateutil 的恶意包到 PyPI（和流行的 python-dateutil 只差一个连字符）。开发者误写 pip install python-dateutil，导致恶意代码被打包进镜像并部署到生产环境。

BASH

# 下载 Trivy
# https://github.com/aquasecurity/trivy/releases（下载 Windows 版）

# 扫描本地镜像
trivy image nginx:latest
# 输出：列出所有已知 CVE，按严重程度分类

# 对比：扫描一个多年未更新的镜像
docker pull node:14
trivy image node:14
# 输出：数百个漏洞，包括大量 HIGH 和 CRITICAL 级别

Dockerfile 安全原则：

原则	危险写法	安全写法	原因
版本锁定	`FROM ubuntu:latest`	`FROM ubuntu:22.04`	`latest` 标签可能引入未测试的变更
非 root 运行	默认以 root 运行	`USER appuser`	容器内 root 在特定条件下可威胁宿主机
清理缓存	不清理	`rm -rf /var/lib/apt/lists/*`	减小攻击面，减少镜像体积
秘密管理	`ENV SECRET=xxx`	运行时注入（`--env-file` 或 K8s Secret）	镜像层中写入的秘密可被提取
最小安装	`apt install -y nginx vim curl ...`	`apt install -y --no-install-recommends nginx`	不必要的包 = 不必要的漏洞

1.5 Registry 未授权访问

Docker Registry 是存储和分发 Docker 镜像的仓库服务。如果配置不当（未启用身份认证），攻击者可以：

匿名访问 Registry API（无需任何凭证）
列出所有镜像仓库（泄露业务信息）
拉取或覆盖镜像（可能植入后门）

这个漏洞属于高危配置缺陷（CWE-284: Improper Access Control）。

BASH

# 测试匿名访问
curl https://<registry>/v2/_catalog
# 返回 {"repositories":["app1","app2",...]} → 未授权访问

# 列出所有镜像标签
curl https://<registry>/v2/<image>/tags/list

# 拉取镜像
docker pull <registry>/<image>:<tag>

第二章 Kubernetes 安全

2.1 K8s 架构与核心概念

Kubernetes（简称 K8s，因为 K 和 s 之间有 8 个字母）是容器编排平台。当你的应用需要运行在几十台甚至几千台服务器上时，手动管理 Docker 容器会变得不可能。K8s 自动处理容器的调度、扩展、负载均衡、自我修复。你只需告诉它要几个副本，它自动找机器、启动容器、挂了重启。

控制平面（Control Plane，又称 Master 节点）——集群的大脑：

组件	功能	安全关注点
kube-apiserver	所有操作的唯一入口，处理所有 REST API 请求	认证、授权、审计——三个核心安全功能都在这里
etcd	分布式 KV 存储，保存集群全部配置和状态	etcd 丢了 = 集群丢了。必须加密、备份、限制访问
kube-scheduler	决定 Pod 在哪个 Node 上运行	调度策略可能影响安全（如将敏感 Pod 调度到特定节点）
kube-controller-manager	运行各种控制器循环（Deployment、ReplicaSet、Node 等）	—

工作节点（Worker Node）——运行实际应用的地方：

组件	功能
kubelet	Node 上的"管家"，接收 API Server 指令，管理 Pod
kube-proxy	实现 Service 的网络代理（iptables/IPVS）
Container Runtime	实际运行容器（Docker/containerd/CRI-O）

2.2 核心资源对象

资源	缩写	一句话说明
Pod	po	最小调度单元。一个 Pod 可以包含一个或多个紧密耦合的容器
Service	svc	为 Pod 提供稳定的访问入口（IP+端口），Pod 重启后 IP 会变，Service 不变
Deployment	deploy	声明期望的 Pod 副本数量，控制器自动维持该数量
ConfigMap	cm	存放非敏感的配置数据（环境变量、配置文件）
Secret	—	存放敏感数据。默认仅 Base64 编码，非加密
Namespace	ns	资源逻辑分组。不是安全边界——默认所有 Namespace 的 Pod 可互相访问
ServiceAccount	sa	Pod 访问 API Server 的身份。每个 Pod 默认挂载一个 SA Token
Role	—	定义"能做什么"（对哪些资源有哪些操作权限）。作用于单个 Namespace
ClusterRole	—	同 Role，但作用于整个集群
RoleBinding	—	将 Role 授予某个用户/组/ServiceAccount
ClusterRoleBinding	—	将 ClusterRole 授予集群范围

2.3 RBAC 安全审计

RBAC（Role-Based Access Control，基于角色的访问控制）是 K8s 的权限管理系统。核心原则：谁（Subject）+ 做什么（Verb）+ 对什么（Resource）+ 在哪里（Namespace/Cluster）。

三个高危配置：

高危 1：通配符 *:*:*

YAML

rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

这一条规则授予了对所有 API 组的所有资源的全部操作权限——等同于 cluster-admin。

BASH

# 审计命令：找出所有使用通配符的 Role/ClusterRole
kubectl get clusterroles -A -o yaml | grep -E "apiGroups.*\*|resources.*\*|verbs.*\*"

高危 2：默认 SA 绑定 cluster-admin

BASH

kubectl get clusterrolebindings -o json | jq ''.items[] | select(.roleRef.name=="cluster-admin") | {name: .metadata.name, subjects: .subjects}''

如果输出中包含 system:serviceaccount:default:default 或类似——意味着默认命名空间的默认 SA（所有没有指定自定义 SA 的 Pod 共用这个 SA）拥有集群管理员权限。这个 Pod 内任何人都可以操作整个集群。

高危 3：Pod 创建 + exec 权限

YAML

rules:
- apiGroups: [""]
  resources: ["pods", "pods/exec"]
  verbs: ["create", "get"]

拥有 create pods + exec pods 权限的攻击者可以创建特权 Pod 并逃逸。

2.4 Pod 内访问 API Server

每个 Pod 默认在以下路径挂载三个文件：

BASH

ls /var/run/secrets/kubernetes.io/serviceaccount/
# ca.crt      ← API Server 的 CA 证书
# namespace   ← Pod 所在的 Namespace
# token       ← JWT 格式的 ServiceAccount Token

使用 Token 访问 API Server：

BASH

TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
APISERVER=https://kubernetes.default.svc

# 列出当前 Namespace 的 Pod
curl -k -H "Authorization: Bearer $TOKEN" $APISERVER/api/v1/namespaces/default/pods

# 如果返回 Pod 列表 → 该 SA 有 list pods 权限
# 如果返回 403 Forbidden → 安全

2.5 Pod 安全配置

安全 Pod 完整模板：

YAML

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  # Pod 级别安全上下文
  securityContext:
    runAsNonRoot: true              # 强制以非 root 运行
    runAsUser: 1000                 # 指定运行用户
    seccompProfile:
      type: RuntimeDefault          # 使用默认 Seccomp 策略（阻止 ~44 个危险系统调用）
  containers:
  - name: app
    image: nginx:1.25
    securityContext:
      privileged: false             # 非特权
      allowPrivilegeEscalation: false  # 禁止任何形式的提权（包括 suid）
      readOnlyRootFilesystem: true     # 根文件系统只读（需要写入的目录需单独挂载 volume）
      capabilities:
        drop: ["ALL"]               # 移除所有 Capabilities

快速检查集群中的危险 Pod：

BASH

# 特权 Pod
kubectl get pods -A -o json | jq ''.items[] | select(.spec.containers[].securityContext.privileged==true) | .metadata.name''

# 挂载宿主机目录的 Pod（hostPath）
kubectl get pods -A -o json | jq ''.items[] | select(.spec.volumes[].hostPath) | {name, paths: [.spec.volumes[].hostPath.path]}''

# 以 root 运行的 Pod
kubectl get pods -A -o json | jq ''.items[] | select(.spec.containers[].securityContext.runAsUser==0) | .metadata.name''

2.6 K8s 加固要点

组件	加固措施	对应的启动参数或配置
API Server	禁用匿名访问	`--anonymous-auth=false`
API Server	RBAC 授权	`--authorization-mode=Node,RBAC`
API Server	开启审计日志	`--audit-log-path=/var/log/kube-audit.log`
etcd	证书认证	仅允许经过 mTLS 认证的客户端
etcd	数据加密	配置 `EncryptionConfiguration` 加密 Secret
kubelet	禁用匿名	`--anonymous-auth=false`

第三章 CICD 安全

3.1 流水线攻击面

源码仓库（GitHub/GitLab/Gitee）
  ↓ 凭据泄露、.git 目录暴露、分支保护缺失
构建系统（Jenkins/GitHub Actions/GitLab CI）
  ↓ 构建脚本注入、恶意依赖（typosquatting）、环境变量泄露
制品仓库（Docker Registry/Nexus/Artifactory）
  ↓ 镜像投毒、标签覆盖、未授权拉取/推送
部署环境（K8s/云主机）
  ↓ 部署配置错误、过度权限、Secret 泄露

3.2 源码安全——凭据扫描

BASH

# 使用 GitLeaks 扫描（https://github.com/gitleaks/gitleaks）
gitleaks detect --source . --verbose

# 手动搜索国内云平台 AccessKey
grep -rE "LTAI[0-9A-Za-z]{16,20}" .     # 阿里云
grep -rE "AKID[0-9A-Za-z]{13,20}" .     # 腾讯云

# 搜索私钥
grep -rE "-----BEGIN (RSA|EC|DSA) PRIVATE KEY-----" .

# 搜索密码
grep -rE "password\s*=\s*[\x27\x22][^\x27\x22]+" .

3.3 构建与部署安全

构建日志不打印环境变量
制品仓库配置认证
K8s 部署时检查环境变量中是否有硬编码凭据：

BASH

kubectl get pods -A -o yaml | grep -iE "SECRET|TOKEN|PASSWORD|ACCESS_KEY"

第四章本地实验环境

全部实验在个人电脑完成，零成本：

BASH

# Docker Desktop
# https://www.docker.com/products/docker-desktop/

# 启用内置 K8s
# 设置 → Kubernetes → Enable Kubernetes

# 第三步：安装安全工具
# Trivy: https://github.com/aquasecurity/trivy/releases
# kubeaudit: https://github.com/Shopify/kubeaudit/releases

# 环境就绪后验证：
# docker run --rm alpine sh
# trivy image node:14-alpine
# kubectl get pods -A

# 或使用 minikube
# https://minikube.sigs.k8s.io/docs/start/
minikube start

第一章 Docker 安全

1.1 Docker 核心概念与架构

1.2 Docker 安全隔离机制

1.3 容器逃逸

1.4 镜像安全

1.5 Registry 未授权访问

第二章 Kubernetes 安全

2.1 K8s 架构与核心概念

2.2 核心资源对象

2.3 RBAC 安全审计

2.4 Pod 内访问 API Server

2.5 Pod 安全配置

2.6 K8s 加固要点

第三章 CICD 安全

3.1 流水线攻击面

3.2 源码安全——凭据扫描

3.3 构建与部署安全

第四章 本地实验环境

第四章本地实验环境