22、Helm安全考量与安全图表开发指南

Helm安全考量与安全图表开发指南

在使用Helm进行Kubernetes应用部署时，安全是至关重要的。本文将详细介绍Helm的安全考量，包括图表验证、安全图表开发、资源限制设置、秘密处理以及基于角色的访问控制（RBAC）配置等方面。

1. 验证Helm图表

在安装Helm图表之前，用户可以使用 helm verify 命令来验证图表的数据来源和完整性。此命令针对本地下载的 .tgz 图表存档和 .tgz.prov 来源文件运行。

示例命令如下，假设公钥已导入到名为 ~/.gnupg/pubring.gpg 的密钥环中：

$ helm verify --keyring ~/.gnupg/pubring.gpg guestbook-1.0.0.tgz

如果验证成功，将不会显示输出；否则，将返回错误消息。验证失败可能有多种原因，包括：
- .tgz 和 .tgz.prov 文件不在同一目录中。
- .tgz.prov 文件已损坏。
- 文件哈希不匹配，表明完整性受损。
- 用于解密签名的公钥与最初用于加密的私钥不匹配。

由于 helm verify 命令设计用于本地下载的图表，用户可能会发现使用 helm install --verify 命令更好，该命令可以在一个命令中完成验证和安装，前提是 .tgz 和 .tgz.prov 文件都可以从图表仓库下载。示例命令如下：

$ helm install my-guestbook $CHART_REPO/guestbook --verify --keyring ~/.gnupg/pubring.gpg

2. 开发安全的Helm图表

在开发Helm图表时，除了数据来源和完整性，还需要考虑其他安全问题。以下是一些关键的安全方面：

2.1 使用安全的镜像

Helm和Kubernetes的目标是部署容器镜像，因此镜像本身是一个主要的安全问题。图表开发者应了解镜像标签和镜像摘要之间的区别。

• 标签 ：是对给定镜像的人类可读引用，但不能保证标签内容始终不变。镜像所有者可能会使用相同的标签提供更新的镜像，这可能会导致运行时执行不同的底层镜像，从而引入回归问题。
• 摘要 ：是镜像的计算SHA - 256值，提供了对精确镜像的不可变标识符，并允许容器运行时验证从远程镜像注册表检索的镜像是否包含预期内容。这消除了部署包含意外回归的镜像的风险，也可以避免中间人攻击。

例如，在图表模板中，应使用摘要引用镜像，而不是标签：

# 使用标签引用
quay.io/bitnami/redis:5.0.9
# 使用摘要引用
quay.io/bitnami/redissha256:70b816f2127afb5d4af7ec9d6e8636b2f0f973a3cd8dda7032f9dcffa38ba11f

随着时间的推移，与镜像关联的标签或摘要可能会变得不安全，因为镜像中包含的软件包或操作系统版本可能会出现漏洞。可以通过以下方式确定镜像的漏洞：
- 利用镜像所属注册表的原生功能，如Quay、Nexus和Artifactory等容器注册表具有镜像漏洞扫描功能。
- 使用其他工具，如Clair、Anchore、Vuls和OpenSCAP。

当镜像注册表或独立扫描工具报告镜像存在漏洞时，应立即更新图表中的镜像版本。为了简化容器镜像更新过程，可以定期检查镜像更新，并指定只能从受信任的注册表获取镜像。

此外，应避免部署需要提升权限或功能的镜像。功能用于为进程提供部分root权限，如 NET_ADMIN 允许进程执行网络相关操作， SYS_TIME 允许进程修改系统时钟。运行以root身份运行的容器会使容器获得所有功能，应尽可能限制。

2.2 设置资源限制

Pod使用其底层节点的资源，如果没有适当的默认设置，Pod可能会耗尽节点资源，导致CPU节流和Pod驱逐等问题。因此，图表开发者应关注在Helm图表或Kubernetes集群中设置合理的默认资源限制。

可以在 values.yaml 文件中设置资源字段的默认值，示例如下：

resources:
  limits:
    cpu: 500m
    memory: 2Gi

此默认值将Pod的CPU限制设置为500m，内存限制设置为2Gi，防止Pod耗尽节点资源，同时为应用程序所需的资源量提供建议值。用户可以根据需要覆盖这些资源限制。

除了在 values.yaml 文件中设置默认资源限制，还可以在Kubernetes命名空间中设置限制范围（LimitRange）和资源配额（ResourceQuota）。

• 限制范围 ：用于确定容器在命名空间内允许使用的资源数量，并为未定义资源限制的容器设置默认资源限制。示例如下：

apiVersion: v1
kind: LimitRange
metadata:
  name: limits-per-container
spec:
  limits:
    - max:
        cpu: 1
        memory: 4Gi
      default:
        cpu: 500m
        memory: 2Gi
      type: Container

• 资源配额 ：用于定义命名空间可以使用的最大资源数量。示例如下：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: pod-and-pvc-quota
spec:
  hard:
    limits.cpu: '4'
    limits.memory: 8Gi
    requests.storage: 20Gi

通过设置合理的默认资源限制以及使用LimitRange和ResourceQuota，可以确保Helm图表的用户不会耗尽集群资源，避免造成中断或停机。

3. 处理Helm图表中的秘密

在处理Helm图表时，秘密处理是一个常见问题。图表开发者应避免为密码等秘密值提供默认值，而是要求用户提供明确的值，可以使用 required 函数实现。

当用户在图表安装期间提供秘密时，应将该值保存在Kubernetes的 Secret 中，而不是 ConfigMap 。 ConfigMap 以明文显示值，不适合包含凭据或其他秘密值；而 Secret 通过Base64编码其内容提供混淆，并允许将其内容作为tmpfs挂载到Pod中。

图表用户在提供秘密时应确保安全。常见的提供值的方式是使用 --values 标志，但在处理秘密值时要谨慎，避免将包含秘密的values文件提交到git仓库或其他公共位置。可以使用 --set 标志从本地命令行内联传递秘密，或者使用加密工具（如GPG或Sops）加密包含秘密的values文件。

以下是Sops加密文件中的秘密键值对示例：

password:ENC[AES256GCM,data:xhdUx7DVUG8bitGnqjGvPMygpw==, 
iv:3LR9KcttchCvZNpRKqE5LcXRyWD1I00v2kEAIl1ttco=, 
tag:9HEwxhT9s1pxo9lg19wyNg==,type:str]

4. 配置基于角色的访问控制（RBAC）规则

在Kubernetes中，经过身份验证的用户执行操作的能力由一组RBAC策略控制。在使用Helm时，需要考虑两个因素：
- 安装Helm图表的用户。
- 运行工作负载的Pod关联的服务账户。

默认情况下，用户和服务账户在Kubernetes集群中的权限有限。可以通过使用作用于单个命名空间的角色或作用于集群级别的集群角色来授予额外权限，并使用角色绑定或集群角色绑定将其关联到用户或服务账户。

为了最小化授予应用程序的访问级别，可以创建自定义策略。例如，要允许经过身份验证的用户在命名空间内查看Pod，可以按照以下步骤配置RBAC规则：

1. 启动Minikube（如果在本地工作站运行）：

$ minikube start

2. 创建新的命名空间 chapter9 ：

$ kubectl create ns chapter9

3. 创建新角色 guestbook-pod-viewer ：

$ kubectl create role guestbook-pod-viewer --resource=pods --verb=get,list -n chapter9

4. 创建新的服务账户 guestbook ：

$ kubectl create sa guestbook -n chapter9

5. 创建角色绑定 guestbook-pod-viewers ：

$ kubectl create rolebinding guestbook-pod-viewers --role=guestbook-pod-viewer --serviceaccount=chapter9:guestbook -n chapter9

6. 安装guestbook Helm图表：

$ helm install my-guestbook Learn-Helm/helm-charts/charts/guestbook \
--set serviceAccount.name=guestbook \
--set serviceAccount.create=false \
-n chapter9

7. 验证 guestbook 服务账户是否有权限查询所有Pod：

$ kubectl auth can-i list pods --as=system:serviceaccount:chapter9:guestbook -n chapter9

通过以上步骤，可以确保Helm图表的安全使用和部署，保护Kubernetes集群免受潜在的安全威胁。

以下是一个简单的mermaid流程图，展示了Helm图表安全部署的主要步骤：

graph LR
    A[验证Helm图表] --> B[开发安全图表]
    B --> B1[使用安全镜像]
    B --> B2[设置资源限制]
    B --> B3[处理秘密]
    B --> B4[配置RBAC规则]
    B1 --> B11[使用摘要引用镜像]
    B1 --> B12[检查镜像漏洞]
    B2 --> B21[设置values.yaml默认值]
    B2 --> B22[使用LimitRange和ResourceQuota]
    B3 --> B31[使用Secret保存秘密]
    B3 --> B32[安全传递秘密]
    B4 --> B41[创建角色和角色绑定]
    B4 --> B42[验证权限]

总之，在使用Helm进行Kubernetes应用部署时，要从多个方面考虑安全问题，确保部署的应用程序和集群的安全性。通过遵循上述最佳实践，可以有效降低安全风险，提高系统的稳定性和可靠性。

Helm安全考量与安全图表开发指南

5. 安全考量总结与对比

为了更清晰地理解Helm安全各个方面的要点，下面通过表格的形式对关键内容进行总结和对比：
| 安全方面 | 具体内容 | 注意事项 |
| ---- | ---- | ---- |
| 图表验证 | 使用 helm verify 或 helm install --verify 命令验证图表数据来源和完整性 | .tgz 和 .tgz.prov 文件需在同一目录，公钥和私钥需匹配 |
| 安全镜像 | 优先使用镜像摘要，定期检查镜像漏洞，避免提升权限镜像 | 从受信任注册表获取镜像，及时更新有漏洞的镜像 |
| 资源限制 | 在 values.yaml 设置默认值，使用LimitRange和ResourceQuota | 防止Pod耗尽节点资源 |
| 秘密处理 | 使用 required 函数，将秘密保存在Secret中，安全传递秘密 | 避免秘密值暴露，可使用加密工具 |
| RBAC配置 | 创建角色和角色绑定，遵循最小权限原则 | 验证服务账户权限 |

6. 安全操作流程梳理

以下是一个mermaid流程图，进一步梳理Helm图表安全部署的详细操作流程：

graph TD
    A[开始] --> B[验证Helm图表]
    B --> C{验证是否成功}
    C -- 是 --> D[开发安全图表]
    C -- 否 --> E[检查验证失败原因并解决]
    E --> B
    D --> F[使用安全镜像]
    F --> F1[选择摘要引用镜像]
    F --> F2[定期检查镜像漏洞]
    F2 --> F3{是否有漏洞}
    F3 -- 是 --> F4[更新镜像版本]
    F3 -- 否 --> G[设置资源限制]
    F4 --> G
    G --> G1[在values.yaml设置默认值]
    G --> G2[使用LimitRange和ResourceQuota]
    G2 --> H[处理秘密]
    H --> H1[使用required函数]
    H --> H2[将秘密保存在Secret中]
    H --> H3[安全传递秘密]
    H3 --> I[配置RBAC规则]
    I --> I1[创建角色和角色绑定]
    I --> I2[验证服务账户权限]
    I2 --> J[结束]

7. 常见问题及解决方案

在实际使用Helm进行安全部署过程中，可能会遇到一些常见问题，以下是对应的解决方案：
- 图表验证失败 ：
- 问题表现：执行 helm verify 命令返回错误消息。
- 可能原因： .tgz 和 .tgz.prov 文件不在同一目录、 .tgz.prov 文件损坏、文件哈希不匹配、公钥和私钥不匹配。
- 解决方案：检查文件位置，重新下载 .tgz.prov 文件，确保公钥和私钥正确。
- 镜像漏洞处理不及时 ：
- 问题表现：镜像存在已知漏洞但未及时更新。
- 可能原因：未定期检查镜像漏洞，未设置从受信任注册表获取镜像。
- 解决方案：建立定期检查机制，指定受信任的镜像注册表。
- 资源耗尽问题 ：
- 问题表现：Pod耗尽节点资源，导致CPU节流和Pod驱逐。
- 可能原因： values.yaml 默认值设置不合理，未使用LimitRange和ResourceQuota。
- 解决方案：调整 values.yaml 中的资源默认值，创建LimitRange和ResourceQuota对象。
- 秘密值暴露风险 ：
- 问题表现：包含秘密的values文件被提交到公共位置。
- 可能原因：使用 --values 标志传递秘密值时未注意安全。
- 解决方案：使用 --set 标志内联传递秘密，或使用加密工具加密values文件。
- RBAC权限配置错误 ：
- 问题表现：服务账户没有所需的权限。
- 可能原因：角色和角色绑定配置错误。
- 解决方案：检查角色和角色绑定的配置，使用 kubectl auth can - i 命令验证权限。

8. 持续安全保障建议

为了持续保障Helm部署的安全性，建议采取以下措施：
- 定期审查 ：定期对Helm图表的安全配置进行审查，包括镜像版本、资源限制、秘密处理和RBAC规则等。
- 培训与教育 ：对团队成员进行Helm安全相关的培训，提高安全意识和操作技能。
- 监控与预警 ：建立监控机制，实时监测镜像漏洞、资源使用情况和权限变更等，及时发出预警。
- 更新与升级 ：及时更新Helm版本和相关工具，以获取最新的安全特性和修复。

通过以上全面的安全考量和操作实践，可以确保在使用Helm进行Kubernetes应用部署时，最大程度地降低安全风险，保障系统的稳定运行。在实际应用中，要根据具体的业务需求和环境特点，灵活运用这些安全策略，不断优化安全措施。