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

审校 | 重楼

什么是Kubernetes RBAC?

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

例如，有Dev、Staging和Production三个不同的环境，必须向团队(例如开发人员、DevOps人员、SRE、应用程序所有者和产品经理)提供访问权限。

在开始之前需要强调一下，从抽象的角度来看，将把用户和服务帐户视为相同的——每个请求，无论是来自用户还是服务帐户，最终都是HTTP请求。人们知道Kubernetes中的用户和服务帐户（针对非人类用户）本质上是不同的。

如何启用Kubernetes RBAC

可以在Kubernetes中启用RBAC，这种方法是启动带有授权模式标志的API服务器。用于向用户应用RBAC的Kubernetes资源有：

• 角色（Role）
• 集群角色（ClusterRole）
• 角色绑定（RoleBinding）
• 集群角色绑定（ClusterRoleBinding）

1.服务帐户

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

例如，Kubernetes资源需要由Spinnaker或Argo等持续交付(CD)应用程序访问才能部署应用程序，或者服务A的一个pod需要与服务B的另一个pod对话。在这种情况下，服务帐户用于创建非人类用户的帐户并指定所需授权（使用角色绑定或集群角色绑定）。

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

YAML 
 apiVersion: v1
 kind: ServiceAccount
 metadata:
  name: nginx-sa
 spec: 
  automountServiceAccountToken: false

然后应用它。

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

现在，必须为部署资源中的pod提供服务帐户。

YAML 
 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。

以下可以看到如何使用角色绑定和集群角色绑定为服务帐户分配各种权限。

2.角色和集群角色

角色（Role）和集群角色（ClusterRole）是Kubernetes资源分别用于定义用户可以在命名空间或集群中执行的操作列表。

在Kubernetes中，参与者(如用户、组或服务帐户)被称为主题。主体的动作，如创建、读取、写入、更新和删除，称为操作。

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

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

类似地，集群角色（资源将允许创建与集群相关的角色）。下面是一个例子：

YAML 
 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的用户/组/服务帐户都可以在集群中执行任何操作。

在下一节中，将看到如何使用角色绑定和集群角色绑定向主题授予角色。

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

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

3.角色绑定和集群角色绑定

要将角色应用于主题（用户/组/服务帐号），必须定义角色绑定。这将使用角色配置中定义的权限为用户提供对命名空间内所需资源的最低权限访问。

YAML 
 apiVersion: rbac.authorization.k8s.io/v1beta1
 kind: RoleBinding
 metadata:
 name: Role-binding-dev
 roleRef:
  kind: Role
 name: read-only #The role name you defined in the Role configuration
  apiGroup: rbac.authorization.k8s.io
 subjects:
 - kind: User
  name: Roy #The name of the user to give the role to
 apiGroup: rbac.authorization.k8s.io
 - kind: ServiceAccount
  name: nginx-sa#The name of the ServiceAccount to give the role to
 apiGroup: rbac.authorization.k8s.io

类似地，可以创建集群角色绑定资源来定义用户的角色。需要注意的是，使用了Kubernetes提供的默认超级用户集群角色引用，而不是使用自定义角色。这可以应用于集群管理员。

YAML 
 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的优势在于它允许“原生”实现对集群中各种用户和机器的最小权限。主要的好处是：

1.适当的授权

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

2.职责分离

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

3.100%遵守法规

许多行业法规（例如HIPAA、GDPR、SOX等）都要求软件领域有严格的认证和授权机制。使用Kubernetes RBAC，DevOps和架构师可以快速地将RBAC实现到他们的Kubernetes集群中，并改进他们的设置以遵守这些标准。

Kubernetes RBAC的缺点

对于中小型企业来说，使用Kubernetes RBAC是合理的，但不建议使用Kubernetes RBAC，其原因如下：

• 可能有许多用户和机器，并且应用Kubernetes RBAC可能难以实现和维护。
• 很难看到谁执行了什么操作。例如，大型企业可能需要诸如违反RBAC权限或恶意尝试之类的信息。

原文What Is Kubernetes RBAC and Why Do You Need It?，作者：Debasree Panda