K8S認證、授權與準入控制(RBAC)詳解

相關推薦

本文的kubernetes環境：https://blog.51cto.com/billy98/2350660

RBAC官方文檔：https://kubernetes.io/docs/reference/access-authn-authz/rbac/

前言

1. RBAC (Role-Based Access Control，基于角色的訪問控制）是一種新型、靈活且使用廣泛的訪問控制機制，它將權限授予“角色”（role）之上，這一點有別于傳統訪問控制機制中 將權限直接賦予使用者的方式，簡單點來說就是將權限綁定到role中，然后用戶和role綁定，這樣用戶就擁有了和role一樣的權限。
2. 在任何將資源或服務提供給有限使用者的系統上，認證和授權都是兩個必不可少的功 能，認證用于身份鑒別，而授權則實現權限分派 。 Kubemetes 以插件化的方式實現了這兩種 功能，且分別存在多種可用的插件。 另外，它還支持準入控制機制，用于補充授權機制以實現更精細的訪問控制功能 。
3. API Server 作為 Kubernetes 集群系統的網關，是訪問及管理資源對象的唯一人口，所有需要訪問集群資源的組件，以及此前使用的 kubectl 命令等都要經由此網關進行集群訪問和管理。
4. RBAC使用rbac.authorization.k8s.io API Group 來實現授權決策，允許管理員通過 Kubernetes API 動態配置策略，要啟用RBAC，需要在 apiserver 中添加參數--authorization-mode=RBAC，如果使用的kubeadm安裝的集群，都默認開啟了RBAC，可以通過查看 Master 節點上 apiserver 的靜態Pod定義文件：

   [root@node-01 ~]# cat /etc/kubernetes/manifests/kube-apiserver.yaml 
   ···
   - --authorization-mode=Node,RBAC
   ···

5. 如果是二進制的方式搭建的集群，添加這個參數過后，記得要重啟 apiserver 服務。

RBAC API資源對象

Kubernetes有一個很基本的特性就是它的所有資源對象都是模型化的 API 對象，允許執行增、刪、改、查等操作，比如下面的這下資源：

• Pods
• ConfigMaps
• Deployments
• Nodes
• Secrets
• Namespaces

上面這些資源對象的可能存在的操作有：

• create
• get
• delete
• list
• update
• edit
• watch
• exec

用戶賬戶和用戶組

Kubernetes 并不會存儲由認證插件從客戶端請求中提取出的用戶及所屬組的信息，它們僅僅用于檢驗用戶是否有權限執行其所請求的操作。

客戶端訪問API服務的途徑通常有三種：kubectl、客戶端庫或者直接使用 REST接口進行請求。

而可以執行此類請求的主體也被 Kubernetes 分為兩類：現實中的“人”和 Pod 對象， 它們的用戶身份分別對應于常規用戶 (User Account ）和服務賬號 （ Service Account） 。

• Use Account（用戶賬號）：一般是指由獨立于Kubernetes之外的其他服務管理的用 戶賬號，例如由管理員分發的密鑰、Keystone一類的用戶存儲（賬號庫）、甚至是包 含有用戶名和密碼列表的文件等。Kubernetes中不存在表示此類用戶賬號的對象， 因此不能被直接添加進 Kubernetes 系統中 。
• Service Account（服務賬號）：是指由Kubernetes API 管理的賬號，用于為Pod 之中的服務進程在訪問Kubernetes API時提供身份標識（ identity ） 。Service Account通常要綁定于特定的命名空間，它們由 API Server 創建，或者通過 API 調用于動創建 ，附帶著一組存儲為Secret的用于訪問API Server的憑據。
  

Kubernetes 有著以下幾個內建的用于特殊目的的組 。

• system:unauthenticated ：未能通過任何一個授權插件檢驗的賬號，即未通過認證測 試的用戶所屬的組 。
• system :authenticated ：認證成功后的用戶自動加入的一個組，用于快捷引用所有正常通過認證的用戶賬號。
• system : serviceaccounts ：當前系統上的所有 Service Account 對象。
• system :serviceaccounts :<namespace＞：特定命名空間內所有的 Service Account 對象。

Role和ClusterRole

1. Role是只作用于命名空間級別的，用于定義命名空間內資源權限集合。
2. ClusterRole則用于集群級別的資源權限集合，它們都是標準的 API 資源類型 。
3. 一般來說， ClusterRole 的許可授權作用于整個集群，因此常用于控制 Role 無法生效的資源類型，這包括集群級別的資源（如Nodes）、非資源類型的端點（如／healthz）和作用于所有命名空間的資源（例如跨命名空間獲取任何資源的權限）。

RoleBinding和ClusterRoleBinding

1. RoleBinding用于將Role上的許可權限綁定到一個或一組用戶之上，它隸屬于且僅能作用于一個命名空間。綁定時，可以引用同一名稱中的Role，也可以引用集群級別的 ClusterRole。

2. ClusterRoleBinding則把ClusterRole中定義的許可權限綁定在一個或一組用戶之上，它僅可以引用集群級別的ClusterRole。

3. Role、RoleBinding、ClusterRole和ClusterRoleBinding 的關系如圖 所示 。
   

4. 一個命名空間中可以包含多個Role和RoleBinding對象，類似地，集群級別也可以同時存在多個ClusterRole和ClusterRoleBinding對 象。而一個賬戶也可經由RoleBinding ClusterRoleBinding關聯至多個角色，從而具有多重許可授權。

下面我們來創建一個User Account，測試訪問某些我們授權的資源：

創建k8s User Account

一、創建證書

1. 創建user私鑰

   [root@node-01 ~]# cd /etc/kubernetes/pki/
   [root@node-01 pki]# (umask 077;openssl genrsa -out billy.key 2048)
   Generating RSA private key, 2048 bit long modulus
   .................................................................................+++
   ..................+++
   e is 65537 (0x10001)

2. 創建證書簽署請求
   O=組織信息，CN=用戶名

   [root@node-01 pki]# openssl req -new -key billy.key -out billy.csr -subj "/O=jbt/CN=billy"

3. 簽署證書

   [root@node-01 pki]# openssl  x509 -req -in billy.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out billy.crt -days 365
   Signature ok
   subject=/O=jbt/CN=billy
   Getting CA Private Key

   二、創建配置文件

   創建配置文件主要有以下幾個步驟：

   kubectl config set-cluster --kubeconfig=/PATH/TO/SOMEFILE      #集群配置
   kubectl config set-credentials NAME --kubeconfig=/PATH/TO/SOMEFILE #用戶配置
   kubectl config set-context    #context配置
   kubectl config use-context    #切換context

• --embed-certs=true的作用是不在配置文件中顯示證書信息。
• --kubeconfig=/root/billy.conf用于創建新的配置文件，如果不加此選項,則內容會添加到家目錄下.kube/config文件中，可以使用use-context來切換不同的用戶管理k8s集群。
• context簡單的理解就是用什么用戶來管理哪個集群，即用戶和集群的結合。

創建集群配置

[root@node-01 pki]# kubectl config set-cluster k8s --server=https://10.31.90.200:8443 --certificate-authority=ca.crt --embed-certs=true --kubeconfig=/root/billy.conf
Cluster "k8s" set.

[root@node-01 pki]# kubectl config view --kubeconfig=/root/billy.conf
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://10.31.90.200:8443
  name: k8s
contexts: []
current-context: ""
kind: Config
preferences: {}
users: []

創建用戶配置

[root@node-01 pki]# kubectl config set-credentials billy --client-certificate=billy.crt --client-key=billy.key --embed-certs=true --kubeconfig=/root/billy.conf
User "billy" set.

#查看配置文件
[root@node-01 pki]# kubectl config view --kubeconfig=/root/billy.conf
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://10.31.90.200:8443
  name: k8s
contexts: []
current-context: ""
kind: Config
preferences: {}
users:
- name: billy
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

創建context配置

[root@node-01 pki]# kubectl config set-context billy@k8s --cluster=k8s --user=billy --kubeconfig=/root/billy.conf
Context "billy@k8s" created.

#查看配置文件
[root@node-01 pki]# kubectl config view --kubeconfig=/root/billy.conf
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://10.31.90.200:8443
  name: k8s
contexts:
- context:
    cluster: k8s
    user: billy
  name: billy@k8s
current-context: ""
kind: Config
preferences: {}
users:
- name: billy
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

切換context

[root@node-01 pki]# kubectl config use-context billy@k8s --kubeconfig=/root/billy.conf
Switched to context "billy@k8s".

#查看配置文件
[root@node-01 pki]# kubectl config view --kubeconfig=/root/billy.conf
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://10.31.90.200:8443
  name: k8s
contexts:
- context:
    cluster: k8s
    user: billy
  name: billy@k8s
current-context: billy@k8s
kind: Config
preferences: {}
users:
- name: billy
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

創建系統用戶及k8s驗證文件

[root@node-01 ~]# useradd billy     #創建什么用戶名都可以
[root@node-01 ~]# mkdir /home/billy/.kube
[root@node-01 ~]# cp billy.conf /home/billy/.kube/config
[root@node-01 ~]# chown billy.billy -R /home/billy/.kube/
[root@node-01 ~]# su - billy
[billy@node-01 ~]$ kubectl get pod
Error from server (Forbidden): pods is forbidden: User "billy" cannot list resource "pods" in API group "" in the namespace "default"
#默認新用戶是沒有任何權限的。

創建Role

此role只有pod的get、list、watch權限

[root@node-01 rbac]# cat pods-reader.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pods-reader
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch

[root@node-01 rbac]# kubectl apply -f pods-reader.yaml 
role.rbac.authorization.k8s.io/pods-reader created

創建Rolebinding

用戶billy和role pods-reader的綁定

[root@node-01 rbac]# cat billy-pods-reader.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: billy-pods-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pods-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: billy

[root@node-01 rbac]# kubectl apply -f billy-pods-reader.yaml 
rolebinding.rbac.authorization.k8s.io/billy-pods-reader created

驗證結果

如果沒有指定命名空間的話，默認就是default命名空間。

[billy@node-01 ~]$ kubectl get pod
NAME                         READY   STATUS    RESTARTS   AGE
nginx-demo-95bd675d5-66xrm   1/1     Running   0          18d
tomcat-5c5dcbc885-7vr68      1/1     Running   0          18d

[billy@node-01 ~]$ kubectl -n kube-system get pod
Error from server (Forbidden): pods is forbidden: User "billy" cannot list resource "pods" in API group "" in the namespace "kube-system"

所以我們是可以查看查看default命名空間的pod，但是其他空間的pod是無法查看的。

創建ClusterRole

[root@node-01 rbac]# cat cluster-reader.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-reader
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch

[root@node-01 rbac]# kubectl apply -f cluster-reader.yaml 
clusterrole.rbac.authorization.k8s.io/cluster-reader created

創建ClusterRoleBinding

[root@node-01 rbac]# cat billy-read-all-pods.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: billy-read-all-pods
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: billy

[root@node-01 rbac]# kubectl apply -f billy-read-all-pods.yaml 
clusterrolebinding.rbac.authorization.k8s.io/billy-read-all-pods created

驗證結果

創建了ClusterRole和ClusterRoleBinding后就可以看到所有命名空間的pod了。

[billy@node-01 ~]$ kubectl get pod
NAME                         READY   STATUS    RESTARTS   AGE
nginx-demo-95bd675d5-66xrm   1/1     Running   0          18d
tomcat-5c5dcbc885-7vr68      1/1     Running   0          18d

[billy@node-01 ~]$ kubectl -n kube-system get pod
NAME                                        READY   STATUS    RESTARTS   AGE
canal-gd4qn                                 2/2     Running   0          21d
cert-manager-6464494858-wqpnb               1/1     Running   0          18d
coredns-7f65654f74-89x69                    1/1     Running   0          18d
coredns-7f65654f74-bznrl                    1/1     Running   2          54d
...

ServiceAccount

至于ServiceAccount怎么授權，其實相對user account來說更簡單，只需先創建ServiceAccount，然后創建role或者ClusterRole，最后在RoleBinding或ClusterRoleBinding綁定即可。以下簡單做一個示例，就不在顯示結果了，大家可以自己去驗證。

創建SA

kubectl create sa billy-sa 

創建Role

[root@node-01 rbac]# cat billy-sa-role.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: billy-sa-role
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch

創建Rolebinding

將billy-sa和billy-sa-role的綁定

[root@node-01 rbac]# cat billy-sa-rolebinding.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: billy-sa-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: billy-sa-role
subjects:
- kind: ServiceAccount
  name: billy-sa

驗證結果

創建完SA之后系統會自動創建一個secret，我們可以獲取這個secret里面的token去登錄dashboard，就可以看到相應有權限的資源。

kubectl get secret billy-sa-token-9rc55 -o jsonpath={.data.token} |base64 -d

還可以在創建pod時在pod的spec里指定serviceAccountName，那么這個pod就擁有了對應的權限，具體的就不在演示了。

本次的分享就到此，如有問題歡迎在下面留言交流，希望大家多多關注和點贊，謝謝！