RBAC（Role-Based Access Control蹋肮，基于角色的訪問控制）在Kubernetes v1.5引入，在v1.6版本時升級為Beta版本疾棵，并成為kubeadm安裝方式下的默認選項蕊苗，組建其重要程度栗精。相對于其他的訪問控制方式，RBAC具有如下優(yōu)勢彪蓬。
- 對集群中的資源和非資源權(quán)限均有完整的覆蓋寸莫。
- 整個RBAC完全由幾個API對象完成，同其他API對象一樣档冬，可以用kubectl或API進行操作膘茎。
- 可以在運行時進行調(diào)整，無須重新啟動API Server酷誓。
要使用RBAC授權(quán)模式披坏，則需要在API Server的啟動參數(shù)中加上--authorization-mode=RBAC。
下面對RBAC的原理和用法進行說明盐数。
1. RBAC的API資源對象說明
RBAC引入了4個新的頂級資源對象：Role棒拂、ClusterRole、RoleBinding娘扩、ClusterRoleBinding着茸。同其他API資源對象一樣壮锻，用戶可以使用kubectl或者API調(diào)用方式操作這些資源對象琐旁。
角色（Role）
一個角色就是一組權(quán)限的集合，這里的權(quán)限都是許可形式猜绣，不存在拒絕的規(guī)則灰殴。在一個命名空間中，可以用Role來定義一個角色掰邢，如果是集群級別牺陶，就需要使用ClusterRole了。
Role只能對命名空間內(nèi)的資源進行授權(quán)辣之，下面例子中定義的角色具備讀取Pod的權(quán)限：
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace： default
name: pod-reader
rules:
- apiGroups: [""] # ""空字符串掰伸，表示核心API群
resources: ["pods"]
verbs: ["get", "watch", "list"]
rules中的參數(shù)說明：
-
apiGroups： 支持的API組列表，例如“apiVersion: batch/v1”怀估、“apiVersion: extensions:v1beta1”狮鸭、“apiVersion: apps/v1beta1”等。 -
resources：支持的資源對象列表多搀，例如pods歧蕉、deployments、jobs等康铭。 -
verbs：對資源對象的操作方法列表惯退，例如get、watch从藤、list催跪、delete锁蠕、replace、patch等叠荠。
集群角色
集群角色處理具有和角色一致的命名空間內(nèi)資源的管理能力匿沛，因其集群級別的范圍，還可以用于以下特殊元素的授權(quán)榛鼎。
- 集群范圍的資源逃呼，例如Node（節(jié)點）。
- 非資源類型的路徑者娱，例如“/healthz”抡笼。
- 包含全部命名空間的資源，例如pods（用于kubectl get pods --all-namespaces這樣的操作授權(quán)）黄鳍。
下面的ClusterRole可以讓用戶有權(quán)訪問任意一個或所有命名空間的secrets（視其綁定方式而定）：
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
# ClusterRole不受限于命名空間推姻，所以省略了namespace name的定義
name: secret-reader
rules:
- apiGroups: [""] # ""空字符串，表示核心API群
resources: ["secrets"]
verbs: ["get", "watch", "list"]
角色綁定（RoleBinding）和集群角色綁定（ClusterRoleBinding）
RoleBinding或ClusterRoleBinding用來把一個角色綁定到一個目標上框沟，綁定的目標可以是User（用戶）藏古、Group（組）或者Service Account。
使用RoleBinding為某個命名空間授權(quán)忍燥，使用ClusterRoleBinding為集群范圍內(nèi)授權(quán)拧晕。
RoleBinding可以引用Role進行授權(quán)。下面例子中的RoleBinding將在default命名空間中把pod-reader角色授予用戶jane梅垄，這一操作讓jane可以讀取default命名空間中的Pod：
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace: default
name: read-pods
subjects:
- kind: User
name: jane
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
RoleBinding也可以引用ClusterRole厂捞，對屬于同一個命名空間內(nèi)ClusterRole定義的資源主體進行授權(quán)。一種常見的做法是集群管理員為集群范圍預(yù)先定義好一組角色（ClusterRole）队丝，然后在多個命名空間中重復(fù)使用這些ClusterRole靡馁。
例如下面的例子，雖然secret-reader是一個集群角色机久，但是因為使用了RoleBinding臭墨，所以dave只能讀取development命名空間中的secret：
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace: development
name: read-secret
subjects:
- kind: User
name: dave
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io
集群角色綁定中的角色只能是集群角色，用于進行集群級別或者對所有命名空間都生效的授權(quán)膘盖。下面的例子允許manager組的用戶讀取任意namespace中的secret：
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace: development
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
