---
tags: [docker, image-security, trivy, distroless, registry]
create time: 2026-05-18 00:45
---

# 镜像安全 — 扫描、基线 & 仓库管理

## 概述

镜像安全不仅仅是"不要有 CVE"——它是一个完整的供应链安全体系，涵盖基础镜像选型、漏洞扫描、仓库分级管理和推送门禁。更多内容参见 [[../01-容器化/01-Dockerfile最佳实践]]。

## 镜像扫描流程

```mermaid
flowchart LR
    Scan["镜像扫描 (Trivy/Snyk)"] --> Clean{"漏洞等级?"}
    
    Clean -- "CRITICAL/HIGH" --> Block["❌ 阻止推送"]
    Clean -- "MEDIUM" --> Review["⚠️ 人工审核"]
    Clean -- "LOW/INFO" --> Allow["✅ 允许推送"]
    
    style Block fill:#ffebee
    style Review fill:#fff3e0
    style Allow fill:#e8f5e9
```

### Trivy 常用命令

```bash
# 扫描镜像
trivy image harbor.example.com/app/server:v1.2.3

# 只报告 HIGH 及以上级别
trivy image --severity HIGH,CRITICAL harbor.example.com/app/server:v1.2.3

# 输出 JSON 供 CI 集成
trivy image --format json --output report.json harbor.example.com/app/server:v1.2.3

# 扫描 Dockerfile 中的潜在问题
trivy config Dockerfile
```

## 安全检查清单

- [ ] 不使用 `latest` tag（永远用具体版本号）→ 精确回滚
- [ ] 不安装不必要的软件包（`apk del --purge .build-deps`）→ 最小攻击面
- [ ] 定期更新基础镜像（修复 CVE）→ 跟上安全补丁节奏
- [ ] 使用非 root 用户运行 → `USER appuser`
- [ ] 镜像不包含密钥、密码、私钥 → CI/CD Secret 挂载代替 ENV
- [ ] 使用最小基础镜像（scratch / distroless）→ 减少暴露面

## Distroless 镜像

Google 推出的**无 shell、无包管理器**的极简运行时镜像：

```dockerfile
# 最极致的精简
FROM gcr.io/distroless/static-debian12
COPY --from=builder /app/server .
USER nonroot
CMD ["./server"]
```

> ⚠️ 注意：distroless 镜像没有 shell (`/bin/sh`)，调试时需要额外工具（如 debug 镜像或 `kubectl exec` 到 sidecar）。

### 常用 Distroless 变种

| 镜像 | 适用场景 | 大小 |
|------|---------|------|
| `gcr.io/distroless/static-debian12` | 纯静态二进制 | ~2MB |
| `gcr.io/distroless/base-debian12` | 需要 glibc 的动态链接程序 | ~30MB |
| `gcr.io/distroless/java17` | Java 应用（含 JRE） | ~150MB |
| `gcr.io/distroless/nodejs18` | Node.js 应用 | ~100MB |

## 镜像压缩对比参考

| 基础镜像 | 典型 Go 服务大小 | 备注 |
|---------|-----------------|------|
| `ubuntu:22.04` | ~35 MB | 完整发行版 |
| `debian:bookworm-slim` | ~20 MB | 裁剪后较常用 |
| `alpine:3.19` | ~7 MB | musl libc，偶有兼容问题 |
| `distroless/static` | ~5 MB | 无 shell，生产推荐 |
| `scratch` | <取决于二进制 | 仅静态链接二进制可运行 |

> [!warning] Alpine 与 musl libc
> 
> Alpine 使用 musl libc 而非 glibc。某些 C 扩展（如 `node-gyp`、部分 Python wheel）可能无法编译或运行时行为不一致。Go 服务通过 `CGO_ENABLED=0` 规避了此问题，但 Node.js/Python 应用需谨慎评估。

## 镜像仓库管理与流转

```mermaid
flowchart LR
    Dev["开发者本地"] -->|"docker push"| DEV_REPO["dev 仓库<br/>v1.2.3-dev"]
    
    Staging["Staging 验证"] -->|"通过"| PROD_REPO["prod 仓库<br/>v1.2.3"]
    
    K8s["K8s Cluster"] -->|"pull"| PROD_REPO
    
    PR["PR Merge"] --> Tag["打标签 v1.2.3"]
    Tag --> ProdRepoMove["移动到 prod 仓库"]
    
    style DEV_REPO fill:#fff3e0
    style PROD_REPO fill:#e8f5e9
```

| 仓库方案 | 特点 | 适用场景 |
|---------|------|---------|
| **Harbor** | 自托管，RBAC + 扫描 | 国内企业首选 |
| **ECR / ACR / GCR** | 云厂商托管 | 全云环境 |
| **Docker Hub** | 公共免费 | 开源项目 |

### Harbor 最佳实践

| 实践 | 说明 |
|------|------|
| **项目隔离** | dev/prod 独立项目，不同团队有不同权限 |
| **自动扫描** | 推送时自动触发 Trivy 扫描，阻断高危漏洞 |
| **复制规则** | dev 仓库 → prod 仓库自动复制已通过测试的镜像 |
| **生命周期策略** | 自动清理过期镜像和垃圾数据 |

## 补充：镜像签名与 Cosign

为了防止中间人攻击或被篡改的镜像被拉到集群，可以使用 Sigstore Cosign 对镜像签名：

```bash
# 签名镜像
cosign sign --key cosign.key harbor.example.com/app/server:v1.2.3

# 在 CI 中验证签名
cosign verify --key cosign.pub harbor.example.com/app/server:v1.2.3

# 不依赖密钥的验证（ rekor 透明日志）
cosign verify --certificate-identity=email@company.com \
    --certificate-oidc-issuer=https://accounts.google.com \
    harbor.example.com/app/server:v1.2.3
```

> [!info] 镜像签名 vs 漏洞扫描
> 
> 两者解决不同问题：
> - **漏洞扫描** = 这个镜像有没有已知漏洞？
> - **镜像签名** = 这个镜像确实是我们构建的，没有被篡改？
> 
> 生产环境应该两者都有。签名可以作为 Gatekeeper/Admission Webhook 的一部分，在 Pod 启动前强制验证镜像签名。

## 关联笔记

- [[../01-容器化/01-Dockerfile最佳实践]] — Dockerfile 中的安全加固
- [[../01-容器化/02-多架构构建]] — Buildx 构建全平台镜像
- [[../hhs/MS/05-部署运维/03-CICD与GitOps]] — CI 流水线中的安全扫描环节