譯者 | 李睿

審校 | 重樓

什么是Kubernetes RBAC?

當組織開始走上Kubernetes之旅時，在通常情況下，他們希望實現(xiàn)最低權(quán)限角色和適當?shù)氖跈?quán)來保護他們的基礎(chǔ)設施。這就是實現(xiàn)Kubernetes RBAC以保護Kubernete資源的地方，例如敏感數(shù)據(jù)，包括部署細節(jié)、持久存儲設置和機密。Kubernetes RBAC提供了控制誰能夠以何種訪問方式訪問每個API資源的能力。組織可以為人類用戶（個人或組）和非人類用戶（服務帳戶）使用RBAC來定義他們對各種Kubernetes資源的訪問類型。

例如，有Dev、Staging和Production三個不同的環(huán)境，必須向團隊(例如開發(fā)人員、DevOps人員、SRE、應用程序所有者和產(chǎn)品經(jīng)理)提供訪問權(quán)限。

在開始之前需要強調(diào)一下，從抽象的角度來看，將把用戶和服務帳戶視為相同的——每個請求，無論是來自用戶還是服務帳戶，最終都是HTTP請求。人們知道Kubernetes中的用戶和服務帳戶（針對非人類用戶）本質(zhì)上是不同的。

如何啟用Kubernetes RBAC

可以在Kubernetes中啟用RBAC，這種方法是啟動帶有授權(quán)模式標志的API服務器。用于向用戶應用RBAC的Kubernetes資源有：

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

1.服務帳戶

為了管理用戶，Kubernetes提供了一種身份驗證機制，但通常建議將Kubernetes與企業(yè)用戶身份管理(如Active Directory或LDAP)集成在一起。當涉及到Kubernetes集群中的非人類用戶(或機器或服務)時，就出現(xiàn)了服務帳戶的概念。

例如，Kubernetes資源需要由Spinnaker或Argo等持續(xù)交付(CD)應用程序訪問才能部署應用程序，或者服務A的一個pod需要與服務B的另一個pod對話。在這種情況下，服務帳戶用于創(chuàng)建非人類用戶的帳戶并指定所需授權(quán)（使用角色綁定或集群角色綁定）。

可以通過創(chuàng)建如下所示的yaml來創(chuàng)建一個服務帳戶：

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

然后應用它。

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

現(xiàn)在，必須為部署資源中的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將屬于默認的服務帳戶。需要注意的是，每個命名空間都有一個默認的服務帳戶，集群也有一個默認的服務帳戶。默認服務帳戶的所有默認授權(quán)策略將應用于未提及服務帳戶信息的pod。

以下可以看到如何使用角色綁定和集群角色綁定為服務帳戶分配各種權(quán)限。

2.角色和集群角色

角色（Role）和集群角色（ClusterRole）是Kubernetes資源分別用于定義用戶可以在命名空間或集群中執(zhí)行的操作列表。

在Kubernetes中，參與者(如用戶、組或服務帳戶)被稱為主題。主體的動作，如創(chuàng)建、讀取、寫入、更新和刪除，稱為操作。

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命名空間和命名空間內(nèi)的所有資源。任何綁定到只讀角色的服務帳戶或用戶都可以執(zhí)行這些操作——獲取、列出和監(jiān)視。

類似地，集群角色（資源將允許創(chuàng)建與集群相關(guān)的角色）。下面是一個例子：

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的用戶/組/服務帳戶都可以在集群中執(zhí)行任何操作。

在下一節(jié)中，將看到如何使用角色綁定和集群角色綁定向主題授予角色。

另外，Kubernetes允許使用角色資源配置自定義角色，或者使用默認的面向用戶的角色，如下所示：

• 集群管理員（Cluster-admin）：對于集群管理員，Kubernetes提供了一個超級用戶角色。集群管理員可以對集群中的任何資源執(zhí)行任何操作?？梢栽诩航巧壎ㄖ惺褂贸売脩魜硎谟鑼?和所有命名空間)中的每個資源的完全控制權(quán)，也可以在角色綁定中使用超級用戶來授予對各自命名空間中的每個資源的完全控制權(quán)。
• 管理員（Admin）：Kubernetes提供了一個管理員角色，允許對命名空間內(nèi)的資源進行無限制的讀/寫訪問。管理員角色可以在特定的命名空間內(nèi)創(chuàng)建角色和角色綁定。它不允許對命名空間本身進行寫訪問。這可以在角色綁定的資源中使用。
• 編輯（Edit）：編輯角色在給定的Kubernetes命名空間內(nèi)授予讀/寫訪問權(quán)限。它無法查看或修改角色或角色綁定。
• 視圖（View）：視圖角色允許在給定的命名空間內(nèi)進行只讀訪問。它不允許查看或修改角色或角色綁定。

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

要將角色應用于主題（用戶/組/服務帳號），必須定義角色綁定。這將使用角色配置中定義的權(quán)限為用戶提供對命名空間內(nèi)所需資源的最低權(quán)限訪問。

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

類似地，可以創(chuàng)建集群角色綁定資源來定義用戶的角色。需要注意的是，使用了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的優(yōu)勢在于它允許“原生”實現(xiàn)對集群中各種用戶和機器的最小權(quán)限。主要的好處是：

1.適當?shù)氖跈?quán)

通過對各種用戶和服務帳戶授予Kubernetes資源的最小權(quán)限，是DevOps和架構(gòu)師可以實現(xiàn)零信任的主要支柱之一。組織可以減少數(shù)據(jù)泄露和數(shù)據(jù)泄露的風險，還可以避免內(nèi)部員工意外刪除或操縱任何關(guān)鍵資源。

2.職責分離

在Kubernetes資源上應用RBAC將始終有助于組織中用戶(例如開發(fā)人員、DevOps、測試人員、SRE等)的職責分離。例如，為了在開發(fā)環(huán)境中創(chuàng)建/刪除新資源，開發(fā)人員不應該依賴于管理員。同樣，將新應用程序部署到測試服務器并在測試后刪除pod不應該成為DevOps或測試人員的瓶頸。將授權(quán)和權(quán)限應用到用戶(如開發(fā)人員和CI/CD部署代理)各自的工作空間(如命名空間或集群)將減少依賴并減少懈怠。

3.100%遵守法規(guī)

許多行業(yè)法規(guī)（例如HIPAA、GDPR、SOX等）都要求軟件領(lǐng)域有嚴格的認證和授權(quán)機制。使用Kubernetes RBAC，DevOps和架構(gòu)師可以快速地將RBAC實現(xiàn)到他們的Kubernetes集群中，并改進他們的設置以遵守這些標準。

Kubernetes RBAC的缺點

對于中小型企業(yè)來說，使用Kubernetes RBAC是合理的，但不建議使用Kubernetes RBAC，其原因如下：

• 可能有許多用戶和機器，并且應用Kubernetes RBAC可能難以實現(xiàn)和維護。
• 很難看到誰執(zhí)行了什么操作。例如，大型企業(yè)可能需要諸如違反RBAC權(quán)限或惡意嘗試之類的信息。

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