引言

之前的文章中，我们详细介绍了 K8s 中 RBAC 的概念和使用，今天我们继续来聊一下关于 K8s 中 RBAC 的常见错误和使用中的最佳实践。

Kubernetes API 提供对敏感数据的访问，包括部署详细信息、持久存储设置和secret。 多年来，Kubernetes 社区为 Kubernetes API 提供了多项重要的安全功能，包括基于角色的访问控制 (RBAC)。

RBAC 让您控制谁有权访问哪个 API 资源，从而帮助保护 Kubernetes 集群。但一些错误配置可能导致访问控制薄弱，无法实现最小特权原则。

为什么RBAC很重要？

RBAC 机制提供对应用程序用户权限的细粒度控制。 它通过将功能分配给需要它的用户来避免出现拥有过多权限的帐户。

为用户提供过多的访问权限会增加凭据被盗或丢失的风险，并使组织面临内部威胁。 例如，开发人员不应具有删除生产部署的权限。 即使您信任组织中的每一位员工，恶意的外部人员也可以通过社会工程或网络钓鱼攻击获得对特权帐户的控制权。

Kubernetes 中的 RBAC 允许您创建策略来阻止用户执行管理员级别的操作，例如删除 pod。

在 Kubernetes 项目中使用 RBAC 的方法有多种：

• 集成到现有的企业解决方案中。RBAC 解决方案通过中央角色目录管理对受保护资源的访问。 用户可以在 Kubernetes pod 中验证他们的身份和访问资源，通常使用单点登录 (SSO) 解决方案。

• 在集群内实现用户访问的细粒度控制，您可以使用 RBAC 来控制哪些用户有权访问 Kubernetes 集群以及对项目各个部分的访问级别。 这种细粒度的控制允许团队成员仅访问他们需要的特定资源。

4 个常见的 RBAC 配置错误

以下是基于角色的访问控制(RBAC)的一些常见配置问题。

1.从ABAC升级

如果您的集群运行的是较旧的 Kubernetes 版本，它可能具有较弱的 ABAC 策略，例如对服务帐户的完整 API 访问权限。

默认的 RBAC 策略向控制平面上的一组节点、控制器和组件授予范围内的权限。 不过，它不会授予对 kube-system 命名空间之外的任何服务帐户的访问权限（授予每个经过身份验证的用户的发现权限除外）。

虽然这种方法是安全的，但它可能会破坏期望自动接收 API 权限的现有工作负载。 您可以通过运行两个鉴权方（ABAC 和 RBAC）并使用现有的 ABAC 策略指定一个策略文件来管理向 RBAC 的转换：

--authorization-mode=...,RBAC,ABAC

--authorization-policy-file=mypolicy.json

以下是命令参数的详细解释：

• 如果像 Node 这样的早期授权者拒绝请求，RBAC 授权者将尝试授权相关的 API 请求。

• 如果 RBAC 授权方拒绝 API 请求，ABAC 授权方将运行。

• 系统将允许其中一个策略（ABAC 或 RBAC）授权的任何请求，即使另一个组件不允许。

当你运行 kube-apiserver 的日志级别为 5 或更高的 RBAC 策略时，你可以在 API 服务器日志中查看 RBAC 前缀的 RBAC 拒绝的请求。 此信息对于确定每个服务帐户、用户和组的适当角色很有用。

在您向每个服务帐户授予角色并且工作负载在服务器日志中没有 RBAC 拒绝的情况下运行后，可以安全地删除您的 ABAC 授权方。

2.角色聚合使用不当

角色聚合在 Kubernetes 1.9 及更高版本中可用，允许您通过将它们组合到定义的角色中来简化授予权限。 但是，如果您不仔细审查每个角色聚合，它们可能会修改角色的预期用途。 例如，一个

system:view 角色可能会不正确地组合违反角色目的的规则，例如使用允许用户修改集群的动词。

3.授予重复的角色

角色定义可以重叠并以多种方式为用户提供相同级别的访问权限。 有时，角色可能有意重叠，管理员有意授予重复权限。 但是，此配置很复杂，并且很难理解哪些用户拥有每个访问权限。

另一个问题是，当管理员没有意识到不同的角色绑定提供相同的访问权限时，撤销访问权限会更加困难。

4.保留未使用的角色

如果您创建一个角色但不将其授予任何用户，这会增加管理 RBAC 策略的复杂性而不会提高安全性。 同样，仅与已删除用户相关的角色（例如已删除命名空间中的服务帐户或前雇员）会产生过多噪音，从而模糊相关配置。 删除非活动或未使用的角色通常是安全的，让您可以专注于活动角色。

Kubernetes RBAC 最佳实践

最小权限原则

应为用户和服务帐户(SA)分配执行其角色所需的最少 RBAC 权限。 以下是实现最小特权原则的一些一般性建议：

使用 RoleBindings 而不是 ClusterRoleBindings 在命名空间级别而不是整个集群分配权限。

避免提供通配符权限，尤其是对所有资源。 Kubernetes 是一个可扩展的系统，因此提供通配符访问权限可以授予对现有对象类型以及当前不存在的未来对象类型的权限。

不允许管理员使用集群管理员帐户。 相反，将访问权限授予权限较低的帐户以执行日常管理任务。 这将防止对集群资源的意外修改，并可以减少内部威胁的影响。

不要将用户添加到 system:masters 组——属于该组的任何用户都会绕过所有 RBAC 权限检查，并且始终具有不受限制的超级用户访问权限。 无法通过删除 RoleBindings 或 ClusterRoleBindings 来撤消此操作。 此外，如果集群使用身份验证 webhook，则该组的成员可以绕过它。

最小化特权令牌的分发

理想情况下，您不应将具有强权限的服务帐户分配给您的 pod。 如果您的工作负载需要强权限，请考虑以下事项：

限制运行敏感工作负载的 pod 的节点数量——确保所有 DaemonSet 都是真正需要的，并以最少的权限运行，以限制容器逃逸的爆炸半径。

不要在不受信任或公共 pod 旁边运行敏感 pod——您可以使用 taints、tolerations、NodeAffinity 或 PodAntiAffinity 来实现这一点。 特别注意不受信任的 pod 不符合敏感 pod 的安全标准的情况。

集群管理员角色

内置的集群管理员角色授予对您的集群几乎无限制的访问权限。 在从遗留 ABAC 控制器迁移到 RBAC 的过程中，一些管理员和用户忽略了文档中的警告，并从旧的 ABAC 配置中复制了广泛的集群管理员权限。 确定这是否在您的集群中完成并删除此权限。

如果用户或组被定期授予集群管理员权限，则帐户泄露或错误可能会产生危险的深远影响。 服务帐户通常不需要此访问权限。 在任何一种情况下，您都应该创建一个更细化的角色或集群角色，并将其仅授予需要它的特定用户。

关于HummerRisk

HummerRisk 是开源的云原生安全平台，以非侵入的方式解决云原生的安全和治理问题，核心能力包括混合云的安全治理和K8S容器云安全检测。

Github 地址：https://github.com/HummerRisk/HummerRisk

Gitee 地址：https://gitee.com/hummercloud/HummerRisk