本文为译文，原文链接：https://containerjournal.com/features/understanding-role-based-access-control-in-kubernetes/
了解授权对于了解基于角色的访问控制（RBAC）如何保护Kubernetes至关重要。无论您是开始了解Kubernetes的安全专业人员，还是使用它的工程师建筑，了解管理Kubernetes的基本系统和规则都很重要。
Kubernetes中的RBAC
虽然Kubernetes在技术上支持其他授权模式，但RBAC往往是当今访问控制的事实模式。了解它的工作原理将有助于用户配置团队所需的权限，并避免不必要地将权限分发给那些不需要它们的人。当安全专业人士考虑通过执行最低权限的最佳实践来管理Kubernetes的风险时，这些概念特别有用。
在深入了解细节之前，有几个核心设计原则值得一提：
- 默认情况下，访问被拒绝，只能添加权限。
- 用户不能为他们自己没有权限的事情授予权限。这是一个内置的机制，可以防止权限提升。
- 由于Kubernetes依赖于与外部身份提供商（如身份和访问管理（IAM）系统）的信任关系，因此没有“Kubernetes用户”这种关系。外部身份提供商负责管理用户，而Kubernetes只是确保用户可以证明他们是他们声称的那个人，并检查他们是否有权执行所需的操作。
RBAC配置的资源类型
与所有Kubernetes一样，配置RBAC策略只是创建正确资源的问题。在这种情况下，有四种资源类型控制授权：角色、ClusterRoles、RoleBindings和ClusterRoleBindings。虽然其中一些听起来可能相似，但存在重要的差异。Roles和RoleBindings授予单个命名空间范围内的访问权限，而ClusterRoles和ClusterRoleBindings通常用于在整个集群中提供访问权限（尽管有例外）。
定义角色和角色绑定就像在YAML中制作清单一样简单。这些资源的模式在Kubernetes官方文档中得到了很好的记录，但了解它在实践中是如何运作的很重要。以下是一些例子来帮助说明这个过程：
示例一：授予一个命名空间的读取Pod的访问权限
让我们从一个简单的示例开始——管理员需要授予“Dave”访问权限以获取和列出单个命名空间中的 pod。他们将首先创建一个看起来像这样的 Role 和 RoleBinding：
他们创建了两个资源：一个名为pod-viewer的角色和一个名为pod-viewers的角色绑定。该角色定义了可以针对哪种“资源”采取哪些行动（又称“动词”）。RoleBinding是将主体（在这种情况下，只有Dave）映射到该角色。在本例中，Dave只能在“foo”命名空间中获取和列出pod。他无法与“bar”命名空间中的任何资源进行交互。
示例二：授予全集群访问权限
现在想象一下，管理员希望Dave能够检查集群中所有命名空间中的所有pod。实现这一目标的一种方法是使用ClusterRole和ClusterRoleBinding，如下所示：
乍一看，这可能看起来与之前的示例相似，但现在Dave的访问权限不仅限于“foo”命名空间。由于这导致访问范围更广、限制更少，安全分析师和工程师将正确地指出，在整个集群中授予访问权限是有风险的。一般来说，重要的是要避免过度配置权限。鉴于当今攻击者参与身份盗窃的频率，如果身份被盗，过度配置可能会导致严重损害。
示例三：将ClusterRoles绑定到特定的命名空间
一些组织有很多用户和很多命名空间。为了保持操作平稳进行，他们可能希望为用户各自的命名空间授予一组通用权限。幸运的是，这并不意味着他们需要为每个命名空间创建一个角色资源。事实上，他们可以使用RoleBinding将ClusterRole绑定到单个命名空间：
在本例中，他们使用命名空间的RoleBinding将Dave绑定到“foo”命名空间中的pod-viewer角色——这意味着他无法访问其他命名空间中的pod。这在功能上等同于第一个示例，“pod-viewer”角色可以在多个命名空间之间重复使用。现在有一个集中的地方来管理一组通用权限，这些权限可以在广泛的命名空间中使用，而无需授予用户对所有命名空间的访问权限。
不是Kubernetes的一切都是直观的
这些基本提示可以让用户以大部分方式理解Kubernetes中的权限，但仍然有一些特定的复杂性，安全专业人员和工程师应该理解。聚合ClusterRoles就是这样一个例子：集群角色聚合允许管理员在不修改角色本身的情况下向现有ClusterRole添加权限。这主要用于他们需要向默认ClusterRole添加权限的情况（如“视图”或“编辑”）。虽然修改默认角色在技术上有效，但在升级集群时可能会出现问题。Kubernetes可能会破坏默认角色修改，有时会破坏所需的权限。幸运的是，可以通过将其他权限聚合到具有单独的ClusterRole定义和特殊注释的现有ClusterRole中来避免这种情况。虽然这听起来令人困惑，但令人惊讶的是，很容易想象：
在上面的示例中，pod-mgr角色仅提供获取pod的权限。然而，它还用“agg-pod-mgr”标签聚合了来自其他ClusterRoles的任何权限，因此可以获取并列出有效的权限。
说到动词，有三个“不常见的动词”，但它们对Kubernetes的授权决策方式有重要影响。冒着过于戏剧性的风险，这些动词从字面上改变了规则，并且是前面提到的一些基本规则的例外。它们是：
- “Bind。”Bind是早期规则的例外，该规则涉及用户无法授予他们尚未拥有的权限。绑定动词允许用户创建角色绑定资源，即使他们没有目标角色的权限。安全分析师应该注意这个动词，因为这是提升权限的常见方式。
- “Escalate。”默认情况下，用户不能编辑他们已经绑定的角色，以授予自己额外的权限——这是合理的预防措施。升级动词允许他们这样做，绕过“此用户是否已经拥有这些权限？”检查编辑角色时通常发生的情况。
- “Impersonate。”模拟是一种机制，允许用户作为不同的主体（用户、组、服务帐户）运行API请求。这就像Linux中的“su”命令，但对于Kubernetes来说。通常，此动词仅供高度权限管理员用于帮助调试权限问题，因此安全专业人员应仔细检查冒名动词的使用情况，以确保没有意外升级权限的路径。
最后，重要的是要注意星号——也称为“通配符”——这可能意味着一个操作授予的权限比预期的要多。例如，在ClusterRoles上授予“*”动词似乎很安全，因为有内置的权限升级阻止检查，但事实并非如此。如上所述，这将授予权限升级的“绑定”和“升级”访问权限。由于这样的意外后果，通配符只能小心使用。
保护Kubernetes越来越重要
Kubernetes中的访问控制非常重要，特别是随着Kubernetes在生产和业务关键型工作负载中变得越来越普遍。了解RBAC授权的工作原理对于授予必要的权限至关重要，但重要的是要避免发放比必要的权限多，并保持最低权限的心态。在利用重叠的权限、配置错误和被盗身份方面，今天的攻击者变得越来越精明。Kubernetes中有效的基于角色的访问控制可以帮助将这些暴露降到最低。
