什么是 Kubernetes RBAC 以及为什么需要它？

什么是 Kubernetes RBAC

通常，当组织开始 Kubernetes 之旅时，他们会寻求实施最低权限角色和适当的授权来保护其基础设施。这就是实施 Kubernetes RBAC 的地方，以保护 Kubernetes 资源，例如敏感数据，包括部署详细信息、持久存储设置和机密。Kubernetes RBAC提供了控制谁可以访问每个 API 资源以及以何种访问方式的能力。您可以对人类（个人或组）和非人类用户（服务帐户）使用 RBAC 来定义他们对各种 Kubernetes 资源的访问类型。

例如，有 3 种不同的环境，称为开发、暂存和生产，必须向开发人员、DevOps、SRE、应用程序所有者、产品经理等团队授予访问权限。

Kubernetes 示意图

在开始之前，我们要强调的是，从抽象的角度来看，我们将把用户和服务帐户视为相同的 - 来自用户或服务帐户的每个请求最终都是 HTTP 请求。是的，我们了解Kubernetes 中的用户和服务帐户（对于非人类用户）本质上是不同的。

如何启用 Kubernetes RBAC

人们可以通过在授权模式标志打开的情况下启动 API 服务器来在 Kubernetes 中启用 RBAC。用于对用户应用 RBAC 的 Kubernetes 资源有：

角色，
集群角色，
角色绑定，
集群角色绑定

服务帐号

为了管理用户，Kubernetes 提供了身份验证机制，但通常建议将 Kubernetes 与 Active Directory 或 LDAP 等用户的企业身份管理集成。当涉及 Kubernetes 集群中的非人类用户（或机器或服务）时，服务帐户的概念就出现了。

例如，Kubernetes 资源需要由诸如 Spinnaker 或 Argo 之类的 CD 应用程序访问来部署应用程序，或者服务 A 的一个 pod 需要与服务 B 的另一个 pod 进行通信。在这种情况下，服务帐户用于创建帐户非人类用户的身份，并指定所需的授权（使用 RolesBinding 或 ClusterRoleBinding）。

您可以通过创建如下所示的 yaml 来创建服务帐户：

apiVersion: v1
kind: ServiceAccount
metadata:
name: nginx-saspec: automountServiceAccountToken: false

然后应用它。

$ kubectl apply -f nginx-sa.yaml
serviceaccount/nginx-sa created

现在，您必须为 Deployments 资源中的 pod 提供 ServiceAccount。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx1
  labels:
    app: nginx1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx1
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      serviceAccountName: nginx-sa
      containers:
      - name: nginx1
        image: nginx
        ports:
        - containerPort: 80

如果您未在部署资源中指定serviceAccountName，则 Pod 将属于“默认”服务帐户。请注意，每个命名空间都有一个默认服务帐户，集群也有一个默认服务帐户。并且根据默认服务帐户的所有默认授权策略都将应用于未提及服务帐户信息的 Pod。

在下一节中，我们将了解如何使用 RoleBinding 和 ClusterRoleBinding 向服务帐户分配各种权限。

角色和集群角色

Roles 和 ClusterRoles 是 Kubernetes 资源，用于定义用户可以分别在命名空间或集群中执行的操作列表。

在 Kubernetes 中，用户、组或 ServiceAccount 等参与者称为主体。主语可以执行的操作（例如创建、读取、写入、更新和删除）称为动词。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: read-only
  namespace: dev-namespace
rules:
- apiGroups:
  - ""
  resources: ["*"]
  verbs:
  - get
  - list
  - watch

在上面的角色资源中，我们指定“只读”角色仅适用于 deb-ns 命名空间以及命名空间内的所有资源。任何绑定到“只读”角色的 ServiceAccount 或用户都可以执行这些操作 - 获取、列出和监视。

同样，ClusterRole 资源将允许您创建与集群相关的角色。下面给出的示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: chief-role
rules:
- apiGroups:
- ""
resources: ["*"]
verbs:
- get
- list
- watch
- create
- update
- patch
- delete

绑定到Chief-Role的任何用户/组/ServiceAccount将能够在集群中执行任何操作。

在下一节中，我们将了解如何使用RoleBinding和ClusterRoleBinding向主题授予角色。

另请注意，Kubernetes 允许您使用角色资源配置自定义角色或使用默认的面向用户的角色，如下所示：

Cluster-admin：对于集群管理员，Kubernetes 提供了“超级用户”角色。集群管理员可以对集群中的任何资源执行任何操作。人们可以在 ClusterRoleBinding 中使用“超级用户”来授予对集群（以及所有命名空间）中的每个资源的完全控制权，或者在 RoleBinding 中使用“超级用户”来授予对相应命名空间中的每个资源的完全控制权。
Admin：Kubernetes 提供“admin”角色以允许对命名空间内的资源进行无限制的读/写访问。“admin”角色可以在特定命名空间内创建角色和角色绑定。它不允许对名称空间本身进行写访问。这可以在 RoleBinding 资源中使用。
编辑：“编辑”角色授予给定 Kubernetes 命名空间内的读/写访问权限。它无法查看或修改角色或角色绑定。
View：“视图”角色允许在给定命名空间内进行只读访问。它不允许查看或修改角色或角色绑定。

RoleBinding 和 ClusterRoleBinding

要将角色应用到主题（用户/组/ServiceAccount），您必须定义 RoleBinding。这将为用户提供对命名空间内所需资源的最小权限访问权限，并具有角色配置中定义的权限。

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: Role-binding-dev
roleRef:
  kind: Role
  name: read-only #您在角色配置中定义的角色名称
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
  name: Roy #授予角色的用户的名称
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: nginx-sa#授予角色的 ServiceAccount 的名称
  apiGroup: rbac.authorization.k8s.io

同样，可以创建 ClusterRoleBinding 资源来定义用户的角色。请注意，我们使用了 Kuebrnetes 提供的默认“超级用户”ClusterRole 参考，而不是使用我们的自定义角色。这可以应用于集群管理员。

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: superuser-binding
roleRef:
kind: ClusterRole
name: superuser
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
name: Aditi
apiGroup: rbac.authorization.k8s.io

Kubernetes RBAC 的优点

Kubernetes RBAC 的优点是它允许您“本机”对集群中的各种用户和机器实现最小权限。主要好处是：

适当的授权

通过对各种用户和 Kubernetes 资源的服务帐户赋予最少的权限，DevOps 和架构师可以实现零信任的主要支柱之一。组织可以降低数据泄露和数据泄露的风险，还可以避免内部员工意外删除或操纵任何关键资源。

职责分离

在 Kubernetes 资源上应用 RBAC 将始终促进组织中开发人员、DevOps、测试人员、SRE 等用户的职责分离。例如，在开发环境中创建/删除新资源，开发人员不应依赖管理员。同样，将新应用程序部署到测试服务器并在测试后删除 Pod 不应该成为 DevOps 或测试人员的瓶颈。将开发人员和 CI/CD 部署代理等用户的授权和权限应用到各自的工作区（例如命名空间或集群）将减少依赖性并减少冗余。