Kubernetes 1.6新特性學習:RBAC授權
概述
Kuberntes中API Server的訪問控制過程圖示如下:
在Kubernetes中,授權(authorization)是在認證(authentication)之後的一個步驟。授權就是決定一個使用者(普通使用者或ServiceAccount)是否有權請求Kubernetes API做某些事情。
之前,Kubernetes中的授權策略主要是ABAC(Attribute-Based Access Control)。對於ABAC,Kubernetes在實現上是比較難用的,而且需要Master Node的SSH和根檔案系統訪問許可權,授權策略發生變化後還需要重啟API Server。
Kubernetes 1.6中,RBAC(Role-Based Access Control)基於角色的訪問控制進入Beta階段。RBAC訪問控制策略可以使用kubectl或Kubernetes API進行配置。使用RBAC可以直接授權給使用者,讓使用者擁有授權管理的許可權,這樣就不再需要直接觸碰Master Node。在Kubernetes中RBAC被對映成API資源和操作。
RBAC API的資源物件
在Kubernetes 1.6中通過啟動引數--authorization-mode=RBAC.API Overview
為API Server啟用RBAC。
使用kubeadm初始化的1.6版本的Kubernetes叢集,已經預設為API Server開啟了RBAC,可以檢視Master Node上API Server的靜態Pod定義檔案:
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep RBAC
---authorization-mode=RBAC
RBAC API定義了四個資源物件用於描述RBAC中使用者和資源之間的連線許可權:
- Role
- ClusterRole
- RoleBinding
- ClusterRoleBinding
Role和ClusterRole
Role是一系列許可權的集合。Role是定義在某個Namespace下的資源,在這個具體的Namespace下使用。ClusterRole與Role相似,只是ClusterRole是整個叢集範圍內使用的。
下面我們使用kubectl列印一下Kubernetes叢集中的Role和ClusterRole:
kubectl get roles --all-namespaces
NAMESPACE NAME AGE
kube-public system:bootstrap-signer-clusterinfo 6d
kube-public system:controller:bootstrap-signer 6d
kube-system extension-apiserver-authentication-reader 6d
kube-system system:controller:bootstrap-signer 6d
kube-system system:controller:token-cleaner 6d
kubectl getClusterRoles
NAME AGE
admin 6d
cluster-admin 6d
edit 6d
flannel 5d
system:auth-delegator 6d
system:basic-user 6d
system:controller:attachdetach-controller 6d
......
system:kube-aggregator 6d
system:kube-controller-manager 6d
system:kube-dns 6d
system:kube-scheduler 6d
system:node 6d
system:node-bootstrapper 6d
system:node-problem-detector 6d
system:node-proxier 6d
system:persistent-volume-provisioner 6d
view 6d
可以看到之前建立的這個Kubernetes叢集中已經內建或建立很多的Role和ClusterRole。
下面在default名稱空間內建立一個名稱為pod-reader的Role,role-pord-reader.yaml檔案如下:
kind:Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace:default
name: pod-reader
rules:
- apiGroups:[""]# "" indicates the core API group
resources:["pods"]
verbs:["get","watch","list"]
kubectl create -f role-pord-reader.yaml
role "pod-reader" created
kubectl get roles
NAME AGE
pod-reader 1m
注意RBAC在Kubernetes 1.6還處於Beta階段,所以API歸屬在rbac.authorization.k8s.io
,上面的apiVersion
為rbac.authorization.k8s.io/v1beta1
。
下面再給一個ClusterRole的定義檔案:
kind:ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups:[""]
resources:["secrets"]
verbs:["get","watch","list"]
RoleBinding和ClusterRoleBinding
RoleBinding把Role繫結到賬戶主體Subject,讓Subject繼承Role所在namespace下的許可權。ClusterRoleBinding把ClusterRole繫結到Subject,讓Subject整合ClusterRole在整個叢集中的許可權。
賬戶主體Subject在這裡還是叫“使用者”吧,包含組group,使用者user和ServiceAccount。
kubectl get rolebinding --all-namespaces
NAMESPACE NAME AGE
kube-public kubeadm:bootstrap-signer-clusterinfo 6d
kube-public system:controller:bootstrap-signer 6d
kube-system system:controller:bootstrap-signer 6d
kube-system system:controller:token-cleaner 6d
kubectl get clusterrolebinding
NAME AGE
cluster-admin 6d
flannel 6d
kubeadm:kubelet-bootstrap 6d
kubeadm:node-proxier 6d
system:basic-user 6d
system:controller:attachdetach-controller 6d
system:controller:certificate-controller 6d
......
system:controller:ttl-controller 6d
system:discovery 6d
system:kube-controller-manager 6d
system:kube-dns 6d
system:kube-scheduler 6d
system:node 6d
system:node-proxier 6d
實際上一個RoleBinding既可以引用相同namespace下的Role;又可以引用一個ClusterRole,RoleBinding引用ClusterRole時使用者繼承的許可權會被限制在RoleBinding所在的namespace下。
kind:RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
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
kind:RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
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
Kubernetes中預設的Role和RoleBinding
API Server已經建立一系列ClusterRole和ClusterRoleBinding。這些資源物件中名稱以system:
開頭的,表示這個資源物件屬於Kubernetes系統基礎設施。也就說RBAC預設的叢集角色已經完成足夠的覆蓋,讓叢集可以完全在
RBAC的管理下執行。修改這些資源物件可能會引起未知的後果,例如對於system:node
這個ClusterRole定義了kubelet程序的許可權,如果這個角色被修改,可能導致kubelet無法工作。
可以使用kubernetes.io/bootstrapping=rbac-defaults
這個label檢視預設的ClusterRole和ClusterRoleBinding:
kubectl get clusterrole -l kubernetes.io/bootstrapping=rbac-defaults
NAME AGE
admin 6d
cluster