1. 项目概述为什么你的 Helm Chart 可能正在“裸奔”最近在帮几个团队做内部 DevOps 成熟度评估一个让我后背发凉的现象是超过一半的、正在生产环境运行的 Helm Chart其values.yaml文件里都或多或少地藏着“定时炸弹”。这可不是危言耸听。Helm 作为 Kubernetes 的包管理器极大地简化了应用部署但values.yaml这个用于配置覆盖的文件却成了安全审计中最容易被忽视的盲区。很多开发者包括一些有经验的运维都习惯性地把测试环境的数据库密码、云服务的 Access Key、甚至内部 API 的令牌直接写死在values.yaml里然后把这个文件随 Chart 一起提交到代码仓库。这无异于把家门钥匙挂在门口的信箱上。这个项目要做的就是针对values.yaml文件进行专项安全审计。它主要聚焦两个核心风险点一是敏感信息泄露即检查文件中是否明文存储了密码、密钥、令牌等不该出现的内容二是安全默认值检查即评估 Chart 提供的默认配置是否遵循了安全最佳实践比如是否默认关闭了不必要的端口、是否禁用了默认的管理员密码等。这不仅仅是扫描几个关键词那么简单它需要你理解云原生环境下的安全模型、Secrets 的管理方式以及如何通过策略即代码Policy-as-Code的思路将安全检查左移融入到 CI/CD 流程中。如果你正在管理一个包含数十甚至上百个 Helm Chart 的仓库或者你负责的微服务即将通过 Helm 对外交付那么这项审计是你必须补上的一课。2. 核心风险解析values.yaml 里的“雷区”到底在哪2.1 敏感信息泄露明文存储的“原罪”values.yaml的本质是提供用户可覆盖的配置模板。问题就出在很多 Chart 的维护者为了方便“开箱即用”或者示例清晰会把一些需要密文的信息用明文占位符或示例值写进去。而用户在使用时往往直接修改这个文件填入真实值然后……就忘了处理。第一类硬编码的凭证。这是最直接的风险。你会在values.yaml里看到诸如以下字段database: host: “prod-db.cluster.local” port: 5432 username: “appuser” password: “SuperSecretPassword123!” # 灾难 name: “appdb” redis: password: “redis-pass” # 同样危险 smtp: user: “alertscompany.com” password: “emailPassword”这些密码一旦进入版本控制系统如 Git就会永久留存。即使你后续删除在 Git 历史中依然可查。攻击者通过爬取公开或内部泄露的代码库能轻易获取这些信息直接访问你的核心数据服务。第二类配置文件嵌入。更隐蔽的一种情况是通过extraEnv、extraConfig或files字段将整个包含敏感信息的配置文件如application.properties,.env的内容以多行字符串的形式嵌入。extraConfig: | spring.datasource.urljdbc:mysql://localhost:3306/db spring.datasource.usernameroot spring.datasource.passwordroot_password_here api.keysk_live_xxxxxxxxxxxxxx这种方式把敏感信息藏在了更深的结构里不仔细查看文件内容很难发现但危害同样巨大。第三类镜像拉取密钥。为了从私有镜像仓库拉取镜像需要在values.yaml中配置imagePullSecrets。通常这里应该引用一个预先创建好的 Kubernetes Secret 的名称。但错误做法是尝试在这里直接写dockerconfigjson的内容。# 错误做法试图在此处编码secret imagePullSecrets: - name: my-registry-secret # 下面这行不应该出现在values里 .dockerconfigjson: ewogICJhdXRocyI6IHsKICAgICJyZWdpc3RyeS5leGFtcGxlLmNvbSI6IHsKICAgICAgInVzZXJuYW1lIjogInVzZXIiLAogICAgICAicGFzc3dvcmQiOiAicGFzcyIsCiAgICAgICJlbWFpbCI6ICJ1c2VyQGV4YW1wbGUuY29tIiwKICAgICAgImF1dGgiOiAiZGZZV1J2YjI1bElHUmxjaUJwYmlJNklDSmthVzUwYVdOa0lpd2dQZz09IgogICAgfQogIH0KfQ正确的做法是在values.yaml中只声明 Secret 的名称而 Secret 本身通过kubectl create secret或 sealed-secrets 等工具在部署时动态注入。注意一个常见的误区是认为把values.yaml放在私有仓库就安全了。但仓库的访问控制可能失效如误设权限、仓库可能被攻破、或者代码在开发者本地环境被恶意软件扫描。敏感信息永远不应该以明文形式进入版本控制系统这是铁律。2.2 安全默认值缺失为攻击者打开的后门如果说敏感信息泄露是“主动送人头”那么不安全的默认值就是“家门没锁”。Chart 的默认配置应该遵循“最小权限原则”和“安全默认”原则。但很多社区或早期自研的 Chart 为了追求易用性牺牲了安全性。1. 服务暴露面过广。默认开启所有服务端口且 Service 类型设为LoadBalancer或NodePort。例如一个 Redis Chart 默认同时开启 6379数据端口和 16379哨兵端口并且没有配置任何网络策略NetworkPolicy来限制入站流量来源。这可能导致内部缓存服务意外暴露在公网或内部非信任网络段。2. 管理接口无防护。许多中间件如 MySQL、MongoDB、Consul、Etcd以及 Web 应用如 Jenkins、GitLab带有管理界面或 API。不安全的默认值可能包括默认启用管理界面且绑定到0.0.0.0。使用广为人知的默认账号密码如admin/admin,root/空密码。没有默认设置强密码或强制在首次使用时修改。没有默认启用身份认证Auth或传输层安全TLS。3. 不安全的 Pod 安全上下文。默认以root用户或用户ID 0运行容器。如果容器被攻破攻击者将获得容器内的 root 权限增加了逃逸到宿主机的风险。安全的默认值应该指定一个非 root 的用户 ID 和组 ID。# 不安全的默认值 securityContext: {} # 空对象意味着使用镜像默认用户往往是root # 更安全的默认值 securityContext: runAsNonRoot: true runAsUser: 1000 runAsGroup: 1000 allowPrivilegeEscalation: false capabilities: drop: - ALL4. 资源限制缺失。没有设置 CPU 和内存的requests与limits。这可能导致单个 Pod 消耗过多节点资源引发“邻居干扰”问题甚至导致节点不稳定。虽然这不直接导致数据泄露但属于影响集群稳定性和安全性的不良配置。5. 不必要的特权模式。默认开启privileged: true或挂载敏感主机路径如/,/var/run/docker.sock。这几乎是为容器逃逸铺平了道路在任何生产 Chart 中都应绝对避免作为默认值。3. 审计工具链与自动化检查方案手动检查几个 Chart 尚可但面对成规模的 Chart 仓库必须依靠自动化工具。我们的审计方案应该是一个组合拳集成到 CI/CD 流水线中实现“编码即审计”。3.1 静态分析工具选型与实践静态分析是在不实际部署 Chart 的情况下对values.yaml和 Chart 模板文件进行扫描。这是第一道也是最快的一道防线。首选工具CheckovCheckov 是一个用 Python 编写的策略即代码工具支持对基础设施即代码IaC的多类文件进行扫描对 Helm 有专门的支持。它内置了大量针对 Kubernetes 和 Helm 的安全策略。安装与基础扫描# 安装 pip install checkov # 针对单个Chart目录扫描 checkov -d ./path/to/your/chart --framework helm # 针对整个Charts目录递归扫描 checkov -d ./charts --framework helm关键策略解读Checkov 会报告类似[CKV_K8S_34]的策略ID。我们需要特别关注与values.yaml相关的CKV_K8S_36: “确保没有在环境变量中存储敏感信息”。它会检查env或extraEnv中是否有value字段直接包含了像password、secret、key等关键词的明文。CKV_K8S_37: “确保没有将镜像拉取密码存储在环境变量中”。类似上一条但针对镜像凭证。CKV_K8S_38: “确保没有在 Pod 定义中硬编码 Secrets”。它会寻找secretKeyRef的key对应的value是否被硬编码。CKV_K8S_39: “确保没有在容器命令或参数中硬编码 Secrets”。对于默认值Checkov 也有相关策略如检查容器是否以 root 运行CKV_K8S_23、是否设置了内存限制CKV_K8S_13等。集成到 CI/CD你可以在 GitLab CI、GitHub Actions 或 Jenkins Pipeline 中增加一个步骤在合并请求Merge Request时运行 Checkov。如果发现高危问题则令流水线失败阻止不安全的 Chart 变更被合并。进阶工具KubeLinterKubeLinter 是 Red Hat 开源的一个专注于 Kubernetes YAML 文件静态分析的工具。它需要先将 Helm Chart 渲染成最终的 Kubernetes 资源清单然后再进行分析。# 安装 go install golang.stackrox.io/kube-linter/cmd/kube-linterlatest # 渲染Chart并检查 helm template ./my-chart --values ./my-chart/values.yaml | kube-linter lint -KubeLinter 的检查项更偏向于 Kubernetes 资源的最佳实践对于检查渲染后的资源是否安全如是否设置了securityContext非常有效是 Checkov 的一个很好补充。3.2 动态渲染与深度模式匹配静态工具有时受限于模板语法无法洞察被渲染后的真实值。例如一个在values.yaml中定义为password: “{{ .Values.dbPassword }}”的字段静态工具可能无法判断dbPassword这个值最终来自哪里。因此我们需要结合动态渲染。方案Helm Template 自定义脚本核心思路是用真实的或模拟的values 文件去渲染 Chart然后对渲染输出进行扫描。准备测试 Values 文件创建一个专门用于审计的test-values.yaml。这个文件里你可以用一些明显的标记值来替换可能的敏感字段以验证它们是否会被渲染到最终输出中。同时你也可以用这个文件来测试“默认值”的安全性。# test-values.yaml global: # 用明显非生产值的标记来测试敏感字段泄露 secretPassword: “AUDIT_PLAINTEXT_PASSWORD_DO_NOT_USE” accessKey: “AUDIT_PLAINTEXT_ACCESS_KEY_DO_NOT_USE” database: # 测试默认值是否安全 enabled: true # 测试如果开启是否会有不安全配置渲染并扫描# 渲染Chart helm template my-release ./my-chart -f ./test-values.yaml rendered-manifests.yaml # 使用grep或yq进行模式匹配扫描 # 扫描是否出现了我们的标记密码 if grep -q “AUDIT_PLAINTEXT_PASSWORD_DO_NOT_USE” rendered-manifests.yaml; then echo “CRITICAL: Plaintext password found in rendered manifests!” exit 1 fi # 扫描已知的不安全模式如 emptyDir: {} if grep -A1 -B1 “emptyDir: {}” rendered-manifests.yaml; then echo “WARNING: emptyDir with no sizeLimit found, could lead to disk pressure.” fi # 使用yq更精细地解析YAML # 检查所有容器的securityContext yq eval ‘.spec.template.spec.containers[] | select(.securityContext null) | .name’ rendered-manifests.yaml构建自定义策略引擎对于复杂的策略可以编写 Python 脚本使用ruamel.yaml或PyYAML库解析渲染后的 YAML实现更复杂的逻辑判断。例如“如果 Service 类型是 LoadBalancer则必须同时存在指定的网络策略NetworkPolicy”。3.3 密钥管理集成检查最根本的解决方案是不让敏感信息进入values.yaml。审计方案必须包含对密钥管理集成方式的检查。正确模式验证在审计时我们需要验证 Chart 是否提供了通过 Kubernetes Secret 或外部 Secrets 管理工具如 HashiCorp Vault、AWS Secrets Manager、Azure Key Vault来注入敏感信息的正确途径。检查 values.yaml 设计查看values.yaml中关于数据库、API 等部分的配置项设计。好的设计应该类似database: # 方式一通过Secret名称和Key引用 existingSecret: “” # 用户需提供一个已存在的Secret名称 existingSecretKey: “password” # 方式二通过Vault等外部注入这里可能是一个注解annotation的配置 vault: enabled: false role: “” path: “”而坏的设计是database: password: “” # 这里期望用户直接填密码检查模板实现使用helm template渲染后查看生成的 Deployment 或 StatefulSet 配置。敏感信息应该通过valueFrom.secretKeyRef来引用。# 正确的渲染结果示例 env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: {{ .Values.database.existingSecret }} key: {{ .Values.database.existingSecretKey }}审计脚本可以检查渲染后的清单中是否还存在value: “明文密码”这样的字段。文档检查一个安全的 Chart其README.md或values.yaml顶部的注释应该明确说明如何管理 Secrets并警告不要将明文密码提交到版本库。审计时可以简单检查文档中是否包含“Secret”、“Vault”、“密码”等相关安全说明。4. 构建企业级 Helm Chart 安全审计流水线对于拥有大量 Charts 的团队或企业需要将上述点状的工具和检查整合成一条自动化、可重复、可追溯的审计流水线。这里我分享一个我们在实际环境中落地的方案。4.1 流水线阶段设计我们的流水线在 Chart 的代码仓库如 Git触发针对每次提交或合并请求运行。第一阶段预提交钩子Pre-commit Hook在开发者本地运行目的是尽早发现问题避免将低级错误提交到远程仓库。工具主要使用helm lint和yamllint。检查内容helm lint检查 Chart 的基本结构、模板语法是否正确。yamllint确保values.yaml、Chart.yaml等文件的 YAML 格式规范、缩进正确。可以配置规则禁止使用!!str等显式标签防止潜在的解析风险。实现在项目根目录配置.pre-commit-config.yaml开发者安装 pre-commit 工具后会自动在git commit前触发。第二阶段持续集成CI静态扫描当代码推送到远程仓库后CI 流水线如 GitHub Actions, GitLab CI被触发。基础合规扫描运行checkov -d . --framework helm。我们配置了一个基线策略集任何FAILED状态的高危HIGH或关键CRITICAL级别检查都会导致流水线失败。中低危问题会以警告形式输出要求开发者评估。自定义规则深度扫描调用我们编写的 Python 审计脚本。这个脚本会 a. 解析values.yaml使用正则表达式和关键词列表如passwdsecretkeytokencredential扫描所有键key和值value。对于值我们不仅匹配关键词还会评估其内容是否看起来像 Base64 编码、JWT 令牌或常见的密码模式。 b. 对values.yaml的默认值进行安全评估。我们维护一个“不安全默认值清单”例如service.type: LoadBalancer且没有关联的networkPolicysecurityContext为空资源limits未设置等。脚本会逐项核对。使用helm template配合一套标准的audit-values.yaml文件进行渲染然后对输出运行kube-linter和自定义的 YAML 分析脚本检查渲染后的实际资源是否安全。第三阶段动态验证与策略执行可选进阶对于非常重要的 Chart或在发布到生产 Helm 仓库之前可以增加一个动态验证阶段。在测试集群中干运行Dry-run使用helm install --dry-run在真实的测试 Kubernetes 集群中模拟安装。这可以验证 Chart 的依赖、钩子hooks等是否正常工作。使用 OPA/Gatekeeper 进行准入控制虽然这更多是集群层面的安全但可以确保即使不安全的 Chart 被部署也会被集群的准入控制器拦截。例如可以制定策略“所有 Pod 必须设置runAsNonRoot: true”。这样即使 Chart 的默认值不安全在部署到已启用该策略的集群时也会被拒绝。4.2 关键配置与策略文件示例自定义审计脚本的核心规则Python 伪代码逻辑import yaml import re def check_plaintext_secrets(values_content): high_risk_keywords [‘password’, ‘passwd’, ‘secret’, ‘token’, ‘key’, ‘credential’, ‘accesskey’, ‘secretkey’] high_risk_patterns [r’^sk_(live|test)_[a-zA-Z0-9]{20,}$‘, r’^[A-Za-z0-9/]{40,}{0,2}$‘] # 模拟Stripe密钥和长Base64 findings [] data yaml.safe_load(values_content) def iterate_dict(d, path“”): for k, v in d.items(): current_path f“{path}.{k}” if path else k # 检查键名 if any(keyword in k.lower() for keyword in high_risk_keywords): if v and isinstance(v, str) and v.strip(): # 如果键名可疑且值非空则标记为高危 findings.append({“level”: “HIGH”, “path”: current_path, “value_sample”: v[:50], “reason”: “Suspicious key name with non-empty value”}) # 检查值内容 if isinstance(v, str): for pattern in high_risk_patterns: if re.match(pattern, v): findings.append({“level”: “CRITICAL”, “path”: current_path, “reason”: f“Value matches sensitive pattern: {pattern}”}) # 简单启发式长而无空格、包含特殊字符的字符串可能是密码 if len(v) 12 and ‘ ‘ not in v and any(c in v for c in ‘!#$%^*()’): findings.append({“level”: “MEDIUM”, “path”: current_path, “reason”: “Value resembles a potential plaintext password”}) elif isinstance(v, dict): iterate_dict(v, current_path) elif isinstance(v, list): # 处理列表情况略 pass iterate_dict(data) return findingsGitLab CI.gitlab-ci.yml示例片段stages: - lint - security-scan helm-lint: stage: lint image: alpine/helm:latest script: - helm lint ./my-chart rules: - changes: - ‘my-chart/**’ checkov-scan: stage: security-scan image: bridgecrew/checkov:latest script: - checkov -d ./my-chart --framework helm --quiet --compact --soft-fail allow_failure: false # 高危问题导致失败 artifacts: reports: cyclonedx: gl-sast-report.json custom-audit: stage: security-scan image: python:3.9-slim script: - pip install pyyaml - python ./scripts/helm-values-audit.py ./my-chart/values.yaml rules: - changes: - ‘my-chart/values.yaml’ - ‘scripts/helm-values-audit.py’4.3 审计结果管理与闭环扫描出问题不是终点如何管理、跟踪和修复才是关键。标准化报告输出将所有工具Checkov, KubeLinter 自定义脚本的结果转换为统一的格式如 SARIF并上传到 CI 系统的安全仪表盘或专门的漏洞管理平台。问题分级与分流CRITICAL明文密码、密钥。立即阻塞合并必须修复。HIGH不安全的默认值如 root 运行、缺失网络策略。强烈建议在合并前修复。MEDIUM/LOW缺失资源限制、建议性配置。可作为技术债务记录要求在一定时限内修复。创建自动化工单当扫描发现新问题或历史问题未修复时可以自动在 Jira、GitLab Issue 等系统中创建工单分配给 Chart 的维护者。仪表盘与趋势分析定期生成审计报告展示整个 Chart 仓库的安全态势变化发现薄弱环节推动整体安全水平提升。5. 实操修复指南从“不安全”到“安全”的 Chart 改造假设我们现在审计一个名为myapp的 Chart发现了典型问题。让我们一步步修复它。5.1 修复敏感信息泄露问题原始不安全的values.yaml片段# values.yaml database: host: “localhost” port: 3306 name: “myappdb” username: “appuser” password: “ChangeMe123!” # 明文密码 redis: enabled: true password: “redispass” smtp: host: “smtp.gmail.com” port: 587 from: “alertsmycompany.com” username: “alertsmycompany.com” password: “emailpassword” # 另一个明文密码修复步骤移除明文密码改为 Secret 引用 首先修改values.yaml的设计移除密码字段改为接受 Secret 名称和键名。# values.yaml (修复后) database: host: “localhost” port: 3306 name: “myappdb” username: “appuser” # 不再直接指定密码 existingSecret: “” # 用户需在此填写已存在的Kubernetes Secret名称 existingSecretPasswordKey: “password” # Secret中密码对应的键默认为password redis: enabled: true # 同样改为引用Secret existingSecret: “” existingSecretPasswordKey: “redis-password” smtp: host: “smtp.gmail.com” port: 587 from: “alertsmycompany.com” # SMTP认证信息也通过Secret管理 existingSecret: “” existingSecretUsernameKey: “username” existingSecretPasswordKey: “password”修改 Chart 模板templates/deployment.yaml 在 Deployment 的环境变量部分使用secretKeyRef来引用这些值。# templates/deployment.yaml 片段 env: - name: DB_HOST value: {{ .Values.database.host | quote }} - name: DB_PORT value: {{ .Values.database.port | quote }} - name: DB_NAME value: {{ .Values.database.name | quote }} - name: DB_USER value: {{ .Values.database.username | quote }} - name: DB_PASSWORD valueFrom: secretKeyRef: name: {{ .Values.database.existingSecret | required “database.existingSecret is required!” | quote }} key: {{ .Values.database.existingSecretPasswordKey | default “password” | quote }} # 类似地处理 REDIS_PASSWORD 和 SMTP_USER/PASSWORD更新文档README.md 清晰说明如何使用。## 安全配置数据库密码 本 Chart 不再支持在 values.yaml 中直接设置密码。 1. 首先创建一个 Kubernetes Secret 来存储你的密码 bash kubectl create secret generic myapp-db-secret \ --from-literalpassword‘your-strong-password-here’ 2. 在 values.yaml 中配置 yaml database: existingSecret: “myapp-db-secret” existingSecretPasswordKey: “password” # 如果键名不是password请修改 5.2 加固安全默认值原始不安全的默认配置片段# values.yaml service: type: LoadBalancer # 默认对外暴露 port: 80 securityContext: {} # 空默认以root运行 resources: {} # 未设置资源限制 livenessProbe: httpGet: path: /health port: http initialDelaySeconds: 30 periodSeconds: 10修复步骤网络暴露最小化默认服务类型应为ClusterIP仅在需要时由用户覆盖为NodePort或LoadBalancer。service: type: ClusterIP # 默认仅在集群内访问 port: 80设置安全的 Pod 安全上下文提供遵循最佳实践的默认值。securityContext: runAsNonRoot: true runAsUser: 10001 # 使用一个明确的高位ID避免与系统用户冲突 runAsGroup: 10001 fsGroup: 10001 seccompProfile: type: RuntimeDefault podSecurityContext: fsGroupChangePolicy: “OnRootMismatch”设置合理的资源请求和限制根据应用特性设置默认值。例如对于一个简单的 Web 应用resources: requests: memory: “64Mi” cpu: “100m” limits: memory: “256Mi” cpu: “500m”配置就绪和存活探针确保探针路径正确初始延迟合理。livenessProbe: httpGet: path: /healthz # 使用明确的健康检查端点 port: http initialDelaySeconds: 15 # 根据应用启动时间调整 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3 readinessProbe: httpGet: path: /readyz port: http initialDelaySeconds: 5 periodSeconds: 5 timeoutSeconds: 3 failureThreshold: 1可选默认启用网络策略如果集群支持 NetworkPolicy可以提供一份默认的“拒绝所有入站允许必要出站”的策略模板并在values.yaml中默认启用。# values.yaml networkPolicy: enabled: true # 默认启用网络策略 allowedIngressPorts: - port: 80 protocol: TCP5.3 修复后的完整 values.yaml 示例片段将上述修复点整合一个更安全的values.yaml默认部分看起来是这样的# values.yaml (安全默认版) replicaCount: 1 image: repository: nginx tag: “stable” pullPolicy: IfNotPresent # 推荐使用镜像摘要而非标签提高确定性 # digest: sha256:abc123... imagePullSecrets: [] nameOverride: “” fullnameOverride: “” serviceAccount: create: true annotations: {} name: “” podSecurityContext: runAsNonRoot: true runAsUser: 10001 runAsGroup: 10001 fsGroup: 10001 seccompProfile: type: RuntimeDefault securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL service: type: ClusterIP port: 80 # 注释如需外部访问请将类型改为 NodePort 或 LoadBalancer # type: LoadBalancer # loadBalancerIP: “” ingress: enabled: false className: “” annotations: {} hosts: - host: chart-example.local paths: - path: / pathType: ImplementationSpecific tls: [] resources: requests: memory: “64Mi” cpu: “100m” limits: memory: “256Mi” cpu: “500m” autoscaling: enabled: false minReplicas: 1 maxReplicas: 10 targetCPUUtilizationPercentage: 80 # targetMemoryUtilizationPercentage: 80 database: host: “localhost” port: 3306 name: “myappdb” username: “appuser” # 必须通过Secret提供密码 existingSecret: “” existingSecretPasswordKey: “password” ## 其他配置...经过这样的改造这个 Chart 的默认配置就安全多了同时也清晰地引导用户去使用正确、安全的方式来管理敏感信息。这不仅仅是修复了一个文件更是将一种安全至上的文化注入到了你的部署资产中。