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个过程：
- 证书申请和下发
HTTPS通信双方的服务器向CA机构申请证书，CA机构下发根证书、服务端证书及私钥给申请者
- 客户端和服务端的双向认证
1> 客户端向服务器端发起请求，服务端下发自己的证书给客户端，
客户端接收到证书后，通过私钥解密证书，在证书中获得服务端的公钥，
客户端利用服务器端的公钥认证证书中的信息，如果一致，则认可这个服务器
2> 客户端发送自己的证书给服务器端，服务端接收到证书后，通过私钥解密证书，
在证书中获得客户端的公钥，并用该公钥认证证书信息，确认客户端是否合法
- 服务器端和客户端进行通信
服务器端和客户端协商好加密方案后，客户端会产生一个随机的秘钥并加密，然后发送到服务器端。
服务器端接收这个秘钥后，双方接下来通信的所有内容都通过该随机秘钥加密
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的安全策略进行控制
