基于角色的访问控制

在 Kubernetes 中，为用户或应用程序特定的服务帐户授予角色是最佳实践，以确保您的应用程序在您指定的范围内运行。 阅读有关服务帐户权限的更多信息 在官方 Kubernetes 文档中.

从 Kubernetes 1.6 开始，基于角色的访问控制默认启用。 RBAC 允许您指定根据用户及其在组织中的角色允许执行哪些类型的操作。

使用 RBAC，您可以

• 授予管理员特权操作（创建集群范围的资源，例如新角色）
• 限制用户创建资源（Pod、持久卷、部署）的能力，这些资源仅限于特定命名空间，或在集群范围（资源配额、角色、自定义资源定义）
• 限制用户查看特定命名空间或集群范围的资源的能力。

本指南适用于希望限制用户与 Kubernetes API 交互范围的管理员。

管理用户帐户

所有 Kubernetes 集群都有两类用户：由 Kubernetes 管理的服务帐户和普通用户。

假定普通用户由外部独立服务管理。 管理员分发私钥、用户存储（如 Keystone 或 Google 帐户）、甚至包含用户名和密码列表的文件。 在这方面，Kubernetes 没有表示普通用户帐户的对象。 无法通过 API 调用将普通用户添加到集群。

相反，服务帐户是由 Kubernetes API 管理的用户。 它们绑定到特定命名空间，并由 API 服务器自动创建或通过 API 调用手动创建。 服务帐户与存储为 Secrets 的一组凭据绑定，这些凭据被安装到 Pod 中，允许集群内进程与 Kubernetes API 通信。

API 请求与普通用户或服务帐户绑定，或被视为匿名请求。 这意味着集群内部或外部的每个进程，从在工作站上键入 kubectl 的人类用户，到节点上的 kubelet，到控制平面的成员，都必须在向 API 服务器发出请求时进行身份验证，或被视为匿名用户。

角色、ClusterRole、RoleBinding 和 ClusterRoleBinding

在 Kubernetes 中，用户帐户和服务帐户只能查看和编辑它们被授予访问权限的资源。 此访问权限通过使用角色和 RoleBinding 授予。 角色和 RoleBinding 绑定到特定命名空间，该命名空间授予用户在该命名空间内查看和/或编辑角色提供他们访问权限的资源的能力。

在集群范围内，这些被称为 ClusterRole 和 ClusterRoleBinding。 授予用户 ClusterRole 允许他们访问整个集群中查看和/或编辑资源。 这也是查看和/或编辑集群范围（命名空间、资源配额、节点）的资源所必需的。

ClusterRole 可以通过 RoleBinding 中的引用绑定到特定命名空间。 admin、edit 和 view 默认 ClusterRole 通常以这种方式使用。

以下是一些 Kubernetes 中默认提供的 ClusterRole。 它们旨在成为面向用户的角色。 它们包括超级用户角色（cluster-admin）和具有更细粒度访问权限的角色（admin、edit、view）。

使用 RBAC 限制用户帐户的访问权限

现在我们了解了基于角色的访问控制的基础知识，让我们讨论一下管理员如何限制用户的访问范围。

示例：授予用户对特定命名空间的读/写访问权限

要限制用户对特定命名空间的访问权限，我们可以使用 edit 或 admin 角色。 如果您的图表创建或与角色和 RoleBinding 交互，您需要使用 admin ClusterRole。

此外，您还可以创建具有 cluster-admin 访问权限的 RoleBinding。 授予用户在命名空间范围内的 cluster-admin 访问权限，可以提供对命名空间中所有资源的完全控制权，包括命名空间本身。

在本示例中，我们将创建具有 edit 角色的用户。 首先，创建命名空间

$ kubectl create namespace foo

现在，在该命名空间中创建 RoleBinding，授予用户 edit 角色。

$ kubectl create rolebinding sam-edit
    --clusterrole edit \​
    --user sam \​
    --namespace foo

示例：授予用户对集群范围的读/写访问权限

如果用户希望安装一个安装集群范围资源（命名空间、角色、自定义资源定义等）的图表，他们将需要集群范围的写访问权限。

为此，授予用户 admin 或 cluster-admin 访问权限。

授予用户 cluster-admin 访问权限，允许他们访问 Kubernetes 中的绝对所有可用资源，包括使用 kubectl drain 访问节点和其他管理任务。 强烈建议您考虑为用户提供 admin 访问权限，或创建适合他们需求的自定义 ClusterRole。

$ kubectl create clusterrolebinding sam-view
    --clusterrole view \​
    --user sam

$ kubectl create clusterrolebinding sam-secret-reader
    --clusterrole secret-reader \​
    --user sam

示例：授予用户对特定命名空间的只读访问权限

您可能已经注意到，没有可用于查看 Secrets 的 ClusterRole。 view ClusterRole 不会授予用户对 Secrets 的读访问权限，因为存在升级问题。 舵手默认将发布元数据存储为 Secrets。

为了让用户运行 helm list，他们需要能够读取这些 Secrets。 为此，我们将创建一个特殊的 secret-reader ClusterRole。

创建文件 cluster-role-secret-reader.yaml，并将以下内容写入该文件

apiVersion: rbac.authorization.k8s.io/v1​
kind: ClusterRole​
metadata:​
  name: secret-reader​
rules:​
- apiGroups: [""]​
  resources: ["secrets"]​
  verbs: ["get", "watch", "list"]

然后，使用以下命令创建 ClusterRole

$ kubectl create -f clusterrole-secret-reader.yaml​

完成此操作后，我们可以授予用户对大多数资源的读访问权限，然后授予他们对 Secrets 的读访问权限

$ kubectl create namespace foo

$ kubectl create rolebinding sam-view
    --clusterrole view \​
    --user sam \​
    --namespace foo

$ kubectl create rolebinding sam-secret-reader
    --clusterrole secret-reader \​
    --user sam \​
    --namespace foo

示例：授予用户对集群范围的只读访问权限

在某些情况下，授予用户集群范围的访问权限可能会有益。 例如，如果用户希望运行命令 helm list --all-namespaces，则 API 需要用户具有集群范围的读访问权限。

为此，按照上述步骤授予用户 view 和 secret-reader 访问权限，但使用 ClusterRoleBinding。

$ kubectl create clusterrolebinding sam-view
    --clusterrole view \​
    --user sam

$ kubectl create clusterrolebinding sam-secret-reader
    --clusterrole secret-reader \​
    --user sam

其他想法

上面的示例使用了 Kubernetes 提供的默认 ClusterRole。 为了更细粒度地控制授予用户访问哪些资源，请查看 Kubernetes 文档，了解如何创建自己的自定义角色和 ClusterRole。