什么是RBAC？
基于角色的訪問控制讨韭，廣泛使用于各種計(jì)算機(jī)系統(tǒng)
怎么在k8s中使用RBAC能扒？
apiserver啟動(dòng)時(shí)增加 --authorization-mode=RBAC參數(shù)，kubeadm創(chuàng)建的集群缺省添加有此參數(shù)
kube-apiserver --advertise-address=192.168.3.101 --allow-privileged=true --authorization-mode=Node,RBAC --client-ca-file=/etc/kubernetes/pki/ca.crt --enable-admission-plugins=NodeRestriction --enable-bootstrap-token-auth=true --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key --etcd-servers=https://192.168.3.101:2379,https://192.168.3.102:2379,https://192.168.3.103:2379 --insecure-port=0 --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key --requestheader-allowed-names=front-proxy-client --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6443 --service-account-key-file=/etc/kubernetes/pki/sa.pub --service-cluster-ip-range=10.96.0.0/12 --tls-cert-file=/etc/kubernetes/pki/apiserver.crt --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
Role和ClusterRole
Role是命名空間內(nèi)權(quán)限的集合
ClusterRole是集群權(quán)限的集合齿坷，包含命名空間內(nèi)的權(quán)限和其他集群權(quán)限
以下是一個(gè)Role的例子桂肌，Role pod-reader在namespace default中具有g(shù)et/watch/list pods的權(quán)限
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # ""表示核心api group
resources: ["pods"]
verbs: ["get", "watch", "list"]
以下是一個(gè)ClusterRole的例子，ClusterRole secret-reader在所有namespace中具有g(shù)et/watch/list secrets的權(quán)限
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]
Aggregated ClusterRoles
Aggregated ClusterRoles可以將多個(gè)ClusterRoles的權(quán)限結(jié)合到一起,采用的是標(biāo)簽選擇器的方式
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: monitoring
aggregationRule:
clusterRoleSelectors:
- matchLabels:
rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # 由controller manager自動(dòng)填寫
權(quán)限
權(quán)限體現(xiàn)在api URL中針對(duì)各種資源的verbs永淌。有一些資源擁有子資源崎场，例如pod，擁有子資源log.
GET /api/v1/namespaces/{namespace}/pods/{name}/log
Role需要子資源的權(quán)限遂蛀，也需要在resources中聲明
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list"]
也可以使用resourceNames限制到具體的對(duì)象谭跨，常見的verbs有“get”、“delete”李滴、“update”和 “patch” 螃宙。當(dāng)聲明resourceNames，verb不能為list所坯、watch谆扎、create和deletecollection
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: configmap-updater
rules:
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["my-configmap"]
verbs: ["update", "get"]
RoleBinding和ClusterRoleBinding
Binding 就是 用戶和角色之間的綁定關(guān)系，也分為RoleBinding 和ClusterRoleBinding
以下是一個(gè)RoleBinding的例子芹助，用戶jane與Role pod-reader綁定
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: jane # 用戶名大小寫敏感
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role #這里必須是Role或者ClusterRole
name: pod-reader #匹配Role或者ClusterRole
apiGroup: rbac.authorization.k8s.io
以下是另一個(gè)RoleBinding的例子堂湖，用戶dave 與ClusterRole secret-reader綁定闲先。需要注意，RoleBinding是有namespace限制的无蜂，用戶只在 RoleBinding的namespace擁有ClusterRole的權(quán)限
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-secrets
namespace: development
subjects:
- kind: User
name: dave
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io
以下是一個(gè)ClusterRoleBinding的例子伺糠，用戶組 manager與ClusterRole secret-reader綁定
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
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
RoleBinding和ClusterRoleBinding中的roleRef不能修改，想要修改只能刪除重建斥季。
Subjects
Subjects可以是用戶训桶、用戶組和service account。
帶有‘system:’前綴的用戶和用戶組保留給系統(tǒng)使用酣倾，其他名字都可以用
在pod中不聲明spec.serviceAccountName渊迁，則pod會(huì)使用缺省的serviceaccount，一般是default
缺省Role和ClusterRole
所有缺省Role和ClusterRole都用kubernetes.io/bootstrapping=rbac標(biāo)簽灶挟，并使用’system:'前綴標(biāo)識(shí)琉朽。
每次啟動(dòng)，apiserver都會(huì)使用缺省的Role和ClusterRole更新配置稚铣，可以修復(fù)意外修改造成的問題箱叁。
以heapster為例分析serviceAccount RBAC的使用
deployment heapster中使用serviceAccountName heapster
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: heapster
namespace: kube-system
spec:
replicas: 1
template:
metadata:
labels:
task: monitoring
k8s-app: heapster
spec:
serviceAccountName: heapster
containers:
- name: heapster
image: k8s.gcr.io/heapster-amd64:v1.5.4
imagePullPolicy: IfNotPresent
command:
- /heapster
- --source=kubernetes:https://kubernetes.default
- --sink=influxdb:http://monitoring-influxdb.kube-system.svc:8086
ServiceAccount heapster綁定ClusterRole system:heapster
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"rbac.authorization.k8s.io/v1beta1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"name":"heapster"},"roleRef":{"apiGroup":"rbac.authorization.k8s.io","kind":"ClusterRole","name":"system:heapster"},"subjects":[{"kind":"ServiceAccount","name":"heapster","namespace":"kube-system"}]}
creationTimestamp: 2019-05-15T07:17:42Z
name: heapster
resourceVersion: "2275681"
selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/heapster
uid: 87623890-76e1-11e9-bc74-52540005f38a
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:heapster
subjects:
- kind: ServiceAccount
name: heapster
namespace: kube-system
查看ClusterRole system:heapster的權(quán)限
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:
rbac.authorization.kubernetes.io/autoupdate: "true"
creationTimestamp: 2019-04-30T06:52:29Z
labels:
kubernetes.io/bootstrapping: rbac-defaults
name: system:heapster
resourceVersion: "138722"
selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/system%3Aheapster
uid: 85945bd1-6b14-11e9-bc74-52540005f38a
rules:
- apiGroups:
- ""
resources:
- events
- namespaces
- nodes
- pods
verbs:
- get
- list
- watch
- apiGroups:
- extensions
resources:
- deployments
verbs:
- get
- list
- watch
以kubectl為例分析userAccount RBAC的使用
新建用戶panmeng的證書
openssl genrsa -out panmeng.key 2048
openssl req -new -key panmeng.key -out panmeng.csr -subj "/CN=panmeng"
openssl x509 -req -in panmeng.csr -out panmeng.crt -sha1 -CA ca.crt -CAkey ca.key -CAcreateserial -days 3650
新建role及rolebinding,使用戶panmeng 具有 list和get pod的權(quán)限
kubectl create role getpods --verb=get --verb=list --resource=pods
kubectl create rolebinding panmeng-getpods --role=getpods --user=panmeng --namespace=default
修改kubectl配置文件，并切換context
kubectl config set-credentials panmeng --client-certificate=/etc/kubernetes/pki/panmeng.crt --client-key=/etc/kubernetes/pki/panmeng.key --username=panmeng --embed-certs=true
kubectl config set-context --cluster=kubernetes --user=panmeng
kubectl config use-context context-panmeng
驗(yàn)證效果
# kubectl get nodes
Error from server (Forbidden): nodes is forbidden: User "panmeng" cannot list resource "nodes" in API group "" at the cluster scope
# kubectl get pods
NAME READY STATUS RESTARTS AGE
gc-test 0/2 CrashLoopBackOff 1086 47h
testpod-5wtb7 1/1 Running 0 15d
testpod-646d8 1/1 Running 0 15d
testpod-qczvt 1/1 Running 0 15d
# kubectl delete pod gc-test
Error from server (Forbidden): pods "gc-test" is forbidden: User "panmeng" cannot delete resource "pods" in API group "" in the namespace "default"
# kubectl auth can-i list pods
yes
# kubectl auth can-i get pods
yes
# kubectl auth can-i delete pods
no
