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。
具体步骤:
分析应用需求: 首先,明确每个 Service Account 真正需要访问哪些 Secret。详细记录每个应用需要哪些凭据以及原因。
创建 Role 和 RoleBinding:
- 针对每个应用(或一组具有相同权限需求的应用),创建一个 Role,明确指定该 Role 允许对哪些 Secret 执行哪些操作(通常是
get和list)。 - 使用 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- 针对每个应用(或一组具有相同权限需求的应用),创建一个 Role,明确指定该 Role 允许对哪些 Secret 执行哪些操作(通常是
使用 Pod Security Admission (PSA) 限制权限:
- PSA通过在namespace上打标签,可以限制pod的权限,使其符合安全标准。例如,可以限制pod使用 hostNetwork, privileged containers 等高危权限。
Default Deny 原则: 确保集群中存在一个默认的 deny all 的策略,防止未明确授权的 Service Account 访问 Secret。
定期审计: 定期审查 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 集群的安全性。