什么是Kubernetes?RBAC？為什么需要它？

作者：李睿 2023-11-07 08:00:00

了解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

責任編輯：華軒來源： 51CTO

Kubernetes