轉：https://www.kubernetes.org.cn/4062.html

1、RBAC介紹

在Kubernetes中，授權有ABAC（基于屬性的訪問控制）、RBAC（基于角色的訪問控制）、Webhook、Node、AlwaysDeny（一直拒絕）和AlwaysAllow（一直允許）這6種模式。從1.6版本起，Kubernetes 默認啟用RBAC訪問控制策略。從1.8開始，RBAC已作為穩(wěn)定的功能。通過設置–authorization-mode=RBAC，啟用RABC。

在RABC API中，通過如下的步驟進行授權：
1）定義角色：在定義角色時會指定此角色對于資源的訪問控制的規(guī)則；
2）綁定角色：將主體與角色進行綁定，對用戶進行訪問授權。

image.png

1.1 角色和集群角色

在RBAC API中，角色包含代表權限集合的規(guī)則。在這里，權限只有被授予，而沒有被拒絕的設置。在Kubernetes中有兩類角色，即普通角色和集群角色。可以通過Role定義在一個命名空間中的角色，或者可以使用ClusterRole定義集群范圍的角色。一個角色只能被用來授予訪問單一命令空間中的資源。下面是在“default”命令空間中定義了一個名為“pod-reader”的角色，此角色能夠對在“default”命名空間中訪問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)能夠被授予如下資源的權限：

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

下面是授予集群角色讀取秘密字典文件訪問權限的例子：

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 角色綁定和集群角色綁定

角色綁定用于將角色與一個或一組用戶進行綁定，從而實現(xiàn)將對用戶進行授權的目的。主體分為用戶、組和服務帳戶。角色綁定也分為角色普通角色綁定和集群角色綁定。角色綁定只能引用同一個命名空間下的角色。在下面的例子中，在”default”命名空間中角色綁定將‘jane’用戶和“pod-reader”角色進行了綁定，這就授予了“jane”能夠訪問“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
  apiGroup:rbac.authorization.k8s.io
roleRef: #引用的角色
  kind:Role
  name:pod-reader
  apiGroup:rbac.authorization.k8s.io

角色綁定也可以通過引用集群角色授予訪問權限，當主體對資源的訪問僅限于本命名空間，這就允許管理員定義整個集群的公共角色集合，然后在多個命名空間中進行復用。例如，下面的角色綁定引用了集群角色，但是“dave”用戶也僅僅只能讀取“development”命名空間中的secrets資源：

# 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
  apiGroup:rbac.authorization.k8s.io
roleRef:
  kind:ClusterRole
  name:secret-reader
  apiGroup:rbac.authorization.k8s.io

集群角色可以被用來在集群層面和整個命名空間進行授權。下面的示例允許在“manager”組的用戶能夠訪問所有命名空間中的Secret資源。

# 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”角色能夠對“pods”和“pods/log”進行訪問：

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"]

也可以通過resourceNamess指定特定的資源實例，以限制角色只能夠對實例進行訪問控制：

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

在角色綁定主體的例子：
名稱為 “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”的服務帳戶：

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

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

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

所有的服務帳戶：

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

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

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

所有未被認證的用戶 (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

2、命令行工具

Kubernetes可以通過命令工具進行角色綁定。

2.1 kubectl create rolebinding

在指定的命名空間中進行角色綁定：

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

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

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

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

2.2 kubectl create clusterrolebinding

在整個集群中進行角色綁定：

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

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

2）在整個集群中，授予”system:node”集群角色給“kubelet”用戶：

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

3）在整個集群中，授予”view”集群角色給”acme:myapp”服務帳戶：

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

3、服務帳戶權限

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

從最安全到最不安全的順序，方法如下：
1）授予角色給一個指定應用的服務帳戶(最佳實踐)

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

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

2）在一個命名空間授予“view”集群角色給“default”服務帳戶

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

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

當前，在”kube-system“命名空間中，很多插件作為”default“服務帳戶進行運行。為了允許超級用戶訪問這些插件，在“kube-system”命名空間中授予”cluster-admin“角色給”default”帳戶。

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

3）在一個命名空間中，授予角色給所有的服務帳戶：

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

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

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

如果不想按照每個命名空間管理權限，可以在整個集群的訪問進行授權。例如，在整個集群層面，將”view“集群角色授予“sytem:serviceaccounts“：

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

5）在整個集群中授予超級用戶訪問所有的服務帳戶 (強烈不推薦)

如果對訪問權限不太重視，可以授予超級用戶訪問所有的服務帳戶。

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

6）寬松的RBAC權限

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

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