基于角色的访问控制（RBAC）是一种用于控制系统中不同用户可以访问哪些操作和资源的方法。用户被分配角色，这些角色赋予他们使用特定系统功能的权限。Kubernetes拥有强大的内置RBAC实现，用于授权用户与集群的交互。设置RBAC允许您定义用户可以在每种Kubernetes对象类型上执行的特定操作。这为防范过度授权的用户账户风险提供了重要的第一道防线，防止任何人都可以使用任意功能。

在本文中，您将了解什么是Kubernetes RBAC，为什么应该使用它，以及如何在您的集群中配置它。

---

 

什么是 Kubernetes RBAC

 

Kubernetes中的RBAC（基于角色的访问控制）是一种用于管理和控制用户对集群资源的访问权限的安全机制。它允许您定义和分配角色，以限制哪些用户可以执行特定的操作、访问特定的资源。通过RBAC， 您可以创建自定义角色，将权限与这些角色关联，并将角色分配给用户、组或服务账户。这样可以确保在集群中实现最小权限原则，即为每个用户或组提供必要的权限，以减少安全风险。

 

---

 

RBAC 与 ABAC

RBAC是Kubernetes授权的现代方法，但基于属性的访问控制（ABAC）作为另一种替代方案也是可用的。在Kubernetes v1.6之前的版本中，ABAC是选项。然而，现在建议使用RBAC而不是ABAC。尽管仍然支持ABAC，但最好将ABAC视为已废弃。

ABAC模式要求您将授权规则配置为一个JSON文件中的策略，然后将该文件提供给Kubernetes API服务。它会检查每个被访问资源的属性，例如其命名空间和类型，以确定用户是否被授权：

然而，Kubernetes对于ABAC的实现还有进一步改进的空间。在当前的形式下，Kubernetes的ABAC授权结果无法基于目标资源的任何属性，因为您只能基于API组、命名空间和资源类型进行匹配。同样地，您在用户级别的属性匹配方面受到用户名和组的限制。

因此，RBAC更容易进行配置、测试和维护，同时又不会丧失ABAC的任何功能。Kubernetes目前没有内置的方法来执行真正基于ABAC的授权，这将允许根据任意资源属性（例如标签、创建时间和镜像）来产生不同的授权结果。

---

探索 Kubernetes 上的 RBAC

Kubernetes的RBAC实现围绕着四种主要的对象类型：

1. Roles（角色）：Role对象将一组权限进行分组，这些权限可以分配给您的用户。Roles是命名空间对象，因此它们只允许访问其所属命名空间中的资源。

2.RoleBindings（角色绑定）：RoleBindings将角色分配给用户。RoleBinding中列出的每个用户都被分配了与绑定角色中包含的权限相对应的权限。

3.ClusterRoles（集群角色）：ClusterRoles类似于Roles，但ClusterRoles是非命名空间对象，存在于集群级别。您可以使用它们来管理对全局集群资源（例如节点）的访问，以及对跨命名空间的对象（例如PersistentVolume）的访问。

4. ClusterRoleBindings（集群角色绑定）：ClusterRoleBindings是将ClusterRoles与用户关联的集群级别版本的RoleBindings。它们只能引用ClusterRoles，而不是命名空间内的Roles。

Kubernetes强制实施了Roles和ClusterRoles之间的区别，这是因为所有对象必须是命名空间对象或非命名空间对象。

这意味着，当您希望控制对特定命名空间内资源的访问时，应使用Role。另一方面，如果您计划在多个命名空间中重复使用相同的权限，或者希望限制对不属于任何命名空间的集群级对象（例如节点）的访问时，最好创建一个ClusterRole。这种灵活性确保您可以根据需要和Kubernetes环境的范围，有效地组织和控制资源的访问。

---

 

RBAC与Kubernetes用户账户

实施Kubernetes的RBAC需要您首先创建角色（Roles）和集群角色（ClusterRoles），然后将它们绑定到您的用户账户，以便用户和应用程序可以进行身份验证并获取正确的权限。在用户身份验证方面，有两种策略：普通用户和服务账户。

普通用户

普通用户是指与Kubernetes API服务器进行交互的用户。Kubernetes没有内置对象来表示用户或管理其凭据；相反，管理员需要自行定义身份验证系统，可以使用私钥、在文件中定义的令牌，或者与身份服务进行外部OAuth集成。

通过Kubernetes API无法添加新的普通用户。然而，Kubernetes支持X509客户端证书认证策略，允许客户端使用集群证书颁发机构签名的任何证书进行身份验证。这通常是kubectl连接到集群时使用的默认策略。RBAC中的用户名由证书的通用名称（CN）字段识别。

服务账户

服务账户专门设计用于那些不是由人直接操作的应用程序，如Pod、容器等与Kubernetes API进行交互的实体。与普通用户不同，它们由Kubernetes API进行管理，因此您可以使用kubectl命令创建它们。每个服务账户都有一个独特的令牌，用于将您的应用程序进行身份验证到API服务器。与普通用户不同，服务账户可以范围限定到特定的集群命名空间中。

在探索Kubernetes RBAC功能时，使用服务账户更加简单。您无需管理证书或连接外部身份提供者。

然而，服务账户主要用于集群内需要与Kubernetes API进行交互的Pod。并不推荐用于长期用户使用，这些用户可能需要执行更广泛的任务，如集群管理、监控、故障排除等。对于用户，更好的做法是将现有的身份提供者（如LDAP、Active Directory等）与Kubernetes集成，以管理用户的账户和权限。

---

在Kubernetes中使用RBAC

既然您已经了解了RBAC的工作原理，现在可以通过一个简单的演示在Kubernetes中开始使用它。您需要已经安装了kubectl并且连接到了一个现有的集群。

在本教程中，您将简单的设置一个服务账户用户，但请记住，在实际的现实场景中，我们更推荐使用OAuth集成。

 

1

检查RBAC是否启用

 

RBAC是Kubernetes的一个可选特性。尽管大多数发行版现在都默认启用了它，但在继续之前最好进行检查。运行以下kubectl命令：

       $ kubectl api-versions | grep rbac.authorization.k8s

rbac.authorization.k8s.io/v1

如果在终端中看到 rbac.authorization.k8s.io/v1 的显示，那么 RBAC 已处于启用状态。如果没有任何输出，则表示 API 被禁用。您需要调整API服务的启动配置，可以使用 --authorization-mode=RBAC 来启动 API 服务。

2

  创建服务帐号

 

创建一个服务帐户。将角色分配给服务帐户，以便您可以了解 RBAC 的工作原理。复制以下 YAML 并将其保存到service-account.yaml：

 

apiVersion: v1

kind: ServiceAccount

metadata:

name: demo

---

apiVersion: v1

kind: Secret

type:

kubernetes.io/service-account-token

metadata:

name: demo-sa-token

annotations:

kubernetes.io/service-account.name: demo

 

然后使用 kubectl 将 YAML 配置文件应用到您的集群中：

$ kubectl apply -f service-account.yaml

 

serviceaccount/demo created

secret/demo-sa-token created

 

服务账户已创建，并附带一个包含其身份验证令牌的密钥。获取此令牌的值：

       $ SA_TOKEN=$(kubectl describe secret demo-sa-token | grep token: | awk '{print $2}')

令牌的值已保存到您的Shell的 $SA_TOKEN 变量中，准备在下一步中引用。

3

创建新的kubectl上下文

 

接下来，您需要添加一个 kubectl 上下文，用于将您的集群身份验证为您的服务账户。

首先，检查当前上下文的名称，以便稍后可以切换回该上下文： 

       $ kubectl config current-context$ kubectl config current-context

default

现在，运行以下命令将您的服务账户凭据注册到 kubectl 配置文件中：

       $ kubectl config set-credentials demo-sa --token=$SA_TOKEN

User "demo-sa" set.

然后添加一个新的上下文，用于对现有 Kubernetes 集群进行身份验证，但使用新的demo-sa服务帐户凭据：

        $ kubectl config set-context demo --cluster=default --user=demo-sa

Context "demo" created.

如果您的 KUBECONFIG 文件中的集群名称不是 "demo"，则您需要更改之前传递给 --cluster 标志的值。您可以通过运行 kubectl config get-clusters 命令来获取文件中可用的集群列表。（例如，如果您正在使用具有默认命名的 kind 集群，则集群名称可能是 kind-kind）。

最后，切换到您的新上下文，并尝试运行一个简单的 kubectl 命令，比如列出您集群中的 Pod：

$ kubectl config use-context demo

Switched to context "demo".

$ kubectl get pods

       Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:demo" cannot list resource "pods" in API group "" in the namespace "default"

正如您所见，API 服务器拒绝了访问 —— 由于服务账户尚未分配任何 RBAC 角色，因此它没有执行任何操作的权限。现在，请先切换回您的常规 kubectl 上下文以恢复您的集权限，然后再进行角色分配：

$ kubectl config use-context default

Switched to context "default".

4

创建角色

 

角色（以及集群角色）是可以使用 YAML 清单进行定义的 Kubernetes 对象。请复制以下 YAML 并将其保存为 role.yaml 文件到您的工作目录中：

 

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

  name: sample-role

rules:

  - apiGroups: [""]

    resources: ["pods"]

    verbs: ["get", "list", "create"]

 

 

Roles指定了资源的组合，例如pods、services和deployments，以及持有者被授予执行的动作，如list、create和delete。这个示例Role允许用户创建pods并检索其详细信息，但不允许进行其他类型的交互。

使用kuberctl创建角色

$ kubectl apply -f role.yaml

       role.rbac.authorization.k8s.io/sample-role created

5

 绑定角色

 

现在，角色已在您的集群中存在，但您仍需要将其绑定到服务账户上，以授予用户在角色中定义的权限。

复制以下的YAML内容并保存到`role-binding.yaml`文件中：

 

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

  name: sample-role-binding

subjects:

  - kind: ServiceAccount

    name: demo

    apiGroup: ""

roleRef:

  kind: Role

  name: sample-role

  apiGroup: ""

 

该清单将`sample-role`角色绑定到名为`demo`的服务账户。绑定中的主体标识了被分配到`roleRef`字段所指定角色的用户。如果要将其绑定到普通用户而不是服务账户，可以将主体的`kind`字段设置为`User`。

在此示例中，现在应用您的RoleBinding以将角色分配给您的服务账户：

kubectl apply -f role-binding.yaml

       rolebinding.rbac.authorization.k8s.io/sample-role-binding created

6

测试您的 RBAC 权限

 

您可以使用 kubectl 的 auth can-i 命令来检查用户或服务账户是否可以执行特定的操作。当您查询由您的角色覆盖的操作时，现在应该会返回对于您的 demo 服务账户是“yes”：

      kubectl auth can-i get pods --as=system:serviceaccount:default:demo

yes

       kubectl auth can-i delete pods --as=system:serviceaccount:default:demo

no

切换回以您的服务账户进行身份验证的新 kubectl 上下文：

kubectl config use-context demo

Switched to context "demo".

现在，您应该能够在以服务账户身份进行身份验证的情况下成功检索集群中的 Pod：

$ kubectl get pods

No resources found in default namespace.

成功将角色绑定到服务账户。这意味着您可以执行角色所允许的操作，但其他操作，例如查看services，仍然是被禁止的：

$ kubectl get services

       Error from server (Forbidden): services is forbidden: User "system:serviceaccount:default:demo" cannot list resource "services" in API group "" in the namespace "default"

基于角色的访问控制总结：

Kubernetes的RBAC是管理集群访问的标准机制。在本文中，您已经了解了RBAC的概念，Kubernetes中用于实现RBAC的对象类型，以及如何开始在集群中设置自己的角色和角色绑定。