Kubernetes之（十五）身份認證，授權，准入控制
API Server作為Kubernetes網關，是訪問和管理資源對象的唯一入口，其各種集群組件訪問資源都需要經過網關才能進行正常訪問和管理。每一次的訪問請求都需要進行合法性的檢驗，其中包括身份驗證、操作權限驗證以及操作規范驗證等，需要通過一系列驗證通過之后才能訪問或者存儲數據到etcd當中。如下圖：
ServiceAccount
Service account是為了方便Pod里面的進程調用Kubernetes API或其他外部服務而設計的。它與User account不同:
- User account是為人設計的，而service account則是為Pod中的進程調用Kubernetes API而設計
- User account是跨namespace的，而service account則是僅局限它所在的namespace
- 每個namespace都會自動創建一個default service account
- Token controller檢測service account的創建，並為它們創建secret
- 開啟ServiceAccount Admission Controller后
- 每個Pod在創建后都會自動設置spec.serviceAccount為default（除非指定了其他ServiceAccout）
- 驗證Pod引用的service account已經存在，否則拒絕創建
- 如果Pod沒有指定ImagePullSecrets，則把service account的ImagePullSecrets加到Pod中
- 每個container啟動后都會掛載該service account的token和ca.crt到/var/run/secrets/kubernetes.io/serviceaccount/
當創建 pod 的時候，如果沒有指定一個 service account，系統會自動在與該pod 相同的 namespace 下為其指派一個default service account。而pod和apiserver之間進行通信的賬號，稱為serviceAccountName。如下:
[root@master manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-0 1/1 Running 0 16h
myapp-1 1/1 Running 0 16h
myapp-2 1/1 Running 0 16h
myapp-3 1/1 Running 0 16h
[root@master manifests]# kubectl get pods myapp-0 -o yaml|grep serviceAccountName
serviceAccountName: default
[root@master manifests]# kubectl describe pods myapp-0
......
default-token-dqd2f:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-dqd2f
......
每個Pod無論定義與否都會有個存儲卷，這個存儲卷為default-token-*** token令牌，這就是pod和serviceaccount認證信息。通過secret進行定義，由於認證信息屬於敏感信息，所以需要保存在secret資源當中，並以存儲卷的方式掛載到Pod當中。從而讓Pod內運行的應用通過對應的secret中的信息來連接apiserver，並完成認證。每個 namespace 中都有一個默認的叫做 default 的 service account 資源。進行查看名稱空間內的secret，也可以看到對應的default-token。讓當前名稱空間中所有的pod在連接apiserver時可以使用的預制認證信息，從而保證pod之間的通信。
[root@master manifests]# kubectl get sa
NAME SECRETS AGE
default 1 7d21h
[root@master manifests]# kubectl get sa -n ingress-nginx #所有的名稱空間都存在name是default的serviceAccount
NAME SECRETS AGE
default 1 2d20h
nginx-ingress-serviceaccount 1 2d5h
[root@master manifests]# kubectl get secret
NAME TYPE DATA AGE
default-token-dqd2f kubernetes.io/service-account-token 3 7d21h
mysql-root-password Opaque 1 23h
tomcat-ingress-secret kubernetes.io/tls 2 2d3h
[root@master manifests]# kubectl get secret -n ingress-nginx
NAME TYPE DATA AGE
default-token-fkw6s kubernetes.io/service-account-token 3 2d20h
nginx-ingress-serviceaccount-token-jvlq9 kubernetes.io/service-account-token 3 2d5h
默認的service account 僅僅只能獲取當前Pod自身的相關屬性，無法觀察到其他名稱空間Pod的相關屬性信息。如果想要擴展Pod，假設有一個Pod需要用於管理其他Pod或者是其他資源對象，是無法通過自身的名稱空間的serviceaccount進行獲取其他Pod的相關屬性信息的，此時就需要進行手動創建一個serviceaccount，並在創建Pod時進行定義。那么serviceaccount該如何進行定義呢？？？實際上，service accout也屬於一個kubernetes資源，如下查看service account的定義方式：
[root@master ~]# kubectl explain sa.
KIND: ServiceAccount
VERSION: v1
FIELDS:
apiVersion <string>
imagePullSecrets <[]Object>
kind <string>
metadata <Object>
secrets <[]Object>
創建serviceaccount
[root@master manifests]# kubectl create serviceaccount mysa -o yaml --dry-run #干跑模式，類似ansible的-C檢查語法
apiVersion: v1
kind: ServiceAccount
metadata:
creationTimestamp: null
name: mysa
[root@master manifests]# kubectl create serviceaccount mysa -o yaml --dry-run > serviceaccount.yaml #保存為yaml文件，
[root@master manifests]# cat serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
creationTimestamp: null
name: mysa
[root@master manifests]# kubectl get sa mysa -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"creationTimestamp":null,"name":"mysa","namespace":"default"}}
creationTimestamp: "2019-04-04T06:23:58Z"
name: mysa
namespace: default
resourceVersion: "273220"
selfLink: /api/v1/namespaces/default/serviceaccounts/mysa
uid: 3ab9e525-56a2-11e9-80a7-000c295ec349
secrets:
- name: mysa-token-cxlvc
看到有一個 token 已經被自動創建，並被 service account 引用。設置非默認的 service account，只需要在 pod 的spec.serviceAccountName 字段中將name設置為您想要用的 service account 名字即可。在 pod 創建之初 service account 就必須已經存在，否則創建將被拒絕。需要注意的是不能更新已創建的 pod 的 service account。
自定義serviceaccount
在default名稱空間創建了一個sa為admin
[root@master manifests]# kubectl create sa admin
serviceaccount/admin created
[root@master manifests]# kubectl get sa
NAME SECRETS AGE
admin 1 40s
default 1 7d22h
[root@master manifests]# kubectl describe sa admin
Name: admin
Namespace: default
Labels: <none>
Annotations: <none>
Image pull secrets: <none>
Mountable secrets: admin-token-sswgb
Tokens: admin-token-sswgb
Events: <none>
[root@master manifests]# kubectl get secret
NAME TYPE DATA AGE
admin-token-sswgb kubernetes.io/service-account-token 3 99s
default-token-dqd2f kubernetes.io/service-account-token 3 7d22h
mysql-root-password Opaque 1 23h
tomcat-ingress-secret kubernetes.io/tls 2 2d4h
可以看到已經自動生成了一個 Tokens: admin-token-sswgb
[root@master manifests]# vim pod-sa-demo.yaml #新建pod引用 Tokens: admin-token-sswgb
apiVersion: v1
kind: Pod
metadata:
name: pod-sa-demo
namespace: default
labels:
app: myapp
tier: frontend
annotations:
white.com/created-by: "cluster admin"
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
serviceAccountName: admin #引用剛才創建的sa賬戶
創建並查看
[root@master manifests]# kubectl apply -f pod-sa-demo.yaml
pod/pod-sa-demo created
[root@master manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-0 1/1 Running 0 21h
myapp-1 1/1 Running 0 21h
myapp-2 1/1 Running 0 21h
myapp-3 1/1 Running 0 21h
pod-sa-demo 1/1 Running 0 2s
[root@master manifests]# kubectl describe pods pod-sa-demo
......
Volumes:
admin-token-sswgb: #已經使用藏才創建的admin賬戶的token
Type: Secret (a volume populated by a Secret)
SecretName: admin-token-sswgb
Optional: false
QoS Class: BestEffort
......
在K8S集群當中，每一個用戶對資源的訪問都是需要通過apiserver進行通信認證才能進行訪問的，那么在此機制當中，對資源的訪問可以是token，也可以是通過配置文件的方式進行保存和使用認證信息，可以通過kubectl config進行查看配置，如下：
[root@master manifests]# kubectl config view
apiVersion: v1
clusters: #集群狀態
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://10.0.0.10:6443
name: kubernetes
contexts: #上下文列表
- context: #集群和訪問用戶的映射
cluster: kubernetes
user: kubernetes-admin
name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes #當前上下文
kind: Config
preferences: {}
users: #用戶列表
- name: kubernetes-admin
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
在上面的配置文件當中，定義了集群、上下文以及用戶。其中Config也是K8S的標准資源之一，在該配置文件當中定義了一個集群列表，指定的集群可以有多個；用戶列表也可以有多個，指明集群中的用戶；而在上下文列表當中，是進行定義可以使用哪個用戶對哪個集群進行訪問，以及當前使用的上下文是什么。如圖：定義了用戶kubernetes-admin可以對kubernetes該集群的訪問，用戶kubernetes-user1對Clluster1集群的訪問。
（圖片來源：https://www.cnblogs.com/linuxk/）
自建證書和賬號進行訪問apiserver
生成證書
[root@master manifests]# cd /etc/kubernetes/pki/
[root@master pki]# (umask 077;openssl genrsa -out white.key 2048)
Generating RSA private key, 2048 bit long modulus
..........................................................+++
................................+++
e is 65537 (0x10001)
[root@master pki]# ls -l white.key
-rw------- 1 root root 1679 4月 4 14:49 white.key
使用ca.crt 簽署證書
[root@master pki]# openssl req -new -key white.key -out white.csr -subj "/CN=white" # 證書簽署請求
[root@master pki]# openssl x509 -req -in white.csr -CA ./ca.crt -CAkey ./ca.key -CAcreateserial -out white.crt -days 365 #證書簽署
Signature ok
subject=/CN=white
Getting CA Private Key
[root@master pki]# openssl x509 -in white.crt -text -noout
[root@master pki]# kubectl config set-credentials white --client-certificate=./white.crt --client-key=./white.key --embed-certs=true
User "white" set.
添加到用戶認證
[root@master pki]# kubectl config set-context white@kubernetes --cluster=kubernetes --user=white
Context "white@kubernetes" created.
[root@master pki]# kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://10.0.0.10:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: kubernetes-admin
name: kubernetes-admin@kubernetes
- context:
cluster: kubernetes
user: white
name: white@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
切換賬號
[root@master pki]# kubectl config use-context white@kubernetes
Switched to context "white@kubernetes".
[root@master pki]# kubectl get pods
Error from server (Forbidden): pods is forbidden: User "system:anonymous" cannot list resource "pods" in API group "" in the namespace "default"
當切換成magedu用戶進行訪問集群時，由於magedu該賬戶沒有管理集群的權限，所以在獲取pods資源信息時，會提示Forrbidden。那么下面就再來了解一下怎么對賬戶進行授權.
RBAC簡介
Kubernetes的授權是基於插件形式的，其常用的授權插件有以下幾種：
- Node（節點認證）
- ABAC(基於屬性的訪問控制)
- RBAC（基於角色的訪問控制）
- Webhook（基於http回調機制的訪問控制）
讓一個用戶（Users）扮演一個角色（Role），角色擁有權限，從而讓用戶擁有這樣的權限，隨后在授權機制當中，只需要將權限授予某個角色，此時用戶將獲取對應角色的權限，從而實現角色的訪問控制。如圖：
基於角色的訪問控制（Role-Based Access Control, 即RBAC）使用”rbac.authorization.k8s.io” API Group實現授權決策，允許管理員通過Kubernetes API動態配置策略。
在k8s的授權機制當中，采用RBAC的方式進行授權，其工作邏輯是 把對對象的操作權限定義到一個角色當中，再將用戶綁定到該角色，從而使用戶得到對應角色的權限。此種方式僅作用於名稱空間當中，這是什么意思呢？當User1綁定到Role角色當中，User1就獲取了對該NamespaceA的操作權限，但是對NamespaceB是沒有權限進行操作的，如get，list等操作。
另外，k8s為此還有一種集群級別的授權機制，就是定義一個集群角色（ClusterRole），對集群內的所有資源都有可操作的權限，從而將User2，User3通過ClusterRoleBinding到ClusterRole，從而使User2、User3擁有集群的操作權限。Role、RoleBinding、ClusterRole和ClusterRoleBinding的關系如下圖:
這里有2種綁定ClusterRoleBinding、RoleBinding。也可以使用RoleBinding去綁定ClusterRole。
當使用這種方式進行綁定時，用戶僅能獲取當前名稱空間的所有權限。為什么這么繞呢？？舉例有10個名稱空間，每個名稱空間都需要一個管理員，而該管理員的權限都是一致的。那么此時需要去定義這樣的管理員，使用RoleBinding就需要創建10個Role，這樣顯得更加繁重。為此當使用RoleBinding去綁定一個ClusterRole時，該User僅僅擁有對當前名稱空間的集群操作權限，換句話說，此時只需要創建一個ClusterRole就解決了以上的需求。
注意：RoleBinding僅僅對當前名稱空間有對應的權限。
在RBAC API中，一個角色包含了一套表示一組權限的規則。 權限以純粹的累加形式累積（沒有”否定”的規則）。 角色可以由命名空間（namespace）內的Role對象定義，而整個Kubernetes集群范圍內有效的角色則通過ClusterRole對象實現。
Kubernetes RBAC演示
1、User --> Rolebinding --> Role
創建角色 一個Role對象只能用於授予對某一單一命名空間中資源的訪問權限
語法：
Usage:
kubectl create role NAME --verb=verb --resource=resource.group/subresource
[--resource-name=resourcename] [--dry-run] [options]
--verb指定權限，--resource指定資源或者資源組，--dry-run單跑模式並不會創建
[root@master manifests]# kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run -o yaml #干跑查看定義格式
apiVersion: rbac.authorization.k8s.io/v1
kind: Role #資源類型
metadata:
creationTimestamp: null
name: pods-reader
rules:
- apiGroups: #目標api群組
- ""
resources: #目標資源
- pods
verbs: #操作權限
- get
- list
- watch
[root@master manifests]# kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run -o yaml > role-demo.yaml
[root@master manifests]# vim role-demo.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pods-reader
namespace: default
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
#創建用戶並查看
[root@master manifests]# kubectl apply -f role-demo.yaml
role.rbac.authorization.k8s.io/pods-reader created
[root@master manifests]# kubectl get role
NAME AGE
pods-reader 5s
[root@master manifests]# kubectl describe role pods-reader
Name: pods-reader
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"Role","metadata":{"annotations":{},"name":"pods-reader","namespace":"default"},"rules...
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
pods [] [] [get list watch] #此處已經定義了pods-reader這個角色對pods資源擁有get、list、watch的權限
角色綁定 RoleBinding可以引用在同一命名空間內定義的Role對象。
語法
Usage:
kubectl create rolebinding NAME --clusterrole=NAME|--role=NAME [--user=username]
[--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run] [options]
--role|--clusterrole指定綁定哪個角色，--user指定哪個用戶
[root@master manifests]# kubectl create rolebinding white-read-pod --role=pods-reader --user=white --dry-run -o yaml>rolebinding-demo.yaml
[root@master manifests]# vim rolebinding-demo.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: white-read-pod
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: pods-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: white
[root@master manifests]# kubectl apply -f rolebinding-demo.yaml #創建角色綁定
rolebinding.rbac.authorization.k8s.io/white-read-pod created
[root@master manifests]# kubectl describe rolebinding white-read-pod
Name: white-read-pod
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"RoleBinding","metadata":{"annotations":{},"creationTimestamp":null,"name":"white-read...
Role:
Kind: Role
Name: pods-reader
Subjects:
Kind Name Namespace
---- ---- ---------
User white #查看角色綁定的信息，這里可以看到user：white綁定到了pods-reader這個角色上
[root@master manifests]# kubectl config use-context white@kubernetes #切換white這個用戶，並使用get獲取pods資源信息
Switched to context "white@kubernetes".
[root@master manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-0 1/1 Running 0 4d18h
myapp-1 1/1 Running 0 4d18h
myapp-2 1/1 Running 0 4d18h
myapp-3 1/1 Running 0 4d18h
pod-sa-demo 1/1 Running 0 3d21h
從上面的操作，可以總結出，role的定義和綁定，僅作用於當前名稱空間，在獲取ingress-nginx名稱空間時，一樣會出現Forbidden！！！
[root@master manifests]# kubectl get pods -n ingress-nginx
Error from server (Forbidden): pods is forbidden: User "white" cannot list resource "pods" in API group "" in the namespace "ingress-nginx"
[root@master manifests]# kubectl get pods -n kube-system
Error from server (Forbidden): pods is forbidden: User "white" cannot list resource "pods" in API group "" in the namespace "kube-system"
2、User --> Clusterrolebinding --> Clusterrole
clusterrole定義
ClusterRole對象可以授予與Role對象相同的權限，但由於它們屬於集群范圍對象， 也可以使用它們授予對以下幾種資源的訪問權限：
- 集群范圍資源（例如節點，即node）
- 非資源類型endpoint（例如”/healthz”）
- 跨所有命名空間的命名空間范圍資源（例如pod，需要運行命令kubectl get pods --all-namespaces來查詢集群中所有的pod）
[root@master manifests]# kubectl config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".
[root@master manifests]# kubectl create clusterrole cluster-reader --verb=get,list,watch --resource=pods -o yaml --dry-run >clusterrole-demo.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-reader
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
[root@master manifests]# kubectl apply -f clusterrole-demo.yaml
clusterrole.rbac.authorization.k8s.io/cluster-reader created
這里我們需要切換回kubernetes-admin賬戶，是由於white賬戶不具備創建的權限，這也說明普通用戶是無法進行創建K8S資源的，除非進行授權。如下，我們另開一個終端，將配置到一個普通用戶ik8s上，使其使用white賬戶進行通信
[root@master manifests]# useradd ik8s
[root@master manifests]# cp -rp ~/.kube/ /home/ik8s/
[root@master manifests]# chown -R ik8s.ik8s /home/ik8s/
[root@master manifests]# su - ik8s
[ik8s@master ~]$ kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://10.0.0.10:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: kubernetes-admin
name: kubernetes-admin@kubernetes
- context:
cluster: kubernetes
user: white
name: white@kubernetes
- context:
cluster: ""
user: ""
name: xiaomi
current-context: white@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
- name: white
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
clusterrolebinding定義
#清理原有的rolebinding
[root@master manifests]# kubectl get rolebinding
NAME AGE
white-read-pods 22m
[root@master manifests]# kubectl delete rolebinding white-read-pods
rolebinding.rbac.authorization.k8s.io "white-read-pods" deleted
#刪除后，在ik8s普通用戶上進行獲取pods資源信息，就立馬出現forbidden了
[ik8s@master ~]$ kubectl get pods
Error from server (Forbidden): pods is forbidden: User "white" cannot list resource "pods" in API group "" in the namespace "default"
#創建clusterrolebinding
[root@master manifests]# kubectl create clusterrolebinding white-read-all-pods --clusterrole=cluster-reader --user=white --dry-run -o yaml >clusterrolebinding-demo.yaml
[root@master manifests]# vim clusterrolebinding-demo.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: white-read-all-pods
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: white
[root@master manifests]# kubectl apply -f clusterrolebinding-demo.yaml
clusterrolebinding.rbac.authorization.k8s.io/white-read-all-pods created
[root@master manifests]# kubectl get clusterrolebinding|grep white
white-read-all-pods
[root@master manifests]# kubectl describe clusterrolebinding white-read-all-pods
Name: white-read-all-pods
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"rbac.authorization.k8s.io/v1beta1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"name":"white-read-all-pods"},"...
Role:
Kind: ClusterRole
Name: cluster-reader
Subjects:
Kind Name Namespace
---- ---- ---------
User white
角色綁定后在ik8s終端上進行獲取pods信息，已經不會出現forbidden了
[ik8s@master ~]$ kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-0 1/1 Running 0 4d18h
myapp-1 1/1 Running 0 4d18h
myapp-2 1/1 Running 0 4d18h
myapp-3 1/1 Running 0 4d18h
pod-sa-demo 1/1 Running 0 3d21h
[ik8s@master ~]$ kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-78d4cf999f-6cb69 1/1 Running 0 11d
coredns-78d4cf999f-tflpn 1/1 Running 0 11d
etcd-master 1/1 Running 0 11d
kube-apiserver-master 1/1 Running 0 11d
kube-controller-manager-master 1/1 Running 0 11d
kube-flannel-ds-amd64-gtv85 1/1 Running 0 11d
kube-flannel-ds-amd64-gwbql 1/1 Running 1 11d
kube-flannel-ds-amd64-ml7nf 1/1 Running 0 11d
kube-proxy-ch4vp 1/1 Running 0 11d
kube-proxy-cz2rf 1/1 Running 1 11d
kube-proxy-kdp7d 1/1 Running 0 11d
kube-scheduler-master 1/1 Running 0 11d
但是進行刪除pod就無法進行，因為在授權時是沒有delete權限的
[ik8s@master ~]$ kubectl delete pods myapp-0
Error from server (Forbidden): pods "myapp-0" is forbidden: User "white" cannot delete resource "pods" in API group "" in the namespace "default"
從上面的實驗，我們可以知道對用戶white進行集群角色綁定，用戶white將會獲取對集群內所有資源的對應權限。
3、User --> Rolebinding --> Clusterrole
將white通過rolebinding到集群角色white-read-pods當中，此時，white僅作用於當前名稱空間的所有pods資源的權限
[root@master manifests]# kubectl delete clusterrolebinding white-read-all-pods
clusterrolebinding.rbac.authorization.k8s.io "white-read-all-pods" deleted
[root@master manifests]# kubectl create rolebinding white-read-pods --clusterrole=cluster-reader --user=white --dry-run -oyaml >rolebinding-clusterrole-demo.yaml
[root@master manifests]# vim rolebinding-clusterrole-demo.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: white-read-pods
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: white
[root@master manifests]# kubectl apply -f rolebinding-clusterrole-demo.yaml
rolebinding.rbac.authorization.k8s.io/white-read-pods created
[ik8s@master ~]$ kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-0 1/1 Running 0 4d18h
myapp-1 1/1 Running 0 4d18h
myapp-2 1/1 Running 0 4d18h
myapp-3 1/1 Running 0 4d18h
pod-sa-demo 1/1 Running 0 3d21h
[ik8s@master ~]$ kubectl get pods -n ingress-nginx
Error from server (Forbidden): pods is forbidden: User "white" cannot list resource "pods" in API group "" in the namespace "ingress-nginx"
[ik8s@master ~]$ kubectl get pods -n kube-system
Error from server (Forbidden): pods is forbidden: User "white" cannot list resource "pods" in API group "" in the namespace "kube-system"
[ik8s@master ~]$
RBAC的三種授權訪問
BAC不僅僅可以對user進行訪問權限的控制，還可以通過group和serviceaccount進行訪問權限控制。當我們想對一組用戶進行權限分配時，即可將這一組用戶歸並到一個組內，從而通過對group進行訪問權限的分配，達到訪問權限控制的效果。
從前面serviceaccount我們可以了解到，Pod可以通過 spec.serviceAccountName來定義其是以某個serviceaccount的身份進行運行，當我們通過RBAC對serviceaccount進行訪問授權時，即可以實現Pod對其他資源的訪問權限進行控制。也就是說，當我們對serviceaccount進行rolebinding或clusterrolebinding，會使創建Pod擁有對應角色的權限和apiserver進行通信。如圖：
參考資料
https://www.cnblogs.com/linuxk
馬永亮. Kubernetes進階實戰 (雲計算與虛擬化技術叢書)
Kubernetes-handbook-jimmysong-20181218