kubernetes api的訪問控制

官網地址：https://kubernetes.io/zh/docs/reference/access-authn-authz/authentication/

訪問控制概述

Kubernetes作為一個分布式集群的管理工具，保證集群的安全性是其一個重要的任務。所謂的安全性其實就是保證對Kubernetes的各種客戶端進行認證和鑒權操作。

用戶可以通過 kubectl、客戶端庫（如：client-go）或者通過構造 rest 請求來 訪問 kubernetes api，用戶（User Account）和服務賬戶（ServiceAccount）都可以被鑒權訪問 API，當請求到達 API 時，它會經歷多個階段，如下圖所示：

認證、授權與准入控制

ApiServer是訪問及管理資源對象的唯一入口。任何一個請求訪問ApiServer，都要經過下面三個流程：
● Authentication（認證）：身份鑒別，只有正確的賬號才能夠通過認證
● Authorization（授權）： 判斷用戶是否有權限對訪問的資源執行特定的動作
● Admission Control（准入控制）：用於補充授權機制以實現更加精細的訪問控制功能。

一、認證

如上圖所示認證一共有8種，可以啟動一種或多種認證方式，只要有一種認證方式通過，就不再對其它方式認證，通常啟動 X509 Client Certs 和 Service Accout Tokens 兩種認證方式

1、kubernetes 中的用戶

所有k8s集群有兩類用戶：
● 由k8s管理的服務賬號
● 普通用戶

其中普通用戶是由一個與集群無關的服務通過一下方式之一進行管理的：
● 負責分發私鑰的管理員
● 類似 keystone 、Google Account 或者 gitLab 這類用戶數據庫
● 包含用戶名和密碼列表的文件
Kubernetes 並不包含用來代表普通用戶賬號的對象。 普通用戶的信息無法通過 API 調用添加到集群中。

2、訪問k8s的API Server的客戶端

客戶端分類：
● kubectl: 用戶家目錄中的.kube/config就保存了密鑰相關信息，自動讀取
● pod: pod中的進程需要訪問API Server。如果是人去訪問或編寫的腳本去訪問，這類訪問的帳號為：UserAccount；pod自身訪問時使用的帳號時ServerAccount，生產中后者使用居多。

3、基於CA根證書簽名的雙向數字證書認證方式（X509 Client Certs）

這種認證方式是安全性最高的一種方式，但是同時也是操作起來最麻煩的一種方式。

3.1、HTTPS認證大體分為3個過程：

1. 證書申請和下發

 HTTPS通信雙方的服務器向CA機構申請證書，CA機構下發根證書、服務端證書及私鑰給申請者

2. 客戶端和服務端的雙向認證

 1> 客戶端向服務器端發起請求，服務端下發自己的證書給客戶端，
     客戶端接收到證書后，通過私鑰解密證書，在證書中獲得服務端的公鑰，
     客戶端利用服務器端的公鑰認證證書中的信息，如果一致，則認可這個服務器
 2> 客戶端發送自己的證書給服務器端，服務端接收到證書后，通過私鑰解密證書，
     在證書中獲得客戶端的公鑰，並用該公鑰認證證書信息，確認客戶端是否合法

3. 服務器端和客戶端進行通信

  服務器端和客戶端協商好加密方案后，客戶端會產生一個隨機的秘鑰並加密，然后發送到服務器端。
  服務器端接收這個秘鑰后，雙方接下來通信的所有內容都通過該隨機秘鑰加密

3.2、創建賬戶

# 1、創建證書
[root@k8s-master ~]# cd /etc/kubernetes/pki/
[root@k8s-master pki]# openssl genrsa -out dev.key 2048

# 2、用apiserver的證書去簽署
# 2.1、簽名申請，申請的用戶是dev,組是devgroup
[root@k8s-master pki]# openssl req -new -key dev.key -out dev.csr -subj "/CN=dev/O=devgroup"
# 2.2、簽署證書
[root@k8s-master pki]# openssl x509 -req -in dev.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out dev.crt -days 3650

# 3、設置集群、用戶、上下文信息（每個命令執行前后，請比對~/.kube/config文件內容的變化）
[root@k8s-master pki]# kubectl config set-cluster kubernetes --embed-certs=true --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.30.130:6443

[root@k8s-master pki]# kubectl config set-credentials dev --embed-certs=true --client-certificate=/etc/kubernetes/pki/dev.crt --client-key=/etc/kubernetes/pki/dev.key

[root@master pki]# kubectl config set-context dev@kubernetes --cluster=kubernetes --user=dev

# 4、切換賬戶到dev
[root@master pki]# kubectl config use-context dev@kubernetes

# 5、查看 rook-ceph 下 pod，發現沒有權限
[root@k8s-master pki]# kubectl get pod -n rook-ceph
Error from server (Forbidden): pods is forbidden: User "dev" cannot list resource "pods" in API group "" in the namespace "rook-ceph"

# 6、切換回admin賬戶
[root@master pki]# kubectl config use-context kubernetes-admin@kubernetes

下一章節講授權，到時候再測試權限的功能

4、服務賬戶（ServiceAccount）令牌

服務賬號（Service Account）是一種自動被啟用的用戶認證機制，使用經過簽名的 持有者令牌來驗證請求。該插件可接受兩個可選參數：
● --service-account-key-file 一個包含用來為持有者令牌簽名的 PEM 編碼密鑰。 若未指定，則使用 API 服務器的 TLS 私鑰。
● --service-account-lookup 如果啟用，則從 API 刪除的令牌會被回收。

服務賬號通常由 API 服務器自動創建並通過 ServiceAccount 准入控制器 關聯到集群中運行的 Pod 上。 持有者令牌會掛載到 Pod 中可預知的位置，允許集群內進程與 API 服務器通信。 服務賬號也可以使用 Pod 規約的 serviceAccountName 字段顯式地關聯到 Pod 上。
新建一個名稱空間，系統會自動在這個名稱空間中創建一個名為 default 的 ServiceAccount

說明： serviceAccountName 通常會被忽略，因為關聯關系是自動建立的。

在pod資源文件中，如果你不指定 serviceAccountName ，那么他的值是 default。

[root@k8s-master ~]# kubectl create ns dev
namespace/dev created

# 系統默認建的service account
[root@k8s-master ~]# kubectl get sa -n dev
NAME      SECRETS   AGE
default   1         14s

[root@k8s-master ~]# kubectl describe sa default -n dev
Name:                default
Namespace:           dev
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   default-token-przcv
Tokens:              default-token-przcv
Events:              <none>

[root@k8s-master ~]# kubectl get secret -n dev
NAME                  TYPE                                  DATA   AGE
default-token-przcv   kubernetes.io/service-account-token   3      4m24s

[root@k8s-master ~]# kubectl describe secret default-token-przcv -n dev
Name:         default-token-przcv
Namespace:    dev
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: default
              kubernetes.io/service-account.uid: 3893c194-f931-4463-949b-f021ac4fbe2f

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1066 bytes
namespace:  3 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6Ik1RS0VUYVNaU2kyRDB1Q3JMQklfaUxjNk5jZkZvWF9SY1dKb2huaEFoTUEifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZXYiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoiZGVmYXVsdC10b2tlbi1wcnpjdiIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiMzg5M2MxOTQtZjkzMS00NDYzLTk0OWItZjAyMWFjNGZiZTJmIiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50OmRldjpkZWZhdWx0In0.zTZZkUiDp6NMMm7zBqDAaIqn9JAJYon_VRmKplcJSV4kZuCh9jEuWDPpLxs5V81VIFvg9LosFaA6vnpja-946DyK2v2FGAvxELRPC41kbCGdGYVJn0Sih5R5MfGp57vsVhrR1NxLmSjxi4af7rdfaIes0RmsOfg3I2iGOeqN7t7d-R6ucEUPIc9Krr2Hi6vzlUYeDTpnF73aJXZPQPKb5o8RJZbG5lB7uJ8Hylmw_r21Cw_ouXwt0pOiIcIyJ7-hVZMe0kZejKrPhFrxxeLy3DyxLhYYukeYGozScFspaH62kbBOezTZqum9Vssqdl7ZpNX2aiDWrdHAxWYy1_v6HA

在集群外部使用服務賬號持有者令牌也是完全合法的：
例如：k8s提供的rest api 接口
官網地址：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#list-pod-v1-core
列出namespace下所有的pod：GET /api/v1/namespaces/{namespace}/pods
用postman測試：
講上面的token放入header中，測試結果如下：

說明：這個default的service account沒有權限查看pod資源，所以集群內默認的 pod 也沒有權限通過api-server操作集群資源。

如果不使用默認的default service account，那我們如何創建自定義的service account呢？
創建 dev-sc.yaml 資源文件，內容如下：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dev-sc
  namespace: dev

或者用命令 kubectl create serviceaccount dev-sc -n dev 也可以。
創建sa：

[root@k8s-master sa]# kubectl apply -f dev-sc.yaml 
serviceaccount/dev-sc created

# 查看相關聯的 Secret
[root@k8s-master sa]# kubectl get serviceaccounts dev-sc -n dev -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"dev-sc","namespace":"dev"}}
  name: dev-sc
  namespace: dev
secrets:
- name: dev-sc-token-nb77d

所創建的 Secret 中會保存 API 服務器的公開的 CA 證書和一個已簽名的 JSON Web 令牌（JWT）

[root@k8s-master sa]# kubectl describe secret dev-sc-token-nb77d -n dev
Name:         dev-sc-token-nb77d
Namespace:    dev
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: dev-sc
              kubernetes.io/service-account.uid: 08a07eb1-0d84-437a-8e6c-4f8edb485b18

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1066 bytes
namespace:  3 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6Ik1RS0VUYVNaU2kyRDB1Q3JMQklfaUxjNk5jZkZvWF9SY1dKb2huaEFoTUEifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZXYiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoiZGV2LXNjLXRva2VuLW5iNzdkIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImRldi1zYyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjA4YTA3ZWIxLTBkODQtNDM3YS04ZTZjLTRmOGVkYjQ4NWIxOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZXY6ZGV2LXNjIn0.zAoQU7vtMUBZ6YLN5LDlSwz9iM8yDEo4NEqp2K1roMCJHhnPsl-D_8E-OLxO0byJTf8ADkXpq31bLGiZeCoRWxKjjCh-3jrRM99cVxSTEt8Os2gMitwF3TwGyMTd_bUzHh0SpuNeAkPxXIMJyI5XOq3eHresB71OwVNqJYraa9kdL6Wbd67unR_SLqOCGdryQ3K2YWYmX0zcAtsWqhtwRuaCgIz-56f9l0W6UBYDJvs8Dig5Dx-1p_XMmDmQpuMEpAqNxMvdgaZmVUV2Kwtj1A9LD0hiOS2NdrcZbBD1x9P9Oii2brLZTXOnjFa_YOwWjvTXEeyznHTPHm2iu0Xz2Q

已簽名的 JWT 可以用作持有者令牌，並將被認證為所給的服務賬號。 關於如何在請求中包含令牌，請參閱前文。 通常，這些 Secret 數據會被掛載到 Pod 中以便集群內訪問 API 服務器時使用， 不過也可以在集群外部使用。
服務賬號被身份認證后，所確定的用戶名為 system:serviceaccount:<名字空間>:<服務賬號>， 並被分配到用戶組 system:serviceaccounts 和 system:serviceaccounts:<名字空間>。

警告：由於服務賬號令牌保存在 Secret 對象中，任何能夠讀取這些 Secret 的用戶 都可以被認證為對應的服務賬號。在為用戶授予訪問服務賬號的權限時，以及對 Secret 的讀權限時，要格外小心。

在下一節會講如何授權，下一章節會測試綁定角色權限。

二、授權

授權發生在認證成功之后，通過認證就可以知道請求用戶是誰， 然后Kubernetes會根據事先定義的授權策略來決定用戶是否有權限訪問，這個過程就稱為授權。
每個發送到 ApiServer 的請求都帶上了用戶和資源的信息：比如發送請求的用戶、請求的路徑、請求的動作等，授權就是根據這些信息和授權策略進行比較，如果符合策略，則認為授權通過，否則會返回403錯誤。

API Server目前支持以下幾種授權策略：
● AlwaysDeny：表示拒絕所有請求，一般用於測試
● AlwaysAllow：允許接收所有請求，相當於集群不需要授權流程（Kubernetes默認的策略）
● ABAC：基於屬性的訪問控制，表示使用用戶配置的授權規則對用戶請求進行匹配和控制
● Webhook：通過調用外部REST服務對用戶進行授權
● Node：是一種專用模式，用於對kubelet發出的請求進行訪問控制
● RBAC：基於角色的訪問控制（kubeadm安裝方式下的默認選項）

RBAC(Role-Based Access Control) 基於角色的訪問控制，主要是在描述一件事情：給哪些對象授予了哪些權限

其中涉及到了下面幾個概念：
● 對象：User、Groups、ServiceAccount
● 角色：代表着一組定義在資源上的可操作動作(權限)的集合
● 綁定：將定義好的角色跟用戶綁定在一起

RBAC引入了4個頂級資源對象：
● Role、ClusterRole：角色，用於指定一組權限
● RoleBinding、ClusterRoleBinding：角色綁定，用於將角色（權限）賦予給對象

1、Role、ClusterRole

一個角色就是一組權限的集合，這里的權限都是許可形式的（白名單）。

# Role只能對命名空間內的資源進行授權，需要指定nameapce
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: authorization-role
rules:
- apiGroups: [""]  # 支持的API組列表,"" 空字符串，表示核心API群
  resources: ["pods"] # 支持的資源對象列表
  verbs: ["get", "watch", "list"] # 允許的對資源對象的操作方法列表

上面的資源文件創建了一個角色：authorization-role ，它在dev名稱空間下有用，它對 dev 名稱空間下的 pod 資源具有 get、watch、list操作；

# ClusterRole可以對集群范圍內資源、跨namespaces的范圍資源、非資源類型進行授權
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: authorization-clusterrole
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

需要詳細說明的是，rules 中的參數：
● apiGroups: 支持的API組列表

"","apps", "autoscaling", "batch"

● resources：支持的資源對象列表

"services", "endpoints", "pods","secrets","configmaps","crontabs","deployments","jobs",
"nodes","rolebindings","clusterroles","daemonsets","replicasets","statefulsets",
"horizontalpodautoscalers","replicationcontrollers","cronjobs"

● verbs：對資源對象的操作方法列表
如何查詢資源具有哪些操作：kubectl api-resources -o wide

"get", "list", "watch", "create", "update", "patch", "delete", "exec"

2、RoleBinding、ClusterRoleBinding

角色綁定用來把一個角色綁定到一個目標對象上，綁定目標可以是 User、Group 或者 ServiceAccount。

# RoleBinding可以將同一namespace中的subject綁定到某個Role下，則此subject即具有該Role定義的權限
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: authorization-role-binding
  namespace: default
subjects:
- kind: User
  name: dev
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: authorization-role
  apiGroup: rbac.authorization.k8s.io

# ClusterRoleBinding在整個集群級別和所有namespaces將特定的subject與ClusterRole綁定，授予權限
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: authorization-clusterrole-binding
subjects:
- kind: User
  name: dev
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: authorization-clusterrole
  apiGroup: rbac.authorization.k8s.io

3、將第一章節的3.2小節創建的 dev 賬戶，綁定相關權限

需求：dev 用戶 只能查看 rook-ceph 名稱空間下的pod資源
創建 ceph-watch-role.yaml

# Role只能對命名空間內的資源進行授權，需要指定nameapce
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: rook-ceph
  name: ceph-watch-role
rules:
- apiGroups: [""]  # 支持的API組列表,"" 空字符串，表示核心API群
  resources: ["pods"] # 支持的資源對象列表
  verbs: ["get", "watch", "list"] # 允許的對資源對象的操作方法列表

創建 ceph-watch-role-binding.yaml

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: ceph-watch-role-binding
  namespace: rook-ceph
subjects:
- kind: User
  name: dev
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: ceph-watch-role
  apiGroup: rbac.authorization.k8s.io

應用：kubectl apply -f ceph-watch-role.yaml -f ceph-watch-role-binding.yaml
測試：

# 切換賬戶到dev
[root@master pki]# kubectl config use-context dev@kubernetes
# 可以看到rook-ceph空間下的所有pod
[root@k8s-master sa]# kubectl get pod -n rook-ceph
NAME                                                  READY   STATUS      RESTARTS   AGE
csi-cephfsplugin-hwkll                                3/3     Running     15         6d4h
csi-cephfsplugin-knttk                                3/3     Running     15         6d4h
csi-cephfsplugin-provisioner-ccc6db5bd-7cnlt          6/6     Running     30         6d4h
...

# default 命名空間下的沒有權限查看
[root@k8s-master sa]# kubectl get pod -n default
Error from server (Forbidden): pods is forbidden: User "dev" cannot list resource "pods" in API group "" in the namespace "default"

# 切換回admin賬戶
kubectl config use-context kubernetes-admin@kubernetes

4、將第一章節的第4節創建的服務賬號綁定相關權限

創建 pod-watch-sa-role.yaml

# Role只能對命名空間內的資源進行授權，需要指定nameapce
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: dev
  name: pod-watch-sa-role
rules:
- apiGroups: [""]  # 支持的API組列表,"" 空字符串，表示核心API群
  resources: ["pods"] # 支持的資源對象列表
  verbs: ["get", "watch", "list"] # 允許的對資源對象的操作方法列表

創建角色綁定 pod-watch-sa-role-binding.yaml

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pod-watch-sa-role-binding
  namespace: dev
subjects:
- kind: ServiceAccount
  name: dev-sc
  namespace: dev
roleRef:
  kind: Role
  name: pod-watch-sa-role
  apiGroup: rbac.authorization.k8s.io

應用：kubectl apply -f ceph-watch-sa-role.yaml -f ceph-watch-sa-role-binding.yaml
測試：
查看serviceAccount為dev-sc所創建的 Secret 中會保存 API 服務器的公開的 CA 證書和一個已簽名的 JSON Web 令牌（JWT）：

# 查看相關聯的 Secret
[root@k8s-master sa]# kubectl get serviceaccounts dev-sc -n dev -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"dev-sc","namespace":"dev"}}
  name: dev-sc
  namespace: dev
secrets:
- name: dev-sc-token-nb77d

[root@k8s-master sa]# kubectl describe secret dev-sc-token-nb77d -n dev

獲取到token：

eyJhbGciOiJSUzI1NiIsImtpZCI6Ik1RS0VUYVNaU2kyRDB1Q3JMQklfaUxjNk5jZkZvWF9SY1dKb2huaEFoTUEifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZXYiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoiZGV2LXNjLXRva2VuLW5iNzdkIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImRldi1zYyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjA4YTA3ZWIxLTBkODQtNDM3YS04ZTZjLTRmOGVkYjQ4NWIxOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZXY6ZGV2LXNjIn0.zAoQU7vtMUBZ6YLN5LDlSwz9iM8yDEo4NEqp2K1roMCJHhnPsl-D_8E-OLxO0byJTf8ADkXpq31bLGiZeCoRWxKjjCh-3jrRM99cVxSTEt8Os2gMitwF3TwGyMTd_bUzHh0SpuNeAkPxXIMJyI5XOq3eHresB71OwVNqJYraa9kdL6Wbd67unR_SLqOCGdryQ3K2YWYmX0zcAtsWqhtwRuaCgIz-56f9l0W6UBYDJvs8Dig5Dx-1p_XMmDmQpuMEpAqNxMvdgaZmVUV2Kwtj1A9LD0hiOS2NdrcZbBD1x9P9Oii2brLZTXOnjFa_YOwWjvTXEeyznHTPHm2iu0Xz2Q

測試集群外訪問 dev 空間下的pod 的 rest api 接口：
將token放在請求頭里：

Authorization : Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Ik1RS0VUYVNaU2kyRDB1Q3JMQklfaUxjNk5jZkZvWF9SY1dKb2huaEFoTUEifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZXYiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoiZGV2LXNjLXRva2VuLW5iNzdkIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImRldi1zYyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjA4YTA3ZWIxLTBkODQtNDM3YS04ZTZjLTRmOGVkYjQ4NWIxOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZXY6ZGV2LXNjIn0.zAoQU7vtMUBZ6YLN5LDlSwz9iM8yDEo4NEqp2K1roMCJHhnPsl-D_8E-OLxO0byJTf8ADkXpq31bLGiZeCoRWxKjjCh-3jrRM99cVxSTEt8Os2gMitwF3TwGyMTd_bUzHh0SpuNeAkPxXIMJyI5XOq3eHresB71OwVNqJYraa9kdL6Wbd67unR_SLqOCGdryQ3K2YWYmX0zcAtsWqhtwRuaCgIz-56f9l0W6UBYDJvs8Dig5Dx-1p_XMmDmQpuMEpAqNxMvdgaZmVUV2Kwtj1A9LD0hiOS2NdrcZbBD1x9P9Oii2brLZTXOnjFa_YOwWjvTXEeyznHTPHm2iu0Xz2Q

測試結果如下：

可以獲取到 dev 命名空間下的pod信息了；

如果查看別的名稱空間下的pod，就會報無權限的錯誤。

三、准入控制

通過了前面的認證和授權之后，還需要經過准入控制處理通過之后，apiserver才會處理這個請求。
准入控制是一個可配置的控制器列表，可以通過在Api-Server上通過命令行設置選擇執行哪些准入控制器：

enable-admission-plugins=NodeRestriction,NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,
                      DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds

只有當所有的准入控制器都檢查通過之后，apiserver才執行該請求，否則返回拒絕。
當前可配置的Admission Control准入控制如下：
● NodeRestriction：該准入控制器限制了 kubelet 可以修改的 Node 和 Pod 對象
● AlwaysAdmit：允許所有請求
● AlwaysDeny：禁止所有請求，一般用於測試
● AlwaysPullImages：在啟動容器之前總去下載鏡像
● DenyExecOnPrivileged：它會攔截所有想在Privileged Container上執行命令的請求
● ImagePolicyWebhook：這個插件將允許后端的一個Webhook程序來完成admission controller的功能。
● Service Account：實現ServiceAccount實現了自動化
● SecurityContextDeny：這個插件將使用SecurityContext的Pod中的定義全部失效
● ResourceQuota：用於資源配額管理目的，觀察所有請求，確保在namespace上的配額不會超標
● LimitRanger：用於資源限制管理，作用於namespace上，確保對Pod進行資源限制
● InitialResources：為未設置資源請求與限制的Pod，根據其鏡像的歷史資源的使用情況進行設置
● NamespaceLifecycle：如果嘗試在一個不存在的namespace中創建資源對象，則該創建請求將被拒絕。當刪除一個namespace時，系統將會刪除該namespace中所有對象。
● DefaultStorageClass：為了實現共享存儲的動態供應，為未指定StorageClass或PV的PVC嘗試匹配默認的StorageClass，盡可能減少用戶在申請PVC時所需了解的后端存儲細節
● DefaultTolerationSeconds：這個插件為那些沒有設置forgiveness tolerations並具有notready:NoExecute和unreachable:NoExecute兩種taints的Pod設置默認的“容忍”時間，為5min
● PodSecurityPolicy：這個插件用於在創建或修改Pod時決定是否根據Pod的security context和可用的PodSecurityPolicy對Pod的安全策略進行控制