K8s 中 RBAC 的常见错误及最佳实践

阿里云国内75折回扣微信号：monov8

阿里云国际，腾讯云国际，低至75折。AWS 93折免费开户实名账号代冲值优惠多多微信号：monov8 飞机：@monov6

引言

之前的文章中我们详细介绍了 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则该组的成员可以绕过它。