WEBKT

Kubernetes Secret 权限控制:RBAC 实践与合规

213 0 0 0

在遵循 CIS Kubernetes 基准测试时,Secret 的默认访问权限确实是一个需要关注的安全风险点。为了解决 Service Account 对 Secret 的访问权限过于宽泛的问题,同时满足审计和合规性要求,以下提供一种可行的方案:

核心思路: 使用 RBAC (Role-Based Access Control) 精细化控制 Service Account 对 Secret 的访问权限,并结合 Namespace 和 Pod Security Policies (PSP) 进一步加固安全。 由于PSP 已被 Pod Security Admission (PSA) 替代,推荐使用 PSA。

具体步骤:

  1. 分析应用需求: 首先,明确每个 Service Account 真正需要访问哪些 Secret。详细记录每个应用需要哪些凭据以及原因。

  2. 创建 Role 和 RoleBinding:

    • 针对每个应用(或一组具有相同权限需求的应用),创建一个 Role,明确指定该 Role 允许对哪些 Secret 执行哪些操作(通常是 getlist)。
    • 使用 RoleBinding 将该 Role 绑定到对应的 Service Account 上。RoleBinding 可以限定在特定的 Namespace 内生效,进一步缩小权限范围。

    示例:

    假设有一个名为 my-app 的应用,它需要访问 my-secret 这个 Secret。

    • Role (my-app-secret-reader-role.yaml):
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: my-app-secret-reader
    rules:
    - apiGroups: [""]
      resources: ["secrets"]
      resourceNames: ["my-secret"] # 指定 Secret 名称
      verbs: ["get", "list"]
    
    • RoleBinding (my-app-secret-reader-rolebinding.yaml):
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: my-app-secret-reader-binding
    subjects:
    - kind: ServiceAccount
      name: my-app-sa # 你的 Service Account 名称
      namespace: my-namespace # 你的 Namespace 名称
    roleRef:
      kind: Role
      name: my-app-secret-reader
      apiGroup: rbac.authorization.k8s.io
    
  3. 使用 Pod Security Admission (PSA) 限制权限:

    • PSA通过在namespace上打标签,可以限制pod的权限,使其符合安全标准。例如,可以限制pod使用 hostNetwork, privileged containers 等高危权限。
  4. Default Deny 原则: 确保集群中存在一个默认的 deny all 的策略,防止未明确授权的 Service Account 访问 Secret。

  5. 定期审计: 定期审查 RBAC 配置,确认权限设置是否仍然符合应用需求。可以使用工具自动扫描集群中的 RBAC 配置,并生成报告。

满足审计和合规性要求:

  • 清晰的 RBAC 配置: RBAC 配置本身就是一种权限控制的记录。通过查看 Role 和 RoleBinding 的定义,可以清晰地了解每个 Service Account 拥有哪些 Secret 的访问权限。
  • 审计日志: 启用 Kubernetes 的审计日志,记录所有对 Secret 的访问请求。通过分析审计日志,可以追踪哪些 Service Account 访问了哪些 Secret,以及访问的时间和结果。
  • 文档记录: 编写详细的文档,记录每个 Service Account 的权限需求、RBAC 配置以及审计流程。

额外建议:

  • Secret 存储加密: 启用 Kubernetes Secret 的静态加密,防止 Secret 数据在 etcd 中被未经授权访问。
  • 使用 Secret 管理工具: 考虑使用 Vault 等 Secret 管理工具,集中管理和控制 Secret 的访问。
  • 最小权限原则: 始终坚持最小权限原则,只授予 Service Account 必要的 Secret 访问权限。

通过以上步骤,可以有效地限制 Service Account 对 Secret 的访问权限,同时满足审计和合规性要求,确保 Kubernetes 集群的安全性。

K8s安全侠 KubernetesSecretRBAC

评论点评