更多请点击 https://kaifayun.com第一章Docker on VMware环境安全加固 checklistCIS Benchmark v2.0合规版概述本章节提供面向生产级 Docker 容器平台在 VMware vSphere 虚拟化环境中部署时严格遵循 CIS Docker Benchmark v2.0 及 CIS VMware vSphere 7.0/8.0 Benchmark 的交叉合规性加固清单。该 checklist 不仅覆盖容器运行时层Docker Engine、宿主机操作系统Linux、VMware ESXi 主机配置还纳入虚拟网络隔离、vCenter 权限模型与镜像生命周期治理等纵深防御维度。核心合规原则最小权限原则Docker daemon 不以 root 运行且禁用非必要 capabilities如 NET_ADMIN、SYS_ADMIN加密优先所有容器间通信及镜像拉取强制启用 TLS 1.2 与证书双向校验不可变基础设施VMware 虚拟机模板OVF/OVA预置加固策略禁止运行时修改关键内核参数Docker daemon 安全配置示例{ icc: false, userns-remap: default, no-new-privileges: true, default-ulimits: { nofile: { Name: nofile, Hard: 65536, Soft: 65536 } }, tlsverify: true, tlscacert: /etc/docker/tls/ca.pem, tlscert: /etc/docker/tls/server.pem, tlskey: /etc/docker/tls/server-key.pem }该配置需写入/etc/docker/daemon.json并执行sudo systemctl restart docker生效确保容器网络隔离、用户命名空间启用、特权限制及 TLS 加密通信全部激活。VMware 层关键加固项对照表VMware 组件CIS 控制项 ID推荐操作ESXi 主机VMSA-2022-0012禁用 SSH 服务除非审计必需启用 ESXi 防火墙并仅开放 443/902 端口vCenter ServerCIS-VCSA-7.0-1.1.1将 Docker 宿主 VM 归属至专用资源池并配置 CPU/Memory 限额与 DRS 规则第二章VMware底层基础设施安全基线配置2.1 ESXi主机CIS合规加固SSH、Shell与日志策略实践禁用未授权Shell访问ESXi默认启用ESXi Shell本地控制台和SSH服务CIS要求仅在必要时启用并限制访问源。通过Host Client或vSphere CLI执行# 禁用ESXi Shell非SSH esxcli system shell set --enabledfalse # 仅允许特定IP段通过SSH连接需配合防火墙规则 esxcli network firewall ruleset set -r sshServer -e true esxcli network firewall ruleset set -r sshServer -a 192.168.10.0/24该配置关闭交互式Shell入口同时将SSH规则集限定于运维网段避免暴露至管理网络全域。CIS日志保留策略配置设置系统日志最小保留天数为180天启用远程syslog转发至SIEM平台禁止日志覆盖前未归档logrotate策略联动关键参数合规对照表策略项CIS建议值ESXi CLI命令SSH空闲超时≤300秒esxcli system settings advanced set -o /UserVars/SSHIdleTimeOut -i 300日志最大大小≥8MBesxcli system syslog config set --log-levelinfo --log-dir-uniquetrue2.2 vSphere角色权限最小化基于RBAC的Docker宿主节点授权模型权限边界定义在vSphere中为Docker宿主节点分配权限时应严格限制至仅需的API集合。例如仅授予VirtualMachine.Inventory.Create、Host.Config.Network和Datastore.FileManagement等细粒度权限避免使用Administrator或ResourcePool.Administrator等宽泛角色。最小权限角色配置示例# vSphere RBAC角色定义片段通过vSphere REST API创建 { name: docker-host-operator, privilegeIds: [ VirtualMachine.Inventory.Create, VirtualMachine.Interact.PowerOn, Datastore.Browse ] }该配置确保宿主节点仅能创建/启停自身VM实例并访问指定数据存储杜绝跨租户资源操作能力。权限映射对照表操作场景vSphere权限对应Docker行为拉取镜像并写入本地存储Datastore.FileManagementdocker pull / docker save启动容器对应VMVirtualMachine.Interact.PowerOndocker run --runtimevsphere2.3 虚拟机硬件版本与固件安全策略UEFI Secure Boot与TPM 2.0启用指南硬件版本兼容性要求VMware Workstation 17 和 Hyper-V Gen 2 虚拟机默认支持 UEFI v2.3.1 与 TPM 2.0 模拟。旧版硬件如 VMX-13不提供 Secure Boot 控制接口。启用 Secure Boot 的关键配置firmware secureBoot enabledtrue/ tpm version2.0 enabledtrue/ /firmware该 XML 片段需注入虚拟机配置文件如 .vmx 或 .vmcxenabledtrue触发固件级签名验证链强制仅加载 Microsoft 或第三方签名的启动组件。TPM 2.0 信任链验证流程阶段验证目标依赖模块PCR0UEFI 固件完整性ROM/ACPI TablePCR2Secure Boot 策略DB/DBX 变量2.4 存储策略强化加密vSAN数据存储与快照访问控制加密策略配置vSAN 8.0 支持静态数据加密SDDP需在集群级别启用并绑定 KMS 服务器# 启用vSAN加密并指定KMS Get-VsanClusterConfiguration -Cluster Prod-Cluster | Set-VsanClusterConfiguration -DataEncryptionEnabled $true -KmsServer kms.corp.local该命令激活AES-256-GCM加密引擎所有新建对象自动加密KMS密钥轮换由外部服务管理vSAN仅缓存短期DEK。快照权限隔离通过vSphere RBAC限制快照操作权限Snapshot.Manage允许创建/删除快照仅授予备份管理员Snapshot.Config仅允许修改快照描述与保留策略加密状态验证表对象类型默认加密快照继承加密VM 磁盘✓策略启用后✓内存快照✗不加密✗2.5 网络堆栈加固分布式交换机安全策略与端口组隔离配置端口组隔离策略配置通过vSphere DVSDistributed Virtual Switch启用端口组VLAN隔离限制跨组二层通信portgroup namePG-Web-Secure/name vlanId101/vlanId promiscuousModefalse/promiscuousMode macChangestrue/macChanges forgedTransmitsfalse/forgedTransmits /portgrouppromiscuousModefalse阻止混杂模式抓包forgedTransmitsfalse拦截伪造源MAC帧防止横向渗透。安全策略对比表策略项默认值加固推荐值混杂模式truefalseMAC地址更改truetrue伪造传输truefalse实施要点为不同业务域创建独立端口组分配非重叠VLAN ID所有端口组启用“拒绝所有”防火墙规则后按需放行第三章Docker Engine与Runtime层深度加固3.1 CIS v2.0强制禁用的17项高危服务从dockerd参数到systemd unit覆盖实践核心禁用服务示例CIS v2.0明确要求禁用如avahi-daemon、rpcbind、telnetd等17项服务。其中dockerd需通过启动参数强化隔离# /etc/docker/daemon.json { iptables: false, userland-proxy: false, no-new-privileges: true, default-ulimits: { nofile: { Hard: 65536, Soft: 65536 } } }该配置关闭内核iptables规则注入禁用用户态代理以减少攻击面并强制容器进程无法提权。systemd unit覆盖策略通过drop-in覆盖禁用rpcbind服务sudo systemctl edit rpcbind.service # 添加 [Service] ExecStart ExecStart/bin/true此覆盖使服务启动即退出比disable更彻底规避依赖链意外激活。禁用服务对照表服务名风险类型推荐禁用方式avahi-daemonmDNS暴露内网拓扑systemctl mask avahi-daemonrsync未授权文件同步删除/usr/bin/rsync并chown root:root3.2 容器运行时安全配置gVisor与Kata Containers在VMware环境的选型与部署验证安全隔离模型对比特性gVisorKata Containers隔离层级用户态内核syscall拦截轻量级VM完整内核启动延迟100ms500msVMware兼容性原生支持无需嵌套虚拟化需启用Intel VT-x/AMD-V嵌套VMware中Kata部署关键配置# /etc/kata-containers/configuration.toml [hyperstart] enable true [hypervisor.qemu] path /usr/bin/qemu-system-x86_64 machine_type pc,accelvmware # 启用VMware特定优化 kernel_params consolettyS0 systemd.unitkata-containers.target该配置显式指定machine_typepc,accelvmware利用VMware Workstation/ESXi的硬件加速接口避免QEMU纯软件模拟开销kernel_params确保内核日志输出与systemd服务协同。选型决策树高密度多租户场景 → 优先gVisor资源占用低、无嵌套虚拟化依赖强合规要求如PCI-DSS→ Kata Containers硬件级隔离3.3 镜像供应链防护Notary签名验证与Trivy扫描集成至vSphere Container Registry流水线签名验证与漏洞扫描协同机制在CI/CD流水线中Notary v2Cosign负责对镜像签名验证Trivy执行SBOM生成与CVE扫描。二者通过OCI Artifact Annotations联动确保“签了才扫、扫完才推”。流水线集成配置示例steps: - name: verify-signature uses: sigstore/cosign-actionv3 with: image: registry.example.com/app:v1.2.0 certificate: ${{ secrets.COSIGN_CERT }} signature: ${{ secrets.COSIGN_SIG }} - name: trivy-scan uses: aquasecurity/trivy-actionmaster with: image-ref: registry.example.com/app:v1.2.0 format: sarif exit-code: 1该配置先校验签名有效性防止篡改再触发Trivy深度扫描exit-code: 1确保高危漏洞阻断发布。关键策略对照表组件职责失败响应Notary/Cosign验证镜像签名与证书链拒绝拉取中断流水线Trivy识别CVE-2023-XXXXX等高危漏洞生成SARIF报告并阻断部署第四章网络与通信面安全治理决策体系4.1 默认暴露的9个危险端口识别与阻断从netstat分析到NSX-T分布式防火墙策略落地端口识别netstat快速筛查# 筛选监听中且未绑定到127.0.0.1的TCP端口 netstat -tuln | awk $4 !~ /127\.0\.0\.1|::1/ $6 LISTEN {print $4} | \ cut -d: -f2 | sort -u | head -9该命令过滤出非本地回环监听的前9个TCP端口常暴露SSH22、HTTP80、MySQL3306等高危服务。常见危险端口对照表端口默认服务典型风险22SSH暴力破解、密钥泄露3306MySQL未授权访问、SQL注入外连NSX-T策略落地关键步骤在NSX Manager中创建“Block-Default-Exposure”安全策略关联至所有Tier-1网关下的工作负载段4.2 三种网络隔离模式对比评估Bridge/NAT/Host模式在VMware NSX-T中的性能与合规性权衡核心性能指标对比模式吞吐量Gbps延迟μsPCIe直通支持PCI-DSS合规性Bridge9.228✅⚠️需额外微分段NAT6.742❌✅默认地址隐藏Host10.119✅❌IP暴露风险NSX-T策略配置示例# Bridge模式启用分布式防火墙规则 - name: pci-zone-bridge applied_tos: [/infra/domains/default/groups/pci-servers] scope: [/infra/domains/default/groups/pci-servers] rules: - display_name: Block non-PCI traffic source_groups: [/infra/domains/default/groups/pci-servers] destination_groups: [/infra/domains/default/groups/external] action: DENY该YAML定义了Bridge模式下基于组的零信任策略applied_tos确保策略仅作用于PCI域内服务器scope限定匹配范围避免跨域策略污染。合规性实施路径NAT模式天然满足GDPR数据最小化原则但需禁用SNAT回流以保障审计日志完整性Host模式须配合NSX-T Identity Firewall启用应用层身份认证弥补网络层隔离缺失4.3 多租户容器网络设计基于vSphere with Tanzu的命名空间级微分段实现命名空间隔离机制vSphere with Tanzu 利用 NSX-T 的 Tier-1 Router 为每个 Kubernetes 命名空间自动部署专属逻辑交换机实现 L2/L3 级网络隔离。策略由 Supervisor Cluster 的 Network Policy Controller 同步至 NSX Manager。微分段策略示例apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: restrict-ns-egress namespace: finance-prod spec: podSelector: {} policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: tenant: finance ports: - protocol: TCP port: 443该策略仅允许finance-prod命名空间内 Pod 访问同租户tenant: finance命名空间的 HTTPS 服务拒绝跨租户流量。策略生效链路Kubernetes NetworkPolicy 被 Tanzu Kubernetes Grid ServiceTKGS转换为 NSX Distributed Firewall 规则规则按命名空间标签映射至对应 Logical SwitchNSX Edge 上执行状态化 ACL 匹配延迟 50μs4.4 Ingress与Service Mesh安全增强Istio mTLS策略在VMware Tanzu Kubernetes Grid中的策略注入实践mTLS策略注入机制Istio通过PeerAuthentication和DestinationRule资源协同实现mTLS强制启用。在Tanzu Kubernetes GridTKG集群中需确保工作负载Pod注入Sidecar并启用双向证书校验。apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: istio-system spec: mtls: mode: STRICT # 强制所有服务间通信启用mTLS该策略作用于istio-system命名空间全局生效mode: STRICT要求所有入站流量必须携带有效mTLS证书否则被拒绝。策略验证与调试流程确认Istio控制平面已部署且Revision标签匹配检查Pod是否注入Envoy Sidecaristioctl ps使用istioctl authz check验证mTLS状态组件配置要点TKG适配说明Ingress Gateway启用TLS mTLS上游认证需绑定TKG管理的vSphere CA签发证书Service MeshPeerAuthentication DestinationRule联动DestinationRule中tls.mode: ISTIO_MUTUAL为必需第五章附录CIS Docker Benchmark v2.0映射矩阵与自动化审计脚本CIS控制项与Docker配置的精准映射以下表格展示了CIS Docker Benchmark v2.0中高频风险项与容器运行时配置的对应关系覆盖认证、网络隔离与镜像信任三大核心维度CIS 控制项关联Docker配置检测方式4.1 – 禁用用户命名空间警告/etc/docker/daemon.json中userns-remap是否启用JSON键值校验5.26 – 限制容器共享主机IPC命名空间docker run --ipcprivate或 daemon默认default-runtime策略运行时参数扫描 daemon配置比对轻量级审计脚本Bash# 检查是否启用内容信任CIS 4.5 if [ $(docker info --format {{.ContentTrust}}) ! true ]; then echo [FAIL] Content trust disabled — violates CIS 4.5 exit 1 fi # 验证守护进程是否禁用iptables管理CIS 2.8 if grep -q iptables: true /etc/docker/daemon.json 2/dev/null; then echo [WARN] Docker manages iptables — may conflict with host firewall fi集成CI/CD流水线的实践要点将审计脚本嵌入GitLab CI的before_script阶段在构建前拦截不合规镜像构建请求使用dockerd --validate验证daemon.json语法后再执行systemctl reload docker审计结果以JUnit XML格式输出供Jenkins Test Result Analyzer解析并生成趋势图
