大家好！您正在运营Kubernetes集群吗？如果是，那么“安全”无疑是您绝不能忽视的最重要主题。特别是在多个用户和工作负载共存的环境中，控制谁可以做什么的RBAC（基于角色的访问控制）可以说是安全的核心中的核心。🚀
但是，在RBAC设置时，您是否曾想过“随便给个cluster-admin权限就行了吧？”而草草了事？错误的RBAC配置可能成为将整个集群拱手让给攻击者的捷径。
今天，我们将为集群运营商，深入剖析安全高效RBAC设计的核心原则和最佳实践，以及我们容易无意中忽略的权限提升风险！
1. 基本原则：这些务必遵守！ 🙏
安全的RBAC设计始于几个基本原则。即使看起来复杂，只要遵循这些原则，就能大大提高安全级别。
最小权限原则 (Least Privilege)
这是最重要和最基本的原则。无论是用户还是服务账户(Service Account)，都必须只授予执行其角色所需的最小权限。这就像只给所需房间的钥匙，而不是一整串钥匙。
- ✅ 按命名空间(Namespace)单位授予权限。 不要使用适用于整个集群的ClusterRoleBinding，而应使用仅在特定命名空间内有效的RoleBinding。这样可以明确限制特定用户的活动范围。
- ❌ 避免使用通配符(“)权限。 诸如resources: [“”] 的设置非常危险。因为它不仅会自动授予集群中所有现有资源的权限，还会授予未来可能添加的新CRD(Custom Resource Definition)的权限。
- 👨✈️ 谨慎使用cluster-admin角色。 作为集群管理员，平时所有操作都使用cluster-admin账户是危险的。因为这可能导致意外修改或删除重要资源。使用低权限账户，只在必要时使用impersonate（模拟）功能更为安全。
- 🚫 不要将用户添加到system:masters组！ 此组的成员将成为绕过所有RBAC权限检查的超级用户。一旦授予，即使删除RoleBinding也无法撤销权限，因此绝不能使用。
最小化特权令牌(Privileged Token)分发
将具有强大权限的服务账户令牌挂载到Pod中，可能是安全事件的起点。
- 需要强大权限的Pod只在特定节点上运行。 使用Taints或NodeAffinity等方式，隔离关键Pod，使其不与不可信的其他Pod一起运行。
- 禁用服务账户令牌的自动挂载。 在Pod规范中设置automountServiceAccountToken: false可以阻止不必要的令牌挂载。最好只为确实需要令牌的工作负载手动挂载。
定期审查
RBAC设置并非一劳永逸。必须定期审查是否存在不必要的权限，以及已删除用户的权限是否仍然存在。如果攻击者创建了与已删除用户同名的账户，他们可能会继承之前用户的所有权限。
2. 不知不觉中权限提升？务必了解的风险点 🚨
您认为“这点权限应该没问题吧？”的设置，可能会导致严重的权限提升(Privilege Escalation)。以下各项尤其需要仔细检查。
Secret list, watch权限的陷阱
get权限可以读取Secret的内容，这一点大家都知道。但是，您知道list和watch权限同样可以暴露Secret的所有内容吗？执行kubectl get secrets -A -o yaml命令时，所有Secret的内容（data字段）都会直接输出。
工作负载创建(create)权限的强大之处
创建Pod或Deployment等工作负载的权限比想象中要强大得多。
- 可以挂载该命名空间下的所有Secret、ConfigMap到Pod中，窃取其内容。
- 可以使用该命名空间下的任何服务账户运行Pod，从而获取该服务账户的权限。
- 如果允许privileged: true设置，甚至可以窃取节点(Host)的权限。
PersistentVolume创建权限
如果用户可以直接创建PersistentVolume，他们可以创建hostPath卷来访问节点的 文件系统。这会导致容器逃逸和节点控制，是一个非常严重的安全问题。
危险动词(Verb)四兄弟: escalate, bind, impersonate, proxy
- escalate: 允许创建比自身拥有更高权限的Role，顾名思义就是“权限提升”动词。
- bind: 允许将包含自身不具备权限的Role绑定给其他用户。也就是说，可以给别人比自己更大的权限。
- impersonate: “模拟”其他用户，从而获取该用户的所有权限。
- nodes/proxy: 如果有访问节点代理子资源的权限，可以直接调用Kubelet API，在所有节点上的Pod中执行命令。这会绕过RBAC检查和审计日志。
其他危险因素
- CSR创建/批准: 可以创建新的客户端证书，以获取对集群的额外访问权限。
- serviceaccounts/token创建: 可以请求现有服务账户的令牌，从而获取该账户的权限。
- Admission Webhook控制: 这是一个强大的权限，可以读取或篡改集群中创建的所有对象。
- 命名空间patch权限: 可以修改命名空间的标签，从而绕过Pod Security Admission策略或更改NetworkPolicy规则。
3. 服务拒绝(DoS)攻击的风险 😫
如果用户有权在集群中创建对象，无论有意无意，都可能创建大量或超大对象，导致etcd瘫痪。这可能导致整个集群故障，构成服务拒绝攻击。
✅ 解决方案: 使用ResourceQuotas限制用户在命名空间内可以创建的对象数量和大小。
总结
Kubernetes RBAC强大而复杂，一个小小的失误都可能导致重大的安全事故。请根据今天探讨的最佳实践，再次检查您的集群RBAC设置。
始终牢记“最小权限原则”，并养成定期检查是否存在不必要授予的危险权限的习惯，是构建安全集群的第一步。
发表回复