/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}
Docker 上线前权限收口：非 root、Seccomp、AppArmor 与 Secret
部署检查如果同时发现 USER root、Docker Socket 挂载和明文凭据，应直接阻止发布并分别修正。这里讨论的是配置风险组合，不假设它来自某次真实渗透。
如果业务同时存在 SSRF 且挂载了 Docker Socket，攻击链可能进一步调用 Docker API；是否已经执行仍需结合 Daemon 审计、容器事件和主机日志确认。检查配置是为了缩小暴露面，不代替取证结论。
1. 权限泄露风险分析：挂载 Docker Socket 与特权身份运行。
工程实践中，部分研发会忽视运行身份的最小权限原则，默认使用构建阶段的管理员身份。未启用 user namespace 时，容器内 UID 0 可映射到宿主机 UID 0，但仍受 capabilities、namespace、seccomp 等边界限制，并不等同于直接取得宿主机控制权。挂载 Docker Socket 才会明显扩大逃逸风险；风险判断应基于实际运行配置和漏洞链路。
上线部署前，可通过以下命令行核查容器镜像的配置合规性：
# 检查容器运行时的 User 配置属性是否为非 0 用户
docker inspect –format='{{.Config.User}}' application_container_name
# 检查容器挂载卷清单中是否包含宿主机 Docker Socket
docker inspect –format='{{range .Mounts}}{{.Source}} -> {{.Destination}}{{"\\n"}}{{end}}' application_container_name | grep docker.sock
# 使用 capsh 工具查看容器进程拥有的 Linux Capabilities 特权位
kubectl exec -it prod-pod-x928 -n default — capsh –print
如若命令输出表明 User 字段为空，或者挂载列表中包含 /var/run/docker.sock，说明该镜像配置违反安全策略，应在 CI/CD 阶段拦截发布。
2. 多阶段构建与最小化镜像：移除编译工具和无关运行依赖
缩减应用被攻击的表面积，应当贯彻“最小镜像原则”。传统的单阶段镜像构建会将编译工具链（如 gcc、g++、golang-sdk）以及大量的 Shell 命令行工具保留在最终的产物层中，为攻击提权提供了基础脚本环境。
通过采用 Dockerfile 多阶段构建（Multi-stage Build）机制，配合 scratch 或 distroless 基础镜像，能够缩减镜像体积并精简容器内的 Shell 交互环境。
重构后的多阶段构建 Dockerfile 示例如下：
# 第一阶段：编译构建环境
FROM golang:1.22-alpine AS builder
WORKDIR /app
RUN apk add –no-cache git ca-certificates
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-w -s" -o /app/service_binary .
# 第二阶段：极简运行时环境
FROM gcr.io/distroless/static-debian12:nonroot
WORKDIR /
COPY –from=builder /app/service_binary /service_binary
USER nonroot:nonroot
EXPOSE 8080
ENTRYPOINT ["/service_binary"]
多阶段构建通常能缩小镜像体积并移除不必要的工具链，实际体积取决于二进制、证书和运行依赖。移除 Shell 会减少攻击者可用工具，但不能消除命令注入或 Webshell 风险。
3. 上线配置收口：基于 Seccomp、AppArmor 与 Secret 卷的自动化校验。
编写安全的镜像文件是防御体系的第一步，配置收口的关键在于 CI/CD 自动化流水线中的静态审计拦截。通过校验脚本扫描 Kubernetes Deployment YAML 或 Docker Compose 配置文件，强制审查 SecurityContext 是否删除了非必要的 Capabilities，以及是否禁用了特权身份。
以下是采用 Python 编写的生产环境部署 YAML 配置审计脚本：
import sys
import yaml
from typing import List, Dict, Any
class SecurityAuditor:
def __init__(self, yaml_filepath: str):
self.filepath = yaml_filepath
self.errors: List[str] = []
def load_manifests(self) -> List[Dict[str, Any]]:
with open(self.filepath, 'r', encoding='utf-8') as f:
return list(yaml.safe_load_all(f))
def audit(self) -> bool:
manifests = self.load_manifests()
for doc in manifests:
if not doc or doc.get('kind') not in ['Deployment', 'StatefulSet', 'DaemonSet']:
continue
metadata = doc.get('metadata', {})
name = metadata.get('name', 'unknown')
spec = doc.get('spec', {}).get('template', {}).get('spec', {})
security_ctx = spec.get('securityContext', {})
if not security_ctx.get('runAsNonRoot', False):
self.errors.append(f"[{name}] Security Error: Pod spec.securityContext.runAsNonRoot must be true")
containers = spec.get('containers', [])
for c in containers:
c_name = c.get('name', 'unknown')
c_sec = c.get('securityContext', {})
if not c_sec.get('readOnlyRootFilesystem', False):
self.errors.append(f"[{name}/{c_name}] Security Warning: readOnlyRootFilesystem should be true")
caps = c_sec.get('capabilities', {})
drop_caps = caps.get('drop', [])
if 'ALL' not in [cap.upper() for cap in drop_caps]:
self.errors.append(f"[{name}/{c_name}] Security Error: capabilities.drop must contain 'ALL'")
if c_sec.get('allowPrivilegeEscalation', True):
self.errors.append(f"[{name}/{c_name}] Security Error: allowPrivilegeEscalation must be false")
return len(self.errors) == 0
if __name__ == "__main__":
if len(sys.argv) < 2:
print("Usage: python audit_security.py <deployment.yaml>")
sys.exit(1)
auditor = SecurityAuditor(sys.argv[1])
is_safe = auditor.audit()
if not is_safe:
print("SECURITY AUDIT FAILED! Violation summary:")
for err in auditor.errors:
print(f" – {err}")
sys.exit(1)
else:
print("Security audit passed. Configurations comply with security standards.")
sys.exit(0)
在清单配置层收紧权限后，可配合系统层面的 Seccomp 参数进行能力限制：
# 验证宿主机节点上的 AppArmor Profile 运行状态
aa-status | grep docker-default
# 容器启动时加载严格的系统调用过滤策略文件（Seccomp）
docker run -d –security-opt seccomp=/etc/docker/seccomp-strict.json –name secure_app app:v2.1
4. 权限边界：构建能力不带进运行时
上线安全收口的校验规则应覆盖从基础镜像选型到 K8s Admission Control 准入决策的边界逻辑。使用 Distroless/nonroot（如 UID 65532）基础镜像时，常见的运行崩溃避坑规则在于：如果应用需要在运行时解析 /etc/passwd 或者向 /etc/ssl/certs 写入自签名证书，会因为非 root 用户权限不足抛出 Permission Denied 错误。解决方案是在 Dockerfile 编译阶段复制好 ca-certificates，并显式指定 USER 65532:65532 权限归属。
对于挂载宿主机 /var/run/docker.sock 的避坑与替代规则：生产部署中应严格禁止直接挂载宿主机 Daemon Socket。如果业务容器需要拉起其他容器（如 CI/CD 或 Agent 动态沙盒），应替代为基于 Kubernetes API Server 的 RBAC 受限账号，或者使用基于用户态无特权运行的 Podman / Kaniko 工具，切断容器向宿主机内核提权的路径。
针对 Kubernetes 准入控制，可在 CI/CD 中集成 Open Policy Agent（OPA）或 Kyverno。当 Manifest 配置 allowPrivilegeEscalation: true 或缺少 runAsNonRoot: true 时，可按工作负载风险分级拒绝或要求例外审批。RuntimeDefault 是合理基线，但不能单独阻断未知内核漏洞，仍需配合补丁、最小权限和运行时监测。
