譯者 | 李睿
審校 | 重樓
什么是Kube.NETes RBAC?
當(dāng)組織開(kāi)始走上Kubernetes之旅時(shí)，在通常情況下，他們希望實(shí)現(xiàn)最低權(quán)限角色和適當(dāng)?shù)氖跈?quán)來(lái)保護(hù)他們的基礎(chǔ)設(shè)施。這就是實(shí)現(xiàn)Kubernetes RBAC以保護(hù)Kubernete資源的地方，例如敏感數(shù)據(jù)，包括部署細(xì)節(jié)、持久存儲(chǔ)設(shè)置和機(jī)密。Kubernetes RBAC提供了控制誰(shuí)能夠以何種訪問(wèn)方式訪問(wèn)每個(gè)API資源的能力。組織可以為人類用戶（個(gè)人或組）和非人類用戶（服務(wù)帳戶）使用RBAC來(lái)定義他們對(duì)各種Kubernetes資源的訪問(wèn)類型。
例如，有Dev、Staging和Production三個(gè)不同的環(huán)境，必須向團(tuán)隊(duì)(例如開(kāi)發(fā)人員、DevOps人員、SRE、應(yīng)用程序所有者和產(chǎn)品經(jīng)理)提供訪問(wèn)權(quán)限。
在開(kāi)始之前需要強(qiáng)調(diào)一下，從抽象的角度來(lái)看，將把用戶和服務(wù)帳戶視為相同的——每個(gè)請(qǐng)求，無(wú)論是來(lái)自用戶還是服務(wù)帳戶，最終都是HTTP請(qǐng)求。人們知道Kubernetes中的用戶和服務(wù)帳戶（針對(duì)非人類用戶）本質(zhì)上是不同的。
如何啟用Kubernetes RBAC
可以在Kubernetes中啟用RBAC，這種方法是啟動(dòng)帶有授權(quán)模式標(biāo)志的API服務(wù)器。用于向用戶應(yīng)用RBAC的Kubernetes資源有：
- 角色（Role）
- 集群角色（ClusterRole）
- 角色綁定（RoleBinding）
- 集群角色綁定（ClusterRoleBinding）
1.服務(wù)帳戶
為了管理用戶，Kubernetes提供了一種身份驗(yàn)證機(jī)制，但通常建議將Kubernetes與企業(yè)用戶身份管理(如Active Directory或LDAP)集成在一起。當(dāng)涉及到Kubernetes集群中的非人類用戶(或機(jī)器或服務(wù))時(shí)，就出現(xiàn)了服務(wù)帳戶的概念。
例如，Kubernetes資源需要由Spinnaker或Argo等持續(xù)交付(CD)應(yīng)用程序訪問(wèn)才能部署應(yīng)用程序，或者服務(wù)A的一個(gè)pod需要與服務(wù)B的另一個(gè)pod對(duì)話。在這種情況下，服務(wù)帳戶用于創(chuàng)建非人類用戶的帳戶并指定所需授權(quán)（使用角色綁定或集群角色綁定）。
可以通過(guò)創(chuàng)建如下所示的yaml來(lái)創(chuàng)建一個(gè)服務(wù)帳戶：
YAML
apiVersion: v1
kind: ServiceAccount
metadata:
name: Nginx-sa
spec:
automountServiceAccountToken: false
然后應(yīng)用它。
Shell
$ kubectl Apply -f nginx-sa.yaml
serviceaccount/nginx-sa created
現(xiàn)在，必須為部署資源中的pod提供服務(wù)帳戶。
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
如果沒(méi)有在部署資源中指定服務(wù)帳戶名稱（serviceAccountName），那么pod將屬于默認(rèn)的服務(wù)帳戶。需要注意的是，每個(gè)命名空間都有一個(gè)默認(rèn)的服務(wù)帳戶，集群也有一個(gè)默認(rèn)的服務(wù)帳戶。默認(rèn)服務(wù)帳戶的所有默認(rèn)授權(quán)策略將應(yīng)用于未提及服務(wù)帳戶信息的pod。
以下可以看到如何使用角色綁定和集群角色綁定為服務(wù)帳戶分配各種權(quán)限。
2.角色和集群角色
角色（Role）和集群角色（ClusterRole）是Kubernetes資源分別用于定義用戶可以在命名空間或集群中執(zhí)行的操作列表。
在Kubernetes中，參與者(如用戶、組或服務(wù)帳戶)被稱為主題。主體的動(dòng)作，如創(chuàng)建、讀取、寫(xiě)入、更新和刪除，稱為操作。
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)的所有資源。任何綁定到只讀角色的服務(wù)帳戶或用戶都可以執(zhí)行這些操作——獲取、列出和監(jiān)視。
類似地，集群角色（資源將允許創(chuàng)建與集群相關(guān)的角色）。下面是一個(gè)例子：
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的用戶/組/服務(wù)帳戶都可以在集群中執(zhí)行任何操作。
在下一節(jié)中，將看到如何使用角色綁定和集群角色綁定向主題授予角色。
另外，Kubernetes允許使用角色資源配置自定義角色，或者使用默認(rèn)的面向用戶的角色，如下所示：
- 集群管理員（Cluster-admin）：對(duì)于集群管理員，Kubernetes提供了一個(gè)超級(jí)用戶角色。集群管理員可以對(duì)集群中的任何資源執(zhí)行任何操作?？梢栽诩航巧壎ㄖ惺褂贸?jí)用戶來(lái)授予對(duì)集群(和所有命名空間)中的每個(gè)資源的完全控制權(quán)，也可以在角色綁定中使用超級(jí)用戶來(lái)授予對(duì)各自命名空間中的每個(gè)資源的完全控制權(quán)。
- 管理員（Admin）：Kubernetes提供了一個(gè)管理員角色，允許對(duì)命名空間內(nèi)的資源進(jìn)行無(wú)限制的讀/寫(xiě)訪問(wèn)。管理員角色可以在特定的命名空間內(nèi)創(chuàng)建角色和角色綁定。它不允許對(duì)命名空間本身進(jìn)行寫(xiě)訪問(wèn)。這可以在角色綁定的資源中使用。
- 編輯（Edit）：編輯角色在給定的Kubernetes命名空間內(nèi)授予讀/寫(xiě)訪問(wèn)權(quán)限。它無(wú)法查看或修改角色或角色綁定。
- 視圖（View）：視圖角色允許在給定的命名空間內(nèi)進(jìn)行只讀訪問(wèn)。它不允許查看或修改角色或角色綁定。
3.角色綁定和集群角色綁定
要將角色應(yīng)用于主題（用戶/組/服務(wù)帳號(hào)），必須定義角色綁定。這將使用角色配置中定義的權(quán)限為用戶提供對(duì)命名空間內(nèi)所需資源的最低權(quán)限訪問(wè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)建集群角色綁定資源來(lái)定義用戶的角色。需要注意的是，使用了Kubernetes提供的默認(rèn)超級(jí)用戶集群角色引用，而不是使用自定義角色。這可以應(yīng)用于集群管理員。
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)勢(shì)在于它允許“原生”實(shí)現(xiàn)對(duì)集群中各種用戶和機(jī)器的最小權(quán)限。主要的好處是：
1.適當(dāng)?shù)氖跈?quán)
通過(guò)對(duì)各種用戶和服務(wù)帳戶授予Kubernetes資源的最小權(quán)限，是DevOps和架構(gòu)師可以實(shí)現(xiàn)零信任的主要支柱之一。組織可以減少數(shù)據(jù)泄露和數(shù)據(jù)泄露的風(fēng)險(xiǎn)，還可以避免內(nèi)部員工意外刪除或操縱任何關(guān)鍵資源。
2.職責(zé)分離
在Kubernetes資源上應(yīng)用RBAC將始終有助于組織中用戶(例如開(kāi)發(fā)人員、DevOps、測(cè)試人員、SRE等)的職責(zé)分離。例如，為了在開(kāi)發(fā)環(huán)境中創(chuàng)建/刪除新資源，開(kāi)發(fā)人員不應(yīng)該依賴于管理員。同樣，將新應(yīng)用程序部署到測(cè)試服務(wù)器并在測(cè)試后刪除pod不應(yīng)該成為DevOps或測(cè)試人員的瓶頸。將授權(quán)和權(quán)限應(yīng)用到用戶(如開(kāi)發(fā)人員和CI/CD部署代理)各自的工作空間(如命名空間或集群)將減少依賴并減少懈怠。
3.100%遵守法規(guī)
許多行業(yè)法規(guī)（例如HIPAA、GDPR、SOX等）都要求軟件領(lǐng)域有嚴(yán)格的認(rèn)證和授權(quán)機(jī)制。使用Kubernetes RBAC，DevOps和架構(gòu)師可以快速地將RBAC實(shí)現(xiàn)到他們的Kubernetes集群中，并改進(jìn)他們的設(shè)置以遵守這些標(biāo)準(zhǔn)。
Kubernetes RBAC的缺點(diǎn)
對(duì)于中小型企業(yè)來(lái)說(shuō)，使用Kubernetes RBAC是合理的，但不建議使用Kubernetes RBAC，其原因如下：
- 可能有許多用戶和機(jī)器，并且應(yīng)用Kubernetes RBAC可能難以實(shí)現(xiàn)和維護(hù)。
- 很難看到誰(shuí)執(zhí)行了什么操作。例如，大型企業(yè)可能需要諸如違反RBAC權(quán)限或惡意嘗試之類的信息。
原文標(biāo)題：What Is Kubernetes RBAC and Why Do You Need It?，作者：Debasree Panda
