一、RBAC介紹

在Kubernetes中，授權(quán)有ABAC（基于屬性的訪問(wèn)控制）、RBAC（基于角色的訪問(wèn)控制）、Webhook、Node、AlwaysDeny（一直拒絕）和AlwaysAllow（一直允許）這6種模式。
從1.6版本起，Kubernetes 默認(rèn)啟用RBAC訪問(wèn)控制策略。從1.8開(kāi)始，RBAC已作為穩(wěn)定的功能。通過(guò)設(shè)置--authorization-mode=RBAC，啟用RABC。在RABC API中，通過(guò)如下的步驟進(jìn)行授權(quán)：
定義角色：在定義角色時(shí)會(huì)指定此角色對(duì)于資源的訪問(wèn)控制的規(guī)則；
綁定角色：將主體與角色進(jìn)行綁定，對(duì)用戶進(jìn)行訪問(wèn)授權(quán)。

創(chuàng)新互聯(lián)專注于企業(yè)營(yíng)銷型網(wǎng)站建設(shè)、網(wǎng)站重做改版、桐梓網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5技術(shù)、商城建設(shè)、集團(tuán)公司官網(wǎng)建設(shè)、外貿(mào)網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為桐梓等各大城市提供網(wǎng)站開(kāi)發(fā)制作服務(wù)。

1.1、角色和集群角色

在 RBAC API 中，角色包含代表權(quán)限集合的規(guī)則。在這里，權(quán)限只有被授予，而沒(méi)有被拒絕的設(shè)置。在 Kubernetes 中有兩類角色，即普通角色(Role)和集群角色(ClusterRole)?？梢酝ㄟ^(guò)Role定義在一個(gè)命名空間中的角色，或者可以使用ClusterRole定義集群范圍的角色。一個(gè)Role只能被用來(lái)授予訪問(wèn)單一命令空間中的資源。下面是在 default 命令空間中定義了一個(gè)名為 pod-reader 的角色，此角色能夠?qū)υ?default 命名空間中訪問(wèn) Pod：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

ClusterRole可用于授予與Role相同的權(quán)限。他們能夠被授予如下資源的權(quán)限：

• 集群范圍的資源（類似于Node）
• 非資源端點(diǎn)（類似于”/healthz”）
• 集群中所有命名空間的資源（類似Pod）

下面的ClusterRole可用于授予對(duì)任何特定namespaces中的秘密的讀取訪問(wèn)權(quán)限，或跨所有命名空間的訪問(wèn)權(quán)限。

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

1.2、RoleBinding 和 ClusterRoleBinding

角色綁定用于將角色與一個(gè)或一組用戶進(jìn)行綁定，從而實(shí)現(xiàn)將對(duì)用戶進(jìn)行授權(quán)的目的。主體分為用戶、組和服務(wù)帳戶。角色綁定也分為角色普通角色綁定和集群角色綁定。角色綁定只能引用同一個(gè)命名空間下的角色。
在下面的例子中，在 default 命名空間中角色綁定將 jane 用戶和 pod-reader 角色進(jìn)行了綁定，這就授予了 jane 能夠訪問(wèn) default 命名空間下的 Pod。

# This role binding allows "jane" to read pods in the "default" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role #this must be Role or ClusterRole
  name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

角色綁定也可以通過(guò)引用集群角色授予訪問(wèn)權(quán)限，當(dāng)主體對(duì)資源的訪問(wèn)僅限與本命名空間，這就允許管理員定義整個(gè)集群的公共角色集合，然后在多個(gè)命名空間中進(jìn)行復(fù)用。
例如，下面的角色綁定引用了集群角色，但是 dave 用戶也僅僅只能讀取 development 命名空間中的 secret s資源：

# This role binding allows "dave" to read secrets in the "development" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets
  namespace: development # This only grants permissions within the "development" namespace.
subjects:
- kind: User
  name: dave # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

集群角色可以被用來(lái)在集群層面和整個(gè)命名空間進(jìn)行授權(quán)。下面的示例允許在 manager 組的用戶能夠訪問(wèn)所有命名空間中的保密字典資源。

# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind:ClusterRoleBinding
apiVersion:rbac.authorization.k8s.io/v1
metadata:
  name:read-secrets-global
subjects:
- kind:Group
  name:manager
  apiGroup:rbac.authorization.k8s.io
roleRef:
  kind:ClusterRole
  name:secret-reader
  apiGroup:rbac.authorization.k8s.io

1.3、資源

在Kubernets中，主要的資源包括：Pods、Nodes、Services、Deployment、Replicasets、Statefulsets、Namespace、Persistents、Secrets和ConfigMaps等。另外，有些資源下面存在子資源，例如：Pod下就存在log子資源：

GET /api/v1/namespaces/{namespace}/pods/{name}/log

下面的例子顯示， pod-and-pod-logs-reader 角色能夠?qū)?pods 和 pods/log 進(jìn)行訪問(wèn)：

kind:Role
apiVersion:rbac.authorization.k8s.io/v1
metadata:
 namespace:default
 name:pod-and-pod-logs-reader
rules:
- apiGroups:[""]
  resources:["pods","pods/log"]
  verbs:["get","list"]

也可以通過(guò) resourceNamess 指定特定的資源實(shí)例，以限制角色只能夠?qū)?shí)例進(jìn)行訪問(wèn)控制：

kind:Role
apiVersion:rbac.authorization.k8s.io/v1
metadata:
  namespace:default
  name:configmap-updater
rules:
- apiGroups:[""]
  resources:["configmaps"]
  resourceNames:["my-configmap"]
  verbs:["update","get"]

1.4、主體

RBAC授權(quán)中的主體可以是組，用戶或者服務(wù)帳戶。用戶通過(guò)字符串表示，比如“alice”、 “bob@example.com”等，具體的形式取決于管理員在認(rèn)證模塊中所配置的用戶名。system: 被保留作為用來(lái) Kubernetes 系統(tǒng)使用，因此不能作為用戶的前綴。組也有認(rèn)證模塊提供，格式與用戶類似。

在角色綁定主體的例子：

名稱為 “alice@example.com”用戶：

subjects:
- kind:User
  name:"alice@example.com"
  apiGroup:rbac.authorization.k8s.io

名稱為“frontend-admins”的組：

subjects:
- kind:Group
  name:"frontend-admins"
  apiGroup:rbac.authorization.k8s.io

在 kube-system 命名空間中，名稱為“default”的服務(wù)帳戶：

subjects:
- kind:ServiceAccount
  name:default
  namespace:kube-system

在“qa”命名空間中，所有的服務(wù)帳戶：

subjects:
- kind:Group
  name:system:serviceaccounts:qa
  apiGroup:rbac.authorization.k8s.io

所有的服務(wù)帳戶：

subjects:
- kind:Group
  name:system:serviceaccounts
  apiGroup:rbac.authorization.k8s.io

所有被認(rèn)證的用戶 (version 1.5+):

subjects:
- kind:Group
  name:system:authenticated
  apiGroup:rbac.authorization.k8s.io

所有未被認(rèn)證的用戶 (version 1.5+):

subjects:
- kind:Group
  name:system:unauthenticated
  apiGroup:rbac.authorization.k8s.io

所有用戶(version 1.5+):

subjects:
- kind:Group
  name:system:authenticated
  apiGroup:rbac.authorization.k8s.io
- kind:Group
  name:system:unauthenticated
  apiGroup:rbac.authorization.k8s.io

二、命令行工具

Kubernetes可以通過(guò)命令工具進(jìn)行角色綁定。

2.1、kubectl create rolebinding

在指定的命名空間中進(jìn)行角色綁定：

1）在acme命名空間中，將admin集群角色授予bob用戶：

$ kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme

2）在acme命名空間中，將admin集群角色授予acme:myapp服務(wù)帳戶：

$ kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme

2.2、kubectl create clusterrolebinding

在整個(gè)集群中進(jìn)行角色綁定：

1）在整個(gè)集群中，授予cluster-admin集群角色給root用戶：

$ kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root

2）在整個(gè)集群中，授予system:node集群角色給kubelet用戶：

$ kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet

3）在整個(gè)集群中，授予view集群角色給acme:myapp服務(wù)帳戶：

$ kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp

三、服務(wù)帳戶權(quán)限

默認(rèn)情況下，RBAC策略授予控制板組件、Node和控制器作用域的權(quán)限，但是未授予kube-system命名空間外服務(wù)帳戶的訪問(wèn)權(quán)限。這就允許管理員按照需要將特定角色授予服務(wù)帳戶。

從最安全到最不安全的順序，方法如下：

• 1）授予角色給一個(gè)指定應(yīng)用的服務(wù)帳戶(最佳實(shí)踐)

這要求在Pod規(guī)格中指定ServiveAccountName，同時(shí)此服務(wù)帳戶已被創(chuàng)建(通過(guò)API、kubectl create serviceaccount等)。例如，在my-namespace命名空間內(nèi)，授予my-sa服務(wù)帳戶view集群角色：

kubectl create rolebinding my-sa-view \ 
--clusterrole=view \ 
--serviceaccount=my-namespace:my-sa \ 
--namespace=my-namespace

• 2）在一個(gè)命名空間授予view集群角色給default服務(wù)帳戶

如果應(yīng)用沒(méi)有指定serviceAccountName，它將使用default服務(wù)帳戶。例如，例如，在my-namespace命名空間內(nèi)，授予default服務(wù)帳戶view集群角色：

kubectl create rolebinding default-view \ 
--clusterrole=view \ 
--serviceaccount=my-namespace:default \ 
--namespace=my-namespace

當(dāng)前，在 kube-system 命名空間中，很多插件作為 default 服務(wù)帳戶進(jìn)行運(yùn)行。為了允許超級(jí)用戶訪問(wèn)這些插件，在 kube-system 命名空間中授予 cluster-admin 角色給 default 帳戶。

$ kubectl create clusterrolebinding add-on-cluster-admin \ 
--clusterrole=cluster-admin \ 
--serviceaccount=kube-system:default

• 3）在一個(gè)命名空間中，授予角色給所有的服務(wù)帳戶：

如果希望在一個(gè)命名空間中的所有應(yīng)用都擁有一個(gè)角色，而不管它們所使用的服務(wù)帳戶，可以授予角色給服務(wù)帳戶組。例如，在 my-namespace 命名空間中，將 view 集群角色授予 system:serviceaccounts:my-namespace 組：

$ kubectl create rolebinding serviceaccounts-view \ 
--clusterrole=view \ 
--group=system:serviceaccounts:my-namespace \ 
--namespace=my-namespace

• 4）在整個(gè)集群中授予一個(gè)角色給所有的服務(wù)帳戶 (不推薦)

如果不想按照每個(gè)命名空間管理權(quán)限，可以在整個(gè)集群的訪問(wèn)進(jìn)行授權(quán)。例如，在整個(gè)集群層面，將 view 集群角色授予 sytem:serviceaccounts ：

$ kubectl create clusterrolebinding serviceaccounts-view \ 
--clusterrole=view \ 
--group=system:serviceaccounts

• 5）在整個(gè)集群中授予超級(jí)用戶訪問(wèn)所有的服務(wù)帳戶 (強(qiáng)烈不推薦)

如果對(duì)訪問(wèn)權(quán)限不太重視，可以授予超級(jí)用戶訪問(wèn)所有的服務(wù)帳戶。

$ kubectl create clusterrolebinding serviceaccounts-cluster-admin \ 
--clusterrole=cluster-admin \ 
--group=system:serviceaccounts

• 6）寬松的RBAC權(quán)限

下面的策略允許所有的服務(wù)帳戶作為集群管理員。在容器中運(yùn)行的應(yīng)用將自動(dòng)的收取到服務(wù)帳戶證書(shū)，并執(zhí)行所有的API行為。包括查看保密字典恩將和修改權(quán)限，這是不被推薦的訪問(wèn)策略。

$ kubectl create clusterrolebinding permissive-binding \ 
--clusterrole=cluster-admin \ 
--user=admin \ 
--user=kubelet \ 
--group=system:serviceaccounts

官方文檔：https://kubernetes.io/docs/reference/access-authn-authz/rbac/

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

分享名稱：Kubernetes基于RBAC的授權(quán)(十六)-創(chuàng)新互聯(lián)
網(wǎng)頁(yè)地址：http://weahome.cn/article/ccdijs.html