訪問控制概述
API Server作為Kubernetes集群系統(tǒng)的網(wǎng)關滥朱，是訪問和管理資源對象的唯一入口根暑；包括kube-controller-manager、kube-scheduler徙邻、kubelet和kube-proxy等集群基礎組件排嫌、CoreDNS等附加組件和kubectl命令等都需要經(jīng)過網(wǎng)關才能進行正常的訪問和管理。每一次的訪問請求都需要進行合法性檢驗缰犁，包括用戶身份驗證淳地、操作權限驗證及操作規(guī)范驗證等，需要通過一系列驗證通過之后才能訪問或存儲數(shù)據(jù)到etcd中帅容。如下圖所示
通過上圖可以看出訪問kubernetes集群的資源需要三關：認證颇象、授權、準入控制并徘；API Server處理請求的過程中遣钳，認證插件負責鑒定用戶身份，授權插件用于操作權限許可鑒別麦乞，而準入插件則用于在資源對象的創(chuàng)建蕴茴、刪除、更新或連接（proxy）操作時實現(xiàn)更精細的許可檢查姐直。
普通用戶若要安全訪問集群API Server倦淀，往往需要證書、Token或者用戶名+密碼声畏。
ServiceAccount
Servic Account（服務賬號）：是指由Kubernetes API管理的賬號晃听，用于為Pod之中的服務進程在訪問Kubernetes API時提供身份標識。Service Account通常綁定于特定的名稱空間砰识，由API Server創(chuàng)建能扒，或者通過API調用手動創(chuàng)建。
User Account（用戶賬號）：獨立于Kubernetes之外的其他服務管理用戶賬號辫狼，例如由管理員分發(fā)秘鑰初斑、Keystone一類的用戶存儲（賬號庫）、甚至是保函有用戶名和密碼列表的文件等膨处。
- User Account是為人設計的见秤，而Service Account則是為Pod中的進程調用Kubernetes API而設計砂竖；
- User Account是跨namespace的，而Service Account則是僅局限它所在的namespace鹃答；
- 每個namespace都會自動創(chuàng)建一個default service account
在創(chuàng)建Pod資源時乎澄，如果沒有指定一個service account，系統(tǒng)會自動在與該Pod相同的namespace下為其指派一個default service account测摔。而pod和apiserver之間進行通信的賬號置济，稱為serviceAccountName。如下：
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-statefulset-0 1/1 Running 0 43h
nginx-statefulset-1 1/1 Running 0 43h
nginx-statefulset-2 1/1 Running 0 43h
nginx-statefulset-3 1/1 Running 0 43h
[root@k8s-master ~]# kubectl get pods/nginx-statefulset-0 -o yaml |grep "serviceAccountName"
serviceAccountName: default
[root@k8s-master ~]# kubectl describe pods/nginx-statefulset-0
Name: nginx-statefulset-0
Namespace: default
......
Volumes:
default-token-blm9l:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-blm9l
Optional: false
通過上面可以看出每個Pod無論定義與否都會有一個存儲卷锋八，這個存儲卷為default-token-* token令牌浙于，這就是Pod和serviceaccount認證信息。通過secret進行定義挟纱，由于認證信息屬于敏感信息羞酗，所以需要保存在secret資源當中，并以存儲卷的方式掛載到Pod當中紊服。從而讓Pod內運行的應用通過對應的secret中的信息來連接apiserver檀轨，并完成認證。每個namespace中都有一個默認的叫做default的service account資源欺嗤。進行查看名稱空間內的secret参萄，也可以看到對應的default-token。讓當前名稱空間中所有的pod在連接apiserver時可以使用的預制認證信息剂府，從而保證pod之間的通信拧揽。
Service Account創(chuàng)建
[root@k8s-master ~]# kubectl get sa #查看serviceaccount資源
NAME SECRETS AGE
default 1 7d19h
[root@k8s-master ~]# kubectl create serviceaccount admin #創(chuàng)建一個名為admin的serviceaccount資源
serviceaccount/admin created
[root@k8s-master ~]# kubectl get sa #查看serviceaccount資源
NAME SECRETS AGE
admin 1 7s
default 1 7d19h
[root@k8s-master ~]# kubectl describe sa/admin #查看serviceaccount資源admin的詳細信息，可以看出已經(jīng)自動生成了一個Tokens：admin-token-lc826
Name: admin
Namespace: default
Labels: <none>
Annotations: <none>
Image pull secrets: <none>
Mountable secrets: admin-token-lc826
Tokens: admin-token-lc826
Events: <none>
[root@k8s-master ~]# kubectl get secret #查看secret腺占，可以查看也生成了一個admin-token-lc826的secret資源
NAME TYPE DATA AGE
admin-token-lc826 kubernetes.io/service-account-token 3 50s
......
Pod中引用service account
每個Pod對象均可附加其所屬名稱空間中的一個Service Account資源淤袜，且只能附加一個。不過衰伯，一個Service Account資源可由所屬名稱空間中的多個Pod對象共享使用铡羡。創(chuàng)建Pod時，通過“spec.serviceAccountName”進行定義意鲸。示例如下：
[root@k8s-master manfests]# vim pod-sa-demo.yaml #編輯資源清單文件
apiVersion: v1
kind: Pod
metadata:
name: pod-sa-demo
namespace: default
labels:
app: myapp
tier: frontend
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
serviceAccountName: admin #指定serviceAccount資源名稱
[root@k8s-master manfests]# kubectl apply -f pod-sa-demo.yaml
pod/pod-sa-demo created
[root@k8s-master manfests]# kubectl get pods -l app=myapp
NAME READY STATUS RESTARTS AGE
pod-sa-demo 1/1 Running 0 9s
[root@k8s-master manfests]#
[root@k8s-master manfests]# kubectl describe pods/pod-sa-demo
Name: pod-sa-demo
Namespace: default
......
Volumes:
admin-token-lc826:
Type: Secret (a volume populated by a Secret)
SecretName: admin-token-lc826 #這里可以看出掛載token就是上面創(chuàng)建的sa所生成的那個烦周。
Optional: false
......
客戶端配置文件kubeconfig
包括kubectl、kubelet和kube-controller-manager等在內的API Server的各類客戶端都可以使用kubeconfig配置文件提供接入多個集群的相關配置信息怎顾，包括API Server的URL及認證信息等读慎，而且能夠設置成不同的上下文環(huán)境，并在各環(huán)境之間快速切換槐雾。
在kubernetes集群中夭委，每一個用戶對資源的訪問都需要通過apiserver進行通信認證才能進行訪問的，那么在此機制當中募强，對資源的訪問可以是token株灸，也可以是通過配置文件的方式進行保存和使用認證信息崇摄，可以通過kubectl config進行查看和配置。如下：
[root@k8s-master]# kubectl config view
apiVersion: v1
clusters: #集群列表
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://192.168.1.31: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
- cluster：集群列表慌烧，包含訪問API Server的URL和所屬集群的名稱等逐抑。
- users：用戶列表，包含訪問API Server時的用戶名和認證信息屹蚊。
- contexts：kubelet的可用上下文列表厕氨，由用戶列表中的某特定用戶名稱和集群列表中的某特定集群名稱組合而成。
通過kubeadm部署的kubernetes集群默認提供了擁有集群管理權限的kubeconfig配置文件/etc/kubernetes/admin.conf淑翼，它可被復制到任何有著kubectl的主機上以用于管理整個集群腐巢。還可以創(chuàng)建基于SSL/TLS認證的自定義賬號品追，以授予非管理員級別的集群資源使用權限玄括。配置過程由兩部分組成，一是為用戶創(chuàng)建專用私鑰及證書文件肉瓦，而是將其配置與kubeconfig文件中遭京。
自建證書和賬號進行訪問apiserver示例
1）為目標用戶賬號kube-user1創(chuàng)建私鑰及證書文件，保存于/etc/kubernetes/pki目錄中
(1)生成私鑰泞莉，權限設置為600
[root@k8s-master ~]# cd /etc/kubernetes/pki/
[root@k8s-master pki]# (umask 077; openssl genrsa -out kube-user1.key 2048)
Generating RSA private key, 2048 bit long modulus
...................................................................................................................+++
.+++
e is 65537 (0x10001)
[root@k8s-master pki]# ll kube-user1.key
-rw------- 1 root root 1679 10月 16 15:01 kube-user1.key
(2)創(chuàng)建證書簽署請求哪雕，-subj選項中的CN的值將被kubeconfig作為用戶名使用，O的值將被識別為用戶組
[root@k8s-master pki]# openssl req -new -key kube-user1.key -out kube-user1.csr -subj "/CN=kube-user1/O=kubernetes"
(3)基于kubeadm安裝Kubernetes集群時生成的CA簽署證書鲫趁，這里設置其有效時長為3650天
[root@k8s-master pki]# openssl x509 -req -in kube-user1.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out kube-user1.crt -days 3650
Signature ok
subject=/CN=kube-user1/O=kubernetes
Getting CA Private Key
(4)驗證證書信息
[root@k8s-master pki]# openssl x509 -in kube-user1.crt -text -noout
2）使用默認的管理員kubernetes-admin@kubernetes為新建的kube-user1設定kube-config配置文件斯嚎。配置結果默認保存于當前系統(tǒng)用戶的.kube/config文件中。
(1)添加用戶到認證
[root@k8s-master pki]# kubectl config set-credentials kube-user1 --embed-certs=true --client-certificate=/etc/kubernetes/pki/kube-user1.crt --client-key=/etc/kubernetes/pki/kube-user1.key
User "kube-user1" set.
(2)配置context挨厚，用來組合cluster和credentials堡僻，即訪問的集群的上下文
[root@k8s-master pki]# kubectl config set-context kube-user1@kubernetes --cluster=kubernetes --user=kube-user1
Context "kube-user1@kubernetes" created.
(3)查看配置文件信息
[root@k8s-master pki]# kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://192.168.1.31:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: kube-user1
name: kube-user1@kubernetes
- context:
cluster: kubernetes
user: kubernetes-admin
name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kube-user1
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
- name: kubernetes-admin
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
(4)指定要使用的上下文，切換為kube-user1訪問集群
[root@k8s-master pki]# kubectl config use-context kube-user1@kubernetes
Switched to context "kube-user1@kubernetes".
(5)測試訪問kubernetes的資源
[root@k8s-master pki]# kubectl get pods
Error from server (Forbidden): pods is forbidden: User "kube-user1" cannot list resource "pods" in API group "" in the namespace "default"
從上面的測試疫剃，當切換為kube-user1用戶進行訪問集群時钉疫，由于kube-user1用戶沒有管理集群的權限，所以在獲取pods資源信息時巢价，會提示Forbidden牲阁。
RBAC-基于角色的訪問控制
介紹RBAC
RBAC（Role-Based Access Control，基于角色的訪問控制）是一種新型壤躲、靈活且使用廣泛的訪問控制機制城菊，它將權限授予“角色”(role)之上，這一點有別于傳統(tǒng)訪問機制中將權限直接賦予使用者的方式碉克。
在RBAC中凌唬，用戶（User）就是一個可以獨立訪問計算機系統(tǒng)中的數(shù)據(jù)或者用數(shù)據(jù)表示的其他資源的主體（Subject）。角色是指一個組織或任務中的工作或者位置棉胀，它代表一種權利法瑟、資格和責任冀膝。許可（Permission）就是允許對一個或多個客體（Object）執(zhí)行的操作。一個用戶可以經(jīng)授權而擁有多個角色霎挟，一個角色可由多個用戶構成窝剖；每個角色可擁有多種許可，每個許可也可授權給多個不同的角色酥夭。每個操作可施加于多個客體（受控對象）赐纱，每個客體也可以接受多個操作。
RBAC簡單來說就是讓一個用戶（Users）扮演一個角色（Role）熬北，角色擁有權限疙描，讓用戶綁定該角色；隨后在授權機制中讶隐，只需要將權限授權給某個角色起胰，此時用戶將獲取對應角色的權限，從而實現(xiàn)角色的訪問控制巫延。
RBAC授權規(guī)則
RBAC授權規(guī)則是通過四種資源來進行配置的效五，他們可以分為兩個組：
- Role（角色）和ClusterRole（集群角色），它們指定了在資源上可以執(zhí)行哪些動作炉峰。
- RoleBinding（角色綁定）和ClusterRoleBinding（集群角色綁定）畏妖，它們將上述角色綁定到特定的用戶、組或ServiceAccounts上疼阔。
角色定義了可以做什么操作戒劫，而綁定定義了誰可以做這些操作，如下圖所示：
綁定關系：
角色和集群角色婆廊，或者角色綁定和集群角色綁定之間的區(qū)別在于角色和角色綁定是名稱空間級別迅细，而集群角色和集群角色綁定是集群級別的資源。
RoleBind--Role：在kubernetes授權機制中否彩，采用RBAC的方式進行授權疯攒，把對象的操作權限定義到一個角色當中，而將用戶綁定到該角色列荔，從而使得用戶得到對應角色的權限敬尺。比如下圖，當用戶（User1）綁定到Role角色當中贴浙，User1就獲取了對應的NamespaceA的操作權限砂吞，但是對于NamespaceB是沒有權限進行操作的。如get崎溃，list等操作蜻直。
ClusterRoleBind--ClusterRole：集群級別的授權，定義一個集群角色（ClusterRole），對集群內的所有資源都有可操作的權限概而，如下圖(只看藍色的線連接)呼巷，當用戶（User1）通過ClusterRolebinding到ClusterRole，從而User1遍擁有了集群的操作權限赎瑰。
-
RoleBind-ClusterRole：這種方式進行綁定時王悍，用戶僅能獲取當前名稱空間的所有權限。為什么這么繞呢餐曼？压储？ 舉例有10個名稱空間，每個名稱空間都需要一個管理員源譬，而每個管理員的權限是一致的集惋。那么此時需要去定義這樣的管理員，使用RoleBinding就需要創(chuàng)建10個Role踩娘，這樣顯得更加繁重刮刑。為了當使用RoleBinding去綁定一個ClusterRole時，該User僅僅擁有對當前名稱空間的集群操作權限霸饲，也就是此時只需要創(chuàng)建一個ClusterRole就解決了以上的需求为朋。比如下圖中的User2和User3用戶雖然綁定了ClusterRole臂拓，但是他們也只有自己的名稱空間NamespaceB中權限厚脉。
Kubernetes RBAC示例
這里由于要切換用戶，使用root用戶同時不停的在kubernetes-admin用戶和上面創(chuàng)建的kube-user1用戶之間進行測試胶惰。故這里創(chuàng)建一個測試用戶打開另外一個終端進行測試傻工。
[root@k8s-master ~]# useradd ik8s
[root@k8s-master ~]# cp -rp .kube/ /home/ik8s/
[root@k8s-master ~]# chown -R ik8s.ik8s /home/ik8s/
[root@k8s-master ~]# su - ik8s
[ik8s@k8s-master ~]$ kubectl config use-context kube-user1@kubernetes
Switched to context "kube-user1@kubernetes".
[ik8s@k8s-master ~]$ kubectl config view
......
current-context: kube-user1@kubernetes #這里可以看到當前已經(jīng)切換到kube-user1用戶了
......
[ik8s@k8s-master ~]$ kubectl get pods #測試kube-user1用戶的權限，可以看出目前它沒有任何權限
Error from server (Forbidden): pods is forbidden: User "kube-user1" cannot list resource "pods" in API group "" in the namespace "default"
User --> Rolebinding --> Role
1）角色（Role）創(chuàng)建孵滞。（說明：一個Role對象只能用于授予對某一單一名稱空間中資源的訪問權限）
[root@k8s-master ~]# kubectl create role -h #查看role創(chuàng)建幫助
......
Usage:
kubectl create role NAME --verb=verb --resource=resource.group/subresource
[--resource-name=resourcename] [--dry-run] [options]
--verb #指定權限
--resource #指定資源或者資源組
--dry-run #干跑模式并不會創(chuàng)建
[root@k8s-master ~]# kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run -o yaml #干跑模式查看role的定義格式
apiVersion: rbac.authorization.k8s.io/v1
kind: Role #資源類型
metadata:
creationTimestamp: null
name: pods-reader #資源名稱
rules:
- apiGroups: #定義對哪些api組內的資源可以進行操作
- ""
resources: #定義對哪些資源可以進行操作
- pods
verbs: #定義操作的權限
- get
- list
- watch
[root@k8s-master ~]# cd manfests/
[root@k8s-master manfests]# kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run -o yaml > role-demo.yaml
[root@k8s-master manfests]# 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@k8s-master manfests]# kubectl apply -f role-demo.yaml
role.rbac.authorization.k8s.io/pods-reader created
[root@k8s-master manfests]# kubectl get role
NAME AGE
pods-reader 4s
[root@k8s-master manfests]# 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的權限坊饶。
2）角色的綁定泄伪。（RoleBinding可以引用在同一名稱空間定義的Role對象）
[root@k8s-master manfests]# kubectl create rolebinding -h #查看rolebinding創(chuàng)建幫助
......
Usage:
kubectl create rolebinding NAME --clusterrole=NAME|--role=NAME
[--user=username] [--group=groupname]
[--serviceaccount=namespace:serviceaccountname] [--dry-run] [options]
--role #指定role的名字
--user #指定哪個用戶
[root@k8s-master manfests]# kubectl create rolebinding kube-user1-read-pods --role=pods-reader --user=kube-user1 --dry-run -o yaml #干跑模式查看rolebinding的定義格式
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding #資源類型
metadata:
creationTimestamp: null
name: kube-user1-read-pods #資源名稱
roleRef: #指定role
apiGroup: rbac.authorization.k8s.io
kind: Role
name: pods-reader
subjects: #指定user
- apiGroup: rbac.authorization.k8s.io
kind: User
name: kube-user1
[root@k8s-master manfests]# kubectl create rolebinding kube-user1-read-pods --role=pods-reader --user=kube-user1 --dry-run -o yaml > rolebinding-demo.yaml
[root@k8s-master manfests]# vim rolebinding-demo.yaml #編輯資源清單文件
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: kube-user1-read-pods
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: pods-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: kube-user1
[root@k8s-master manfests]# kubectl apply -f rolebinding-demo.yaml
rolebinding.rbac.authorization.k8s.io/kube-user1-read-pods created
[root@k8s-master manfests]# kubectl get rolebinding
NAME AGE
kube-user1-read-pods 9s
[root@k8s-master manfests]# kubectl describe rolebinding kube-user1-read-pods #查看角色綁定的信息，這里可以看到user kube-user1綁定到了pods-reader這個角色上匿级。
Name: kube-user1-read-pods
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"RoleBinding","metadata":{"annotations":{},"name":"kube-user1-read-pods","namespace":"...
Role:
Kind: Role
Name: pods-reader
Subjects:
Kind Name Namespace
---- ---- ---------
User kube-user1
3）權限測試
這時候我們使用kube-user1用戶進行測試
[ik8s@k8s-master ~]$ kubectl config use-context kube-user1@kubernetes #如果沒有切換到該kube-user1用戶蟋滴，通過kubectl config use-context進行切換
[ik8s@k8s-master ~]$ kubectl get pods #在default名稱空間獲取pods信息
NAME READY STATUS RESTARTS AGE
nginx-statefulset-0 1/1 Running 0 3d
nginx-statefulset-1 1/1 Running 0 3d
nginx-statefulset-2 1/1 Running 0 3d
nginx-statefulset-3 1/1 Running 0 3d
pod-sa-demo 1/1 Running 0 27h
[ik8s@k8s-master ~]$ kubectl get pods -n kube-system #測試獲取kube-system名稱空間中的pods
Error from server (Forbidden): pods is forbidden: User "kube-user1" cannot list resource "pods" in API group "" in the namespace "kube-system"
從上面的操作可以看出，role的定義和綁定痘绎，僅作用于當前名稱空間津函，在獲取別的名稱空間比如kube-system名稱空間時，一樣會出現(xiàn)Forbidden孤页。
User --> ClusterRolebinding --> ClusterRole
1）ClusterRole定義
ClusterRole資源對象可以授予與Role資源對象相同的權限尔苦，但由于它們屬于集群范圍的對象，也可以使用它們授予對以下幾種資源的訪問權限：
- 集群范圍資源（例如節(jié)點，即Node）
- 非資源類型endpoint（例如/api允坚、/healthz等魂那。）
- 跨所有名稱空間的名稱空間資源（例如pod，運行kubectl get pods --all-namespaces來查詢集群中所有的pod）
[root@k8s-master manfests]# kubectl create clusterrole -h #查看clusterrole創(chuàng)建幫助
......
Usage:
kubectl create clusterrole NAME --verb=verb --resource=resource.group
[--resource-name=resourcename] [--dry-run] [options]
--verb #指定權限
--resource #指定資源或者資源組
[root@k8s-master manfests]# kubectl create clusterrole cluster-reader --verb=get,list,watch --resource=pods --dry-run -o yaml #干跑模式查看clusterrole的定義格式
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
creationTimestamp: null
name: cluster-reader
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
[root@k8s-master manfests]# kubectl create clusterrole cluster-reader --verb=get,list,watch --resource=pods --dry-run -o yaml > clusterrole-demo.yaml
[root@k8s-master manfests]# vim clusterrole-demo.yaml #編輯資源清單
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-reader
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
[root@k8s-master manfests]# kubectl apply -f clusterrole-demo.yaml #創(chuàng)建clusterrole
clusterrole.rbac.authorization.k8s.io/cluster-reader created
[root@k8s-master manfests]# kubectl get clusterrole |grep "cluster-reader"
cluster-reader 19s
[root@k8s-master manfests]# kubectl describe clusterrole/cluster-reader
Name: cluster-reader
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRole","metadata":{"annotations":{},"name":"cluster-reader"},"rules":[{"apiGrou...
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
pods [] [] [get list watch]
2）ClusterRoleBinding定義
#這里還是使用kube-user1用戶稠项，所以先將上面的角色綁定信息刪除
[root@k8s-master manfests]# kubectl get rolebinding #查看角色綁定信息
NAME AGE
kube-user1-read-pods 27m
[root@k8s-master manfests]# kubectl delete rolebinding kube-user1-read-pods #刪除前面的綁定
rolebinding.rbac.authorization.k8s.io "kube-user1-read-pods" delete
[ik8s@k8s-master ~]$ kubectl get pods #刪除后再用kube-user1用戶獲取pods資源信息冰寻，就立馬出現(xiàn)Forbidden了
Error from server (Forbidden): pods is forbidden: User "kube-user1" cannot list resource "pods" in API group "" in the namespace "default"
[root@k8s-master manfests]# kubectl create clusterrolebinding -h
Usage:
kubectl create clusterrolebinding NAME --clusterrole=NAME [--user=username]
[--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run]
[options]
--clusterrole #指定clusterrole
--user #指定用戶
[root@k8s-master manfests]# kubectl create clusterrolebinding kube-user1-read-all-pods --clusterrole=cluster-reader --user=kube-user1 --dry-run -o yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
creationTimestamp: null
name: kube-user1-read-all-pods
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: kube-user1
[root@k8s-master manfests]# kubectl create clusterrolebinding kube-user1-read-all-pods --clusterrole=cluster-reader --user=kube-user1 --dry-run -o yaml > clusterrolebinding-demo.yaml
[root@k8s-master manfests]# vim clusterrolebinding-demo.yaml #編輯資源清單文件
cat clusterrolebinding-demo.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: kube-user1-read-all-pods
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: kube-user1
[root@k8s-master manfests]# kubectl apply -f clusterrolebinding-demo.yaml #創(chuàng)建clusterrolebinding
clusterrolebinding.rbac.authorization.k8s.io/kube-user1-read-all-pods created
[root@k8s-master manfests]# kubectl get clusterrolebinding/kube-user1-read-all-pods
NAME AGE
kube-user1-read-all-pods 25s
[root@k8s-master manfests]# kubectl describe clusterrolebinding/kube-user1-read-all-pods #查看clusterrolebinding資源kube-user1-read-all-pods詳細信息，可以看到kube-user1用戶已經(jīng)綁定到clusterrole資源cluster-reader上了皿渗。
Name: kube-user1-read-all-pods
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"rbac.authorization.k8s.io/v1beta1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"name":"kube-user1-read-all-pod...
Role:
Kind: ClusterRole
Name: cluster-reader
Subjects:
Kind Name Namespace
---- ---- ---------
User kube-user1
3）權限測試
[ik8s@k8s-master ~]$ kubectl get pods #角色綁定后再次獲取pods信息斩芭，已經(jīng)可以正常查看
NAME READY STATUS RESTARTS AGE
nginx-statefulset-0 1/1 Running 0 3d1h
nginx-statefulset-1 1/1 Running 0 3d1h
nginx-statefulset-2 1/1 Running 0 3d1h
nginx-statefulset-3 1/1 Running 0 3d1h
pod-sa-demo 1/1 Running 0 28h
[ik8s@k8s-master ~]$ kubectl get pods -n kube-system #切換名稱空間也是可以查看的
NAME READY STATUS RESTARTS AGE
coredns-bccdc95cf-9gsn8 1/1 Running 0 8d
coredns-bccdc95cf-x7m8g 1/1 Running 0 8d
etcd-k8s-master 1/1 Running 0 8d
kube-apiserver-k8s-master 1/1 Running 0 8d
kube-controller-manager-k8s-master 1/1 Running 0 8d
kube-flannel-ds-amd64-gg55s 1/1 Running 0 8d
kube-flannel-ds-amd64-ssr7j 1/1 Running 5 8d
kube-flannel-ds-amd64-w6f9h 1/1 Running 4 8d
kube-proxy-77pbc 1/1 Running 3 8d
kube-proxy-qs655 1/1 Running 3 8d
kube-proxy-xffq4 1/1 Running 0 8d
kube-scheduler-k8s-master 1/1 Running 0 8d
[ik8s@k8s-master ~]$ kubectl delete pods/pod-sa-demo #在進行刪除pod測試時，還是會報Forbidden乐疆，這是因為在授權時就沒授予delete權限的划乖。
Error from server (Forbidden): pods "pod-sa-demo" is forbidden: User "kube-user1" cannot delete resource "pods" in API group "" in the namespace "default"
從上面的操作可以看出，clusterrole的定義和clusterrolebinding的綁定挤土，可以獲取到集群內所有資源的對應權限琴庵。
User --> Rolebinding --> Clusterrole
將用戶kube-user1通過角色綁定（RoleBinding）到集群角色cluster-reader當中，此時kube-user1僅作用于當前名稱空間的所有pods資源的權限仰美。
1）綁定
#首先刪除上面的clusterrolebinding
[root@k8s-master manfests]# kubectl delete clusterrolebinding kube-user1-read-all-pods
clusterrolebinding.rbac.authorization.k8s.io "kube-user1-read-all-pods" deleted
[root@k8s-master manfests]# kubectl create rolebinding kube-user1-read-pods --clusterrole=cluster-reader --user=kube-user1 --dry-run -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
creationTimestamp: null
name: kube-user1-read-pods
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: kube-user1
[root@k8s-master manfests]# kubectl create rolebinding kube-user1-read-pods --clusterrole=cluster-reader --user=kube-user1 --dry-run -o yaml > rolebinding-clusterrole-demo.yaml
[root@k8s-master manfests]# vim rolebinding-clusterrole-demo.yaml #編輯資源清單文件
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: kube-user1-read-pods
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: kube-user1
[root@k8s-master manfests]# kubectl apply -f rolebinding-clusterrole-demo.yaml
rolebinding.rbac.authorization.k8s.io/kube-user1-read-pods created
[root@k8s-master manfests]# kubectl get rolebinding kube-user1-read-pods
NAME AGE
kube-user1-read-pods 32s
[root@k8s-master manfests]# kubectl describe rolebinding kube-user1-read-pods
Name: kube-user1-read-pods
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"RoleBinding","metadata":{"annotations":{},"name":"kube-user1-read-pods","namespace":"...
Role:
Kind: ClusterRole
Name: cluster-reader
Subjects:
Kind Name Namespace
---- ---- ---------
User kube-user1
2）權限測試
[ik8s@k8s-master ~]$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-statefulset-0 1/1 Running 0 3d1h
nginx-statefulset-1 1/1 Running 0 3d1h
nginx-statefulset-2 1/1 Running 0 3d1h
nginx-statefulset-3 1/1 Running 0 3d1h
pod-sa-demo 1/1 Running 0 28h
[ik8s@k8s-master ~]$ kubectl get pods -n kube-system
Error from server (Forbidden): pods is forbidden: User "kube-user1" cannot list resource "pods" in API group "" in the namespace "kube-system"
從上面的操作可以看出迷殿，角色綁定（Rolebinding）和集群角色（ClusterRole）綁定后，用戶只擁有自己當前名稱空間的對應的權限咖杂。
