Docker与Kubernetes安全的十大常见漏洞：从特权容器到未授权API访问的防护清单

Docker与Kubernetes安全的十大常见漏洞：从特权容器到未授权API访问的防护清单

一、容器安全现状：被低估的威胁面

容器化带来效率，也带来了全新的攻击面。根据CNCF 2026年的安全报告，容器环境相关的安全事件同比增长47%，其中前三类漏洞是：特权容器滥用（占比31%）、镜像供应链攻击（占比24%）、API Server未授权访问（占比18%）。更令人担忧的是，68%的受调查团队在发现安全漏洞时，漏洞已经存在了3个月以上。

容器的威胁面可以从四个维度划分：镜像安全（构建阶段）、运行时安全（运行阶段）、编排安全（Kubernetes层）、供应链安全（依赖链层）。本文覆盖这四大维度下最常见的十大漏洞，每个漏洞都包含危险等级、检测方法和修复方案。

二、镜像安全：构建阶段的三大致命漏洞

漏洞一：基础镜像包含已知高危CVE

危险等级：严重 | 影响面：85%+的容器镜像

漏洞描述：使用未扫描的公共基础镜像（如 node:16、python:3.9），这些镜像可能包含数百个已知CVE，包括远程代码执行（RCE）和权限提升漏洞。

检测方法：

# 使用Trivy扫描镜像漏洞
trivy image –severity CRITICAL,HIGH python:3.9
# 预期输出应清空所有CRITICAL和HIGH漏洞

修复方案：

• 使用官方维护的最小化镜像（如 distroless、alpine）
• 在CI Pipeline中集成镜像扫描（Trivy/Grype），阻断含高危CVE的镜像推送到仓库

import logging
import subprocess
import json
from typing import Dict, List, Optional
from dataclasses import dataclass

logger = logging.getLogger(__name__)

@dataclass
class ImageSecurityPolicy:
"""镜像安全策略"""
max_critical_cves: int = 0 # 允许的Critical CVE数量
max_high_cves: int = 5 # 允许的高危CVE数量
max_medium_cves: int = 20 # 允许的中危CVE数量
block_on_policy_violation: bool = True # 违反策略时是否阻断

class ImageSecurityScanner:
"""容器镜像安全扫描器"""

def __init__(self, policy: ImageSecurityPolicy = None):
self.policy = policy or ImageSecurityPolicy()

def scan_image(self, image_name: str) -> Dict:
"""扫描镜像安全漏洞

Args:
image_name: 镜像名称（含标签）

Returns:
扫描结果，包含漏洞统计和策略合规性
"""
result = {
"image": image_name,
"scan_tool": "trivy",
"passed": True,
"vulnerabilities": {},
"violations": []
}

try:
# 执行Trivy扫描（输出JSON格式）
cmd = [
"trivy", "image", "–format", "json",
"–severity", "CRITICAL,HIGH,MEDIUM",
"–no-progress",
image_name
]

proc = subprocess.run(
cmd, capture_output=True, text=True, timeout=300
)

if proc.returncode != 0 and proc.returncode != 1:
# returncode=0: 无漏洞, =1: 有漏洞, 其他: 扫描错误
result["passed"] = False
result["error"] = f"扫描失败: {proc.stderr[:200]}"
logger.error(f"镜像扫描失败: {image_name}")
return result

# 解析扫描结果
try:
scan_data = json.loads(proc.stdout)
except json.JSONDecodeError:
result["passed"] = False
result["error"] = "扫描结果JSON解析失败"
return result

# 统计各等级漏洞数量
severity_counts = {"CRITICAL": 0, "HIGH": 0, "MEDIUM": 0, "LOW": 0}
for report in scan_data.get("Results", []):
for vuln in report.get("Vulnerabilities", []):
sev = vuln.get("Severity", "UNKNOWN")
if sev in severity_counts:
severity_counts[sev] += 1

result["vulnerabilities"] = severity_counts

# 策略合规性检查
if severity_counts["CRITICAL"] > self.policy.max_critical_cves:
result["violations"].append(
f"CRITICAL漏洞: {severity_counts['CRITICAL']} "
f"(允许: {self.policy.max_critical_cves})"
)
result["passed"] = False

if severity_counts["HIGH"] > self.policy.max_high_cves:
result["violations"].append(
f"HIGH漏洞: {severity_counts['HIGH']} "
f"(允许: {self.policy.max_high_cves})"
)
result["passed"] = False

if severity_counts["MEDIUM"] > self.policy.max_medium_cves:
result["violations"].append(
f"MEDIUM漏洞: {severity_counts['MEDIUM']} "
f"(允许: {self.policy.max_medium_cves})"
)
result["passed"] = False

status_msg = "通过" if result["passed"] else "未通过"
logger.info(f"镜像扫描: {image_name} – {status_msg} "
f"(C:{severity_counts['CRITICAL']}/H:{severity_counts['HIGH']}"
f"/M:{severity_counts['MEDIUM']})")

return result

except subprocess.TimeoutExpired:
logger.error(f"镜像扫描超时: {image_name}")
return {"image": image_name, "passed": False, "error": "扫描超时"}
except Exception as e:
logger.error(f"镜像扫描异常: {image_name} – {e}", exc_info=True)
return {"image": image_name, "passed": False, "error": str(e)}

漏洞二：镜像中硬编码密钥和凭证

危险等级：严重

典型场景：Dockerfile中直接写入数据库密码、API Key等敏感信息：

# 危险做法：硬编码密钥
ENV DATABASE_PASSWORD=MySecretPass123
ENV AWS_ACCESS_KEY_ID=AKIAXXXXXXXX

这些密钥会永久保存在镜像层中，即使后续删除ENV指令也无法从镜像历史中移除。任何人获取镜像后都可以通过 docker history 查看所有层的构建历史。

检测方法：

# 使用TruffleHog扫描镜像中的密钥
trufflehog filesystem –directory=/path/to/extracted/image
# 或使用git-secrets扫描Dockerfile
git-secrets –scan Dockerfile

修复方案：

• 使用Kubernetes Secret或外部密钥管理服务（Vault/AWS Secrets Manager）
• 在Dockerfile中使用 .dockerignore 排除含密钥的文件
• CI Pipeline中集成密钥扫描，发现硬编码密钥立即阻断构建

漏洞三：使用latest标签和无版本化镜像

危险等级：中

漏洞描述：image: nginx:latest 意味着每次部署可能拉取到不同版本的镜像。如果最新版本包含破坏性变更或新增安全漏洞，你的服务会在不知情的情况下受到影响。此外，回滚时无法确定之前的"latest"对应哪个具体版本。

修复方案：使用语义化版本标签（如 nginx:1.25.3-alpine）或镜像摘要（Digest），并在CI Pipeline中禁止使用 latest 标签。

三、运行时安全：三大危险配置

漏洞四：特权容器（privileged: true）

危险等级：严重 | 利用难度：极低

漏洞描述：securityContext.privileged: true 赋予容器几乎等同于宿主机的所有能力，包括访问所有设备、加载内核模块、修改内核参数。一旦特权容器被攻破，攻击者可以逃逸到宿主机。

检测命令：

# 扫描集群中所有特权容器
kubectl get pods –all-namespaces -o json | \\
jq '.items[] | select(.spec.containers[].securityContext.privileged==true) |
{namespace: .metadata.namespace, name: .metadata.name}'

修复方案：99%的场景不需要特权容器。如果确实需要某些Linux Capability（如 NET_ADMIN 用于网络配置），使用细粒度的capability添加而非整个特权模式：

securityContext:
capabilities:
add: ["NET_ADMIN", "SYS_TIME"]
drop: ["ALL"] # 先删除所有能力，再按需添加
privileged: false # 明确禁止特权模式

漏洞五：以root用户运行容器

危险等级：高 | 影响面：60%+的容器

漏洞描述：默认情况下，容器以root用户（UID 0）运行。如果容器内的应用被攻破，攻击者获得的是容器内的root权限，配合其他漏洞（如挂载了Docker Socket）可以直接控制宿主机。

检测方法：

# 检查以root运行的Pod
kubectl get pods –all-namespaces -o json | \\
jq '.items[] | select(.spec.containers[].securityContext.runAsUser==null or
.spec.containers[].securityContext.runAsUser==0) |
[.metadata.namespace, .metadata.name]'

修复方案：

# Pod安全上下文配置
securityContext:
runAsNonRoot: true # 强制非root运行
runAsUser: 1000 # 指定非root UID
fsGroup: 1000 # 文件系统组ID

Dockerfile层面：

# 创建非root用户并切换
RUN addgroup -g 1000 appgroup && \\
adduser -u 1000 -G appgroup -D appuser
USER appuser

漏洞六：敏感目录挂载（Docker Socket、hostPath）

危险等级：严重

典型危险挂载：

• /var/run/docker.sock：允许容器完全控制Docker守护进程
• /proc：暴露宿主机进程信息
• /sys：允许修改内核参数
• /（根目录）：完全访问宿主机文件系统

检测方法：

# 检查敏感hostPath挂载
kubectl get pods –all-namespaces -o json | \\
jq '.items[] | select(.spec.volumes[].hostPath.path |
test("/var/run/docker.sock|/proc|/sys|/etc")) |
{ns: .metadata.namespace, pod: .metadata.name}'

import logging
from typing import Dict, List

logger = logging.getLogger(__name__)

class ContainerSecurityAuditor:
"""容器安全配置审计器"""

# 危险挂载路径列表
DANGEROUS_MOUNTS = [
"/var/run/docker.sock", # Docker Socket
"/proc", # 进程文件系统
"/sys", # 内核参数
"/etc/kubernetes", # K8s配置
"/var/lib/kubelet", # Kubelet数据
"/etc/shadow", # 密码文件
]

# 危险Capability列表
DANGEROUS_CAPABILITIES = [
"SYS_ADMIN", # 几乎所有系统管理操作
"SYS_PTRACE", # 进程跟踪
"SYS_MODULE", # 内核模块加载
"NET_RAW", # 原始网络包
"DAC_OVERRIDE", # 绕过文件权限
]

def audit_pod_security(self, pod_spec: Dict) -> List[Dict]:
"""审计单个Pod的安全配置

Args:
pod_spec: Pod的spec定义

Returns:
安全问题列表
"""
issues = []

try:
containers = pod_spec.get("containers", [])
volumes = pod_spec.get("volumes", [])

for container in containers:
container_name = container.get("name", "unknown")
sec_ctx = container.get("securityContext", {})

# 检查1：特权容器
if sec_ctx.get("privileged"):
issues.append({
"container": container_name,
"severity": "critical",
"issue": "容器以特权模式运行",
"fix": "设置 securityContext.privileged=false，按需添加Linux Capability"
})

# 检查2：root用户运行
run_as_user = sec_ctx.get("runAsUser")
run_as_non_root = sec_ctx.get("runAsNonRoot")
if (run_as_user is None or run_as_user == 0) and not run_as_non_root:
issues.append({
"container": container_name,
"severity": "high",
"issue": "容器以root用户运行",
"fix": "设置 runAsNonRoot=true 和 runAsUser=1000"
})

# 检查3：危险Capability
capabilities = sec_ctx.get("capabilities", {}).get("add", [])
for cap in capabilities:
if cap in self.DANGEROUS_CAPABILITIES:
issues.append({
"container": container_name,
"severity": "high",
"issue": f"容器具有危险Capability: {cap}",
"fix": f"除非明确需要，否则移除 {cap}"
})

# 检查4：危险hostPath挂载
for volume in volumes:
host_path = volume.get("hostPath", {}).get("path", "")
for dangerous_path in self.DANGEROUS_MOUNTS:
if host_path.startswith(dangerous_path):
issues.append({
"container": "pod-level",
"severity": "critical",
"issue": f"容器挂载了敏感路径: {host_path}",
"fix": f"移除 {host_path} 的hostPath挂载，使用其他方式替代"
})

return issues

except Exception as e:
logger.error(f"Pod安全审计异常: {e}", exc_info=True)
return [{"severity": "error", "issue": str(e)}]

四、编排层安全：三大Kubernetes漏洞

漏洞七：API Server未授权访问

危险等级：严重 | 影响面：Kubernetes集群的"上帝权限"

漏洞描述：Kubernetes API Server对外开放且未配置RBAC认证，或使用默认的 –anonymous-auth=true 且绑定 system:anonymous 到高权限ClusterRole。攻击者可以列举所有Pod、删除Deployment、甚至创建特权容器。

检测方法：

# 测试匿名访问（预期返回403）
kubectl get pods –token="" –certificate-authority="" \\
–server=https://<api-server>:6443 2>&1

修复方案：

• 确保API Server启动参数包含 –anonymous-auth=false
• 使用RBAC最小权限原则
• 启用审计日志监控可疑的API调用模式
• 使用网络策略限制API Server的访问来源IP

漏洞八：RBAC权限过度授予

危险等级：高

典型问题：为方便开发调试，将 cluster-admin 权限绑定到 default ServiceAccount或开发团队的所有成员。一旦某个Pod的ServiceAccount Token泄露，攻击者获得整个集群的管理权限。

检测方法：

# 查找具有cluster-admin权限的ServiceAccount
kubectl get clusterrolebindings -o json | \\
jq '.items[] | select(.roleRef.name=="cluster-admin") |
.subjects[] | select(.kind=="ServiceAccount")'

修复方案：遵循RBAC最小权限原则，为每个服务创建专属的Role（命名空间级），而非ClusterRole（集群级）。

漏洞九：Secret明文存储

危险等级：高

Kubernetes Secret默认以Base64编码存储（不是加密！），任何人能读取etcd数据或通过 kubectl get secret -o yaml 即可获取原始值。base64 -d 即可解码。

修复方案：

• 启用etcd静态加密（EncryptionConfiguration）
• 使用外部密钥管理工具（Vault + External Secrets Operator）
• 限制Secret的RBAC读取权限（非所有ServiceAccount都能读取Secret）

# Kubernetes etcd静态加密配置
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
– resources:
– secrets
providers:
– aescbc:
keys:
– name: key1
secret: <base64-encoded-32-byte-key>
– identity: {} # 兜底：明文存储（仅用于迁移过渡期）

五、供应链安全：镜像来源的可信性

漏洞十：未签名的镜像和不可信镜像源

危险等级：中-高

漏洞描述：从不可信的镜像仓库拉取镜像，没有签名验证，无法确认镜像在构建到部署之间是否被篡改。

修复方案：

• 使用私有镜像仓库（Harbor/ACR/ECR）并配置镜像签名（Cosign/Notary）
• 在Kubernetes中使用Admission Controller（如Kyverno/OPA）验证镜像签名
• 配置 imagePullPolicy: IfNotPresent 避免每次都从远程拉取

import logging
from typing import Dict, List

logger = logging.getLogger(__name__)

class ImageSupplyChainValidator:
"""镜像供应链安全验证器"""

# 受信任的镜像仓库白名单
TRUSTED_REGISTRIES = [
"harbor.internal.company.com",
"docker.io/library", # 仅限官方镜像
"registry.k8s.io",
]

def validate_image_source(self, image_name: str) -> Dict:
"""验证镜像来源的可信性

Args:
image_name: 完整镜像名（如 harbor.company.com/app:v1.0）

Returns:
验证结果
"""
result = {
"image": image_name,
"trusted": False,
"issues": []
}

try:
# 检查1：是否使用了latest标签
if ":" not in image_name or image_name.endswith(":latest"):
result["issues"].append({
"severity": "high",
"issue": "使用了latest标签，无法确定具体版本",
"fix": "指定具体的版本号或镜像摘要(Digest)"
})

# 检查2：是否来自受信任的Registry
registry = image_name.split("/")[0] if "/" in image_name else "docker.io"
is_trusted = any(registry.startswith(t) for t in self.TRUSTED_REGISTRIES)

if not is_trusted:
result["issues"].append({
"severity": "high",
"issue": f"镜像来自非信任Registry: {registry}",
"fix": f"使用受信任的Registry: {', '.join(self.TRUSTED_REGISTRIES)}"
})
else:
result["trusted"] = True

# 检查3：是否包含摘要（最安全的引用方式）
if "@sha256:" in image_name:
result["trusted"] = True
result["note"] = "使用Digest引用，安全性最高"

return result

except Exception as e:
logger.error(f"镜像供应链验证异常: {e}")
return {"image": image_name, "trusted": False, "error": str(e)}

五、总结

Docker和Kubernetes安全的十大常见漏洞，本质上反映了"便利性优先于安全性"的默认配置哲学。从镜像构建阶段的CVE和密钥泄露，到运行时的特权容器和root用户，再到编排层的API Server暴露和RBAC滥用，每个漏洞都有明确的检测方法和修复方案。

三条核心安全原则：

下一步：在CI/CD Pipeline中集成自动化的容器安全检查工具链（Trivy+TruffleHog+Kyverno），实现"不安全的镜像无法构建、不合规的配置无法部署"的安全硬约束。