关基安全Helm Charts怎么审

本文目录导读：

1. 第一层：供应链与依赖安全（源头审计）
2. 第二层：Kubernetes 资源安全配置（运行时审计）
3. 第三层：Helm 模板逻辑与变量注入（配置审计）
4. 第四层：部署与生命周期管理（操作审计）
5. 给审计人员的实操建议（检查清单表）
6. 特别针对关基的关键红线（一票否决项）

针对关基（关键信息基础设施）场景下 Helm Charts 的审计，核心在于从“应用交付”角度，验证其是否符合国家等级保护、关基保护条例以及企业自身的合规与安全基线。

Helm Chart 本质上是一个打包了 Kubernetes 资源清单（YAML）、元数据（Chart.yaml）和模板逻辑（Go Template）的压缩包，审计它，不仅要看最终输出的 YAML 是否安全，还要看其模板逻辑是否会引入不安全变量，以及依赖的外部镜像/ Chart 是否存在供应链风险。

以下是针对关基场景的深度审计清单,分为四个层级：

第一层：供应链与依赖安全（源头审计）

这是关基场景的重中之重，因为 Helm Chart 通常会引入子 Chart 或依赖外部容器镜像。

1. 镜像来源与签名
   • 检查项： values.yaml 或 deployment.yaml 中的 image.repository 和 image.tag。
   • 风险： 使用了 latest 标签、使用了 Docker Hub 或第三方非可信仓库、未指定镜像 digest（SHA256）。
   • 关基要求： 必须使用内部私有仓库（Harbor / Nexus）的镜像，且标签必须是不可变的（如精确版本号或 Digest）。
2. 依赖 Chart 审计
   • 检查项： Chart.yaml 中的 dependencies 字段。
   • 风险： 引入了未审计的第三方公共 Chart（如 Bitnami），或依赖仓库使用了 HTTP（非 HTTPS）。
   • 做法： 检查依赖是否已拉取至内部仓库，并经过安全扫描（如 Trivy 扫描 Chart 中的镜像）。
3. Chart 签名（Provenance）
   • 检查项： 是否存在 PROVENANCE 文件及 .prov 签名文件。
   • 风险： 无签名，无法确认 Chart 是否被篡改。
   • 做法： 在安装时使用 --verify 标志,审计时需验证公钥链。

第二层：Kubernetes 资源安全配置（运行时审计）

这部分最繁琐，关键看你 Helm Chart 最终渲染出来的 YAML 是否安全。

1. 权限与 RBAC
   • 服务账户（ServiceAccount）： 检查是否会使用 default 服务账户。关基要求：必须显式创建并挂载自定义的、最小权限的服务账户。
   • ClusterRole 绑定： 检查是否存在 cluster-admin 级别的绑定，对于非系统组件（如数据库、应用），除非绝对必要,否则严禁绑定。
   • 自动化挂载： 检查 Pod Template 中 automountServiceAccountToken: false 是否被遗漏，当 Pod 不需要访问 API Server 时,应禁用。
2. 安全上下文（Security Context）
   • POD 级别： 检查 runAsNonRoot: true、runAsUser/Group 是否为高 ID（如 1000-2000，非 root 0）、fsGroup 是否合理。
   • 容器级别： 检查 capabilities.drop: ["ALL"]，并仅添加必要的 add（如 NET_BIND_SERVICE），检查 readOnlyRootFilesystem: true。
   • Seccomp / AppArmor： 检查是否注入了 seccomp.security.alpha.kubernetes.io/pod: runtime/default 或类似注解。关基环境通常要求开启。
3. 网络策略（NetworkPolicy）
   • 默认拒绝： 检查是否有默认的“拒绝所有入站”策略，Helm Chart 如果没有自带 NetworkPolicy,则存在风险。
   • 最小允许： 检查是否只开放了必要的 Ingress 和 Egress 规则，而非 或 0.0.0/0。
4. 资源限制与 Pod 安全标准
   • 资源配额： 检查 resources.requests 和 limits 是否已定义，缺乏限制会导致 DoS 风险。
   • Pod 安全准入： 检查 Chart 是否符合 Pod Security Standards 的 restricted 或 baseline 级别，禁止 privileged: true、hostPID: true、hostNetwork: true 等高风险选项。
5. 敏感信息存储（Secrets 与 ConfigMaps）
   • 硬编码值： 检查 values.yaml 文件中是否含有明文密码或 Token。
   • 环境变量泄露： 检查是否通过 env.value 直接传递敏感字段，而非使用 env.valueFrom.secretKeyRef。
   • 密钥加密： 检查 Chart 是否使用了 SealedSecrets 或 External Secrets Operator 等机制，而非直接存储明文 Secret。
   • ConfigMap 数据： 检查 ConfigMap 中是否意外存储了证书或连接字符串。

第三层：Helm 模板逻辑与变量注入（配置审计）

关基场景下，运维人员会通过 values.yaml 注入大量配置,模板逻辑必须安全。

1. 模板注入与转义
   • 风险点： 在 Helm 模板中使用 {{ .Values.description }} 这类变量时，如果未正确转义，可能被注入恶意表达式（虽然较少见，但属于深度审计）。
   • 检查项： 查找 tpl 函数的使用，确保用户输入的字符串不会意外调用 Go 模板函数。
2. 默认值与覆盖规则
   • 安全默认值： 检查 values.yaml 中的默认安全配置是否合理，默认的 replicaCount 是否为 2（高可用），默认的日志级别是否为 info 而非 debug（防止敏感信息泄露）。
   • 校验钩子： 检查是否存在 values.schema.json，这个 JSON Schema 文件可以校验用户输入的 values 类型、格式和枚举值。关基要求：必须提供 schema 文件,防止错误或非预期的配置注入。
3. 命名空间硬编码
   • 风险： 模板中硬编码了 namespace: default 或特定的业务命名空间。
   • 做法： 必须使用 .Release.Namespace 动态获取命名空间。

第四层：部署与生命周期管理（操作审计）

Helm 的 hooks 和 lifecycle 可能带来预安装或卸载阶段的执行风险。

1. Helm Hooks 脚本
   • 检查项： annotations: "helm.sh/hook: pre-install, post-upgrade" 等。
   • 风险： Hook 中运行的 Job 或 Pod 可能执行危险命令（如 kubectl delete、数据库 DROP TABLE），或请求外部资源（数据泄露）。
   • 审计要求： 逐行审查 Hook 中的 Job 模板及其容器命令，对于关基系统，应限制 Hook 的执行用户和网络。
2. Webhook 与 Admission

   Chart 自带的 Mutating / Validating Webhook，需特别审计其逻辑，防止其绕过 Kubernetes 自身的准入控制器（如 Pod Security Admission）。

3. 版本回退策略
   • 审计 Chart 是否支持 --history-max 限制，防止 helm rollback 操作时因历史版本未清理导致的资源泄露。

给审计人员的实操建议（检查清单表）

你可以使用以下工具链和思路来执行审计：

特别针对关基的关键红线（一票否决项）

如果在审计中发现以下任意一项，该 Helm Chart 应被立即拒绝部署：

1. 容器以 root 用户（UID=0）运行。
2. 镜像使用了 latest 或可变标签，且未指定 SHA256 Digest。
3. 存在 privileged: true 或挂载了宿主机敏感路径（如 /var/run/docker.sock、/proc、/sys）。
4. 未定义 NetworkPolicy，或 NetworkPolicy 允许 0.0.0/0 出站。
5. 在 values.yaml 或 ConfigMap 中出现了明文密码、Token 或证书私钥。
6. 依赖的 Chart 或镜像来自互联网公共仓库且未经内部安全团队扫描。

关基的 Helm Chart 审计，核心是“不可信执行”的前提——即 Chart 中所有的镜像、配置、默认值都应被视为潜在不安全，需要通过内部安全基线（通常以 OPA/Kyverno 策略形式固化）的严格校验。