建站
咨詢
售后
建站咨詢
新聞中心
譯者 | 李睿
創(chuàng)新互聯(lián)建站網(wǎng)站建設(shè)服務(wù)商，為中小企業(yè)提供網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)服務(wù)，網(wǎng)站設(shè)計(jì)，網(wǎng)站托管維護(hù)等一站式綜合服務(wù)型公司，專業(yè)打造企業(yè)形象網(wǎng)站，讓您在眾多競爭對手中脫穎而出創(chuàng)新互聯(lián)建站。
審校 | 重樓
什么是Kubernetes RBAC?
當(dāng)組織開始走上Kubernetes之旅時(shí)，在通常情況下，他們希望實(shí)現(xiàn)最低權(quán)限角色和適當(dāng)?shù)氖跈?quán)來保護(hù)他們的基礎(chǔ)設(shè)施。這就是實(shí)現(xiàn)Kubernetes RBAC以保護(hù)Kubernete資源的地方，例如敏感數(shù)據(jù)，包括部署細(xì)節(jié)、持久存儲設(shè)置和機(jī)密。Kubernetes RBAC提供了控制誰能夠以何種訪問方式訪問每個(gè)API資源的能力。組織可以為人類用戶（個(gè)人或組）和非人類用戶（服務(wù)帳戶）使用RBAC來定義他們對各種Kubernetes資源的訪問類型。
例如，有Dev、Staging和Production三個(gè)不同的環(huán)境，必須向團(tuán)隊(duì)(例如開發(fā)人員、DevOps人員、SRE、應(yīng)用程序所有者和產(chǎn)品經(jīng)理)提供訪問權(quán)限。
在開始之前需要強(qiáng)調(diào)一下，從抽象的角度來看，將把用戶和服務(wù)帳戶視為相同的——每個(gè)請求，無論是來自用戶還是服務(wù)帳戶，最終都是HTTP請求。人們知道Kubernetes中的用戶和服務(wù)帳戶（針對非人類用戶）本質(zhì)上是不同的。
如何啟用Kubernetes RBAC
可以在Kubernetes中啟用RBAC，這種方法是啟動帶有授權(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)用程序訪問才能部署應(yīng)用程序，或者服務(wù)A的一個(gè)pod需要與服務(wù)B的另一個(gè)pod對話。在這種情況下，服務(wù)帳戶用于創(chuàng)建非人類用戶的帳戶并指定所需授權(quán)（使用角色綁定或集群角色綁定）。
可以通過創(chuàng)建如下所示的yaml來創(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如果沒有在部署資源中指定服務(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ù)帳戶)被稱為主題。主體的動作，如創(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)的所有資源。任何綁定到只讀角色的服務(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）：對于集群管理員，Kubernetes提供了一個(gè)超級用戶角色。集群管理員可以對集群中的任何資源執(zhí)行任何操作。可以在集群角色綁定中使用超級用戶來授予對集群(和所有命名空間)中的每個(gè)資源的完全控制權(quán)，也可以在角色綁定中使用超級用戶來授予對各自命名空間中的每個(gè)資源的完全控制權(quán)。
- 管理員（Admin）：Kubernetes提供了一個(gè)管理員角色，允許對命名空間內(nèi)的資源進(jìn)行無限制的讀/寫訪問。管理員角色可以在特定的命名空間內(nèi)創(chuàng)建角色和角色綁定。它不允許對命名空間本身進(jìn)行寫訪問。這可以在角色綁定的資源中使用。
- 編輯（Edit）：編輯角色在給定的Kubernetes命名空間內(nèi)授予讀/寫訪問權(quán)限。它無法查看或修改角色或角色綁定。
- 視圖（View）：視圖角色允許在給定的命名空間內(nèi)進(jìn)行只讀訪問。它不允許查看或修改角色或角色綁定。
3.角色綁定和集群角色綁定
要將角色應(yīng)用于主題（用戶/組/服務(wù)帳號），必須定義角色綁定。這將使用角色配置中定義的權(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提供的默認(rèn)超級用戶集群角色引用，而不是使用自定義角色。這可以應(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.ioKubernetes RBAC的好處
Kubernetes RBAC的優(yōu)勢在于它允許“原生”實(shí)現(xiàn)對集群中各種用戶和機(jī)器的最小權(quán)限。主要的好處是：
1.適當(dāng)?shù)氖跈?quán)
通過對各種用戶和服務(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將始終有助于組織中用戶(例如開發(fā)人員、DevOps、測試人員、SRE等)的職責(zé)分離。例如，為了在開發(fā)環(huán)境中創(chuàng)建/刪除新資源，開發(fā)人員不應(yīng)該依賴于管理員。同樣，將新應(yīng)用程序部署到測試服務(wù)器并在測試后刪除pod不應(yīng)該成為DevOps或測試人員的瓶頸。將授權(quán)和權(quán)限應(yīng)用到用戶(如開發(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)
對于中小型企業(yè)來說，使用Kubernetes RBAC是合理的，但不建議使用Kubernetes RBAC，其原因如下：
- 可能有許多用戶和機(jī)器，并且應(yīng)用Kubernetes RBAC可能難以實(shí)現(xiàn)和維護(hù)。
- 很難看到誰執(zhí)行了什么操作。例如，大型企業(yè)可能需要諸如違反RBAC權(quán)限或惡意嘗試之類的信息。
原文標(biāo)題：What Is Kubernetes RBAC and Why Do You Need It?，作者：Debasree Panda
網(wǎng)站欄目：什么是Kubernetes?RBAC？為什么需要它？
網(wǎng)頁地址：http://www.5511xx.com/article/dhjggej.html
