Kubernetes安全机制

一、kubernetes的安全框架

1.框架

• 流程
  • kubect先请求api资源，然后是过三关
    • 第一关是认证（Authentication）
    • 第二关是授权（Authorization）
    • 第三关是准入控制（Admission Control）
  • 只有通过这三关才可能会被k8s创建资源
• K8S安全控制框架主要由下面3个阶段进行控制，每一个阶段都 支持插件方式，通过API Server配置来启用插件
• 普通用户若要安全访问集群API Server，往往需要证书、Token 或者用户名+密码；Pod访问，需要ServiceAccount

2.机制

• apiserver使用的是token认证

[root@master01 ~]# ps aux | grep apiserver
...
--token-auth-file=/opt/kubernetes/cfg/token.csv 
...

• 可以通过ServiceAccount在pod中去访问apiserver

[root@master01 ~]# kubectl get sa
NAME      SECRETS   AGE
default   1         3d

• 传输安全：告别8080，迎接6443
• 默认8080监听本地（是通过master及其他组件连接使用）

[root@master01 ~]# netstat -ntap | grep 8080 | grep LISTEN
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      1815/kube-apiserver 

• 对外提供服务端口是6443

[root@master01 ~]# netstat -ntap | grep 6443 | grep LISTEN
tcp        0      0 192.168.170.128:6443    0.0.0.0:*               LISTEN      1815/kube-apiserver 

二、三大模块

1.第一模块：认证

1）kubernetes的用户系统

• kubernetes有两种类型的用户
  • ServiceAccount
  • 一般用户

一般用户

• 一般用户被认为是由外部独立的服务(比如公司的员工)管理的
• 例如:一个分发私钥的管理员，一个像Keystone或谷歌帐户这样的用户存储，甚至一个包含用户名和密码列表的文件
• 在这方面，Kubernetes没有表示普通用户帐户的对象。不能通过API调用将普通用户添加到集群中

ServiceAccount

• 服务帐户是由Kubernetes API管理的用户。它们被绑定到特定的名称空间，并由API服务器自动创建或通过API调用手动创建。服务帐户被关联到一组用作凭证的secret中，这些secret凭证被挂载到pod中，允许集群内进程与Kubernetes API通信

• API请求要么绑定到普通用户，要么绑定到服务帐户，要么作为匿名请求处理。这意味着集群内外的每个进程，不论是PC客户端上使用kubectl的人工用户或者节点上的kubelets，再到控制平面的成员，向API服务器发出请求时都必须进行身份验证，或者被视为匿名用户

2)认证

• API SERVER 认证方式(K8S 的所有访问都是通过 api server)
  • 三种客户端身份认证：
    • HTTPS 证书认证：基于CA证书签名的数字证书认证
    • HTTP Token认证：通过一个Token来识别用户（生产环境中使用广泛）
    • HTTP Base认证：用户名+密码的方式认证
  • Authenticating proxy: 第三方授权协议

Https证书认证

[root@master01 ~]# cat /root/k8s/k8s-sert/k8s-cert.sh 
。。。
cat > server-csr.json <

Http Token认证

[root@master01 ~]# cat /opt/kubernetes/cfg/token.csv 
73af5869be7dea86e14a328bb99da139,kubelet-bootstrap,10001,"system:kubelet-bootstrap"

• 原理：token 是一个难以被模仿的字符串, 每个token对应一个用户名, 存放在API server能访问的一个文件中. 当客户端发起API调用时, token放在header中, API 就能识别是否非法

Http Basic认证

• 这种认证方式是把 用户名+冒号+密码 用base64 算法进行编码后放到header中进行身份识别

3）认证策略

• apiserver 拥有一条链式的认证插件, 没个请求被认证插件验证时,插件会试图将请求与以下属性进行关联

用户名(username):标识最终用户的字符串。常见的值可能是kube-admin或[email protected]。

UID:标识最终用户并试图比username更一致和惟一的字符串。

组(group):一组字符串，它将用户与一组通常分组的用户相关联。

额外字段(extra fileds):字符串映射到包含附加信息授权方可能会发现有用的字符串列表

• 所有值对身份验证系统都是不透明的，只有在由授权方( authorizer)使用时才具有意义

• 可以同时启用多个身份验证方法。通常应该使用至少两种方法:

  • 服务帐户(service account) 的服务帐户令牌(service account token)
  • 一种用于用户身份验证的方法

• 当启用多个验证器模块时，第一个模块将成功地验证 “请求短路评估” (request short-circuits evaluation)。，如果验证失败，则进行断路操作，API服务器不保证运行验证器的执行顺序

• 所有通过验证的用户都会被添加进system:authenticated组

• 可以使用authenticating proxy 或authentication webhook与其他身份验证协议(LDAP、SAML、Kerberos、备用x509方案等)集成

3）CA认证

• 涉及的概念：根证书, 自签名证书, 密钥, 私钥, 加密算法
• 认证的步骤：
  • https 通信双方的服务器端, 想CA 机构申请证书. CA 机构下发根证书,服务端证书,私钥给申请者
  • https 通信双方的客户端向CA机构申请证书, CA 机构下发根证书,服务端证书,私钥给申请者
  • 客户端向服务端发起请求,服务端下发服务端证书给客户端,客户端接收到证书后, 通过私钥揭秘证书, 利用服务端证书中的公钥认证证书信息比较证书里的消息. 例如,比较域名和公钥, 与服务器刚发送的相关信息是否一致, 如果一致, 则认为服务端是可信的
  • 客户端发送客户端证书给服务端,服务端通过私钥解密证书,获得客户端公钥,并用该公钥认证证书信息
  • 客户端通过随机密钥加密信息发送给服务端. 服务端和客户端协商好加密方案后,客户端会产生一个随机的密钥,客户端通过协商好的加密方案加密该密钥,并发送该随机密钥给服务端. 服务器接收密钥后, 双方所有内容通过该随机密钥加密
    

2.第二模块：授权

1）Kubernetes的授权模式

• ABAC 授权——基于属性的访问控制(ABAC)定义了一种访问控制范式，通过将属性组合在一起的策略将访问权限授予用户。策略可以使用任何类型的属性(用户属性、资源属性、对象、环境属性等)。有关使用ABAC模式的更多信息，请参见ABAC模式

• RBAC 授权——基于角色的访问控制(RBAC)是一种基于企业中单个用户的角色来调节对计算机或网络资源的访问的方法。在此上下文中，访问是单个用户执行特定任务的能力，例如查看、创建或修改文件。要了解关于使用RBAC模式的更多信息，请参见RBAC模

• 当指定RBAC(基于角色的访问控制)时，使用RBAC.authority .k8s.io API组驱动授权决策，允许管理员通过Kubernetes API动态配置权限策略。
  NODE 授权——一个特殊用途的授权器，根据调度到kubelet所在节点的pod向kubelet授予权限。有关使用节点授权模式的更多信息，请参见节点授权

• WEBHOOK 授权——WebHook是当某个事件发生时触发一个HTTP POST的回调;实现webhook的web应用程序将向URL发送一条消息。有关使用Webhook模式的更多信息，请参见Webhook模式

• 允许所有访问

• 拒绝所有访问

2）授权模式的设置方法

• 在启动apiserver时添加如下参数之一

--authorization-mode=ABAC
--authorization-mode=RBAC
--authorization-mode=Webhook
--authorization-mode=Node
--authorization-mode=AlwaysDeny
--authorization-mode=AlwaysAllow

• Kubernetes只对以下API请求属性进行审查
  

user — 身份验证期间提供的用户字符串。

group — 已验证用户所属的组名称列表。

extra — 由身份验证层提供的任意字符串键到字符串值的映射。

API — 指示请求是否为API资源。

request path — 到其他非资源端点(如/api或/healthz)的路径。

API request verb(动词) — API verb(动词) , get、list、create、update、patch、watch、proxy、redirect、delete和deletecollection用于资源请求。要确定资源API端点的请求谓词，请参见 Determine the request verb.。

HTTP请求动词 — HTTP动词get、post、put和delete用于非资源请求。

resource — 正在访问的资源的ID或名称(仅用于资源请求)——对于使用get、update、patch和delete谓词的资源请求，您必须提供资源名称。

子资源 —— 正在访问的子资源(仅用于资源请求)。

Namespace —— 正在访问的对象的名称空间(仅用于名称空间大小的资源请求)。

API group —— 正在访问的API组(仅用于资源请求)。空字符串指定核心API组

补充一下关于K8S api的一些知识, K8S api 遵守openapi规范. 在K8S的API 设计中,最重要的几个概念就是 api version, api group, resource type , meta, 以及 spec

apiVersion — 您使用Kubernetes API的哪个版本来创建这个对象

kind — 创建什么样的对象

meta —— 帮助惟一标识对象的数据，包括名称字符串、UID和可选名称空间

3.第三模块：准入控制

• 准入控制（Admission Control）在授权后对请求做进一步的验证或添加默认参数，在对kubernetes api服务器的请求过程中，先经过认证、授权后，执行准入操作，在对目标对象进行操作。这个准入插件代码在apiserver中，而且必须被编译到二进制文件中才能被执行

• 在对集群进行请求时，每个准入控制插件都按顺序运行，只有全部插件都通过的请求才会进入系统，如果序列中的任何插件拒绝请求，则整个请求将被拒绝，并返回错误信息

• 在某些情况下，为了适用于应用系统的配置，准入逻辑可能会改变目标对象。此外，准入逻辑也会改变请求操作的一部分相关资源

• Adminssion Control实际上是一个准入控制器插件列表，发送到API Server的请求都需要经过这个列表中的每个准入控制器 插件的检查，检查不通过，则拒绝请求

[root@master01 ~]# ps aux | grep apiserver
...
--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota,NodeRestriction
...

• NamespaceLifecycle： 命令空间回收
• LimitRanger：配额管理
• ServiceAccount： 每个pod中导入方便访问apiserver
• ResourceQuota： 基于命名空间的高级配额管理
• NodeRestriction： Node加入到k8s群集中以最小权限运行

1）为什么需要准入控制

• 在kubernetes中，一些高级特性正常运行的前提条件为，将一些准入模块处于enable状态。总结下，对于kubernetes apiserver，如果不适当的配置准入控制模块，他就不能称作是一个完整的server，某些功能也不会正常的生效

2）如何运行准入控制插件

• 在kubernetes apiserver中有一个flag：admission_control，他的值为一串用逗号连接起、有序的准入模块列表，设置后，就可在对象操作前执行一定顺序的准入模块调用
• 每个插件的作用：

//AlwaysAdmit
结束所有的请求

//AlwaysPullImages
该插件修改每个新的Pod，强制pull最新镜像，这在多租户群集中非常有用，以便私有镜像只能由拥有授权凭据的用户使用

//AlwaysDeny
拒绝所有请求，一般用于测试

//DenyExecOnPrivileged（已弃用）
该插件将拦截所有请求。如果pod有一个privileged container，将只执行这个pod中的命令
如果自己的集群支持privileged container，自己又希望限制用户在这些privileged container上执行命令，那么强烈推荐使用它

此功能已合并到DenyEscalatingExec中

//DenyEscalatingExec
禁止privileged container的exec和attach操作。

//ImagePolicyWebhook
通过webhook决定image策略，需要同时配置--admission-control=ImagePolicyWebhook

//ServiceAccount
该插件将serviceAccounts 实现了自动化。如果打算使用Kubernetes ServiceAccount对象，那么强烈建议使用此插件

//SecurityContextDeny
该插件会将使用了 SecurityContext的pod中定义的选项全部失效 

//ResourceQuota
该插件将会观察传入的所有请求，并确保它不会违反ResourceQuota对象中枚举的任何限制Namespace。如果在Kubernetes Deployment中使用了ResourceQuota对象，则必须使用此插件来约束Container

推荐在Admission Control参数列表中，这个插件排最后一个。

//LimitRanger
该插件将会观察传入的所有请求，并确保它不会违反LimitRanger对象中枚举的任何限制Namespace，如果在Kubernetes Deployment中使用了LimitRanger对象，则必须使用此插件。LimitRanger还可使用Apply将default资源请求不指定任何的Pods; 目前LimitRanger对Default Namespace中的所有pod应用要求0.1 CPU


//InitialResources（试验）
根据镜像的历史使用记录，为容器设置默认资源请求和limits。

//NamespaceLifecycle
该插件确保处于Termination状态的Namespace不再接收新的对象创建请求，并拒绝请求不存在的Namespace。该插件还可以防止删除系统保留的Namespace:default，kube-system，kube-public

//DefaultStorageClass
该插件将观察PersistentVolumeClaim，并自动设置默认的Storage Class

当没有配置默认Storage Class时，此插件不会执行任何操作。当有多个Storage Class被标记为默认值时，它也将拒绝任何创建，管理员必须重新访问StorageClass对象，并且只标记一个作为默认值。此插件不用于PersistentVolumeClaim的更新，仅用于创建

//DefaultTolerationSeconds
该插件设置Pod的默认forgiveness toleration为5分钟。

//PodSecurityPolicy
该插件用于创建和修改pod，使用Pod Security Policies时需要开启。

当 Kubernetes <1.6.0版本时，API服务器需要启用扩展名/ v1beta1 / podsecuritypolicy API扩展组（--runtime-config=extensions/v1beta1/podsecuritypolicy=true）


//NodeRestriction
此插件限制kubelet修改Node和Pod对象，这样的kubelets只允许修改绑定到Node的Pod API对象，以后版本可能会增加额外的限制。

限制kubelet仅可访问node、endpoint、pod、service以及secret、configmap、PV和PVC等相关的资源（仅适用于v1.7+）

3）插件推荐版本

• 1.11版本以上推荐使用的插件

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

• 对于Kubernetes> = 1.6.0 版本，建议运行以下的准入控制插件（需要按顺序进行）

--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds

• 对于Kubernetes> = 1.4.0 版本，建议运行以下的准入控制插件（需要按顺序进行）

--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota

• 对于Kubernetes> = 1.2.0 版本，建议运行以下的准入控制插件（需要按顺序进行）

--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota

• 对于Kubernetes> = 1.0.0 版本，建议运行以下的准入控制插件（需要按顺序进行）

--admission-control=NamespaceLifecycle,LimitRanger,SecurityContextDeny,ServiceAccount,PersistentVolumeLabel,ResourceQuota

三、RBAC授权

• RBAC（Role-Based Access Control，基于角色的访问控制）使用RBAC.authoriz.k8s.io API组驱动授权决策，允许管理员通过Kubernetes API动态配置策略

1.RBAC的API资源对象说明

//角色：
Role—— 一组权限的集合,只有许可形式的权限,没有拒绝形式的权限, 用户被授予角色即表示拥有角色对应的资源的访问权限。角色存在与namespace 内，跨 namespace的角色需要时用cluster role

Cluster Role—— 集群角色，和角色拥有同样的作用，但是其范围为整个集群。同时拥有集群范围的资源类型（如 NODE, /healthz 等）访问权限。

aggregated cluster role—— 聚合集群角色，可以让一个集群角色，拥有其他几个集群角色的权限 k8s version 1.9+

//角色绑定：
RoleBinding——将角色绑定到主体上，主体可以是user，group，service account

ClusterBinding—— 将集群角色绑定到主体上，主体可以是user，group，service account

//主体（subject）：
User：用户
Group：用户组
ServiceAccount：服务账号（程序型用户，认为不可控）

官方网站：https://kubernetes.io/docs/reference/access-authn-authz/rbac/

2.使用RBAC授权

1）创建用户并做限制

• 创建一个命名空间以及一个pod资源并扩容

[root@master01 demo]# kubectl create ns csdn
namespace/csdn created
[root@master01 demo]# kubectl get ns
NAME          STATUS   AGE
csdn          Active   9s
//创建nginx的pod
[root@master01 demo]# kubectl run nginx --image=nginx -n csdn
kubectl run --generator=deployment/apps.v1beta1 is DEPRECATED and will be removed in a future version. Use kubectl create instead.
deployment.apps/nginx created
//扩容成三个副本
[root@master01 demo]# kubectl scale deploy/nginx --replicas=3 -n csdn
deployment.extensions/nginx scaled
[root@master01 demo]# kubectl get pods -n csdn
nginx-dbddb74b8-9wbnp   1/1     Running   0          30s
nginx-dbddb74b8-tnvnl   1/1     Running   0          72s
nginx-dbddb74b8-x4285   1/1     Running   0          30s

• 创建一个角色资源
• 官方模板
  

[root@master01 demo]# vim rbac-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: csdn
  name: pod-reader 
rules:
- apiGroups: [""] # "" indicates the core API group 
  resources: ["pods"]        //赋予pod资源查看的权限
  verbs: ["get", "watch", "list"]
[root@master01 demo]# kubectl apply -f rbac-role.yaml 
role.rbac.authorization.k8s.io/pod-reader created
[root@master01 demo]# kubectl get role -n csdn
NAME         AGE
pod-reader   20s

• 创建一个角色绑定资源
• rolebinding官方模板
  

[root@master01 demo]# vim rbac-rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding    //类型为RoleBinding
metadata:
  name: read-pods    //绑定的资源
  namespace: csdn    //指定命名空间
subjects:
- kind: User
  name: zhangsan    //指定绑定的用户
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role   
  name: pod-reader   //指定绑定角色
  apiGroup: rbac.authorization.k8s.io
[root@master01 demo]# kubectl apply -f rbac-rolebinding.yaml 
rolebinding.rbac.authorization.k8s.io/read-pods created
[root@master01 demo]# kubectl get role,rolebinding -n csdn
NAME                                        AGE
role.rbac.authorization.k8s.io/pod-reader   8m4s

NAME                                              AGE
rolebinding.rbac.authorization.k8s.io/read-pods   22s

2）制作证书

• 这里准备好了两个模板

[root@master01 demo]# mkdir zhangsan
[root@master01 demo]# cd zhangsan/
[root@master01 zhangsan]# rz -E
rz waiting to receive.
[root@master01 zhangsan]# ls
rbac-user.sh  rbac.yaml
[root@master01 zhangsan]# cat rbac.yaml 
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

---

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io


apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-reader
  namespace: default

---

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sa-read-pods
  namespace: default
subjects:
- kind: ServiceAccount
  name: pod-reader
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

[root@master01 zhangsan]# cat rbac-user.sh 
cat > zhangsan-csr.json <

• 拷贝证书到zhangsan目录

[root@master01 zhangsan]# cp /root/k8s/k8s-sert/ca* ./

• 修改地址为apiserver访问地址（负载均衡VIP）

[root@master01 zhangsan]# vim rbac-user.sh 
kubectl config set-cluster kubernetes \
  --certificate-authority=ca.pem \
  --embed-certs=true \
  --server=https://192.168.170.100:6443 \    //地址改为VIP
  --kubeconfig=zhangsan-kubeconfig

• 直接执行脚本会报错，需要格式化，所以先安装格式化工具并进行格式化

//安装格式化工具
[root@master01 zhangsan]# yum install dos2unix -y
//格式化
[root@master01 zhangsan]# dos2unix rbac-user.sh 
dos2unix: converting file rbac-user.sh to Unix format ...
[root@master01 zhangsan]# bash rbac-user.sh 
2020/05/30 21:13:41 [INFO] generate received request
2020/05/30 21:13:41 [INFO] received CSR
2020/05/30 21:13:41 [INFO] generating key: rsa-2048
2020/05/30 21:13:41 [INFO] encoded CSR
2020/05/30 21:13:41 [INFO] signed certificate with serial number 501963456644305280486350133378326123692229677297
2020/05/30 21:13:41 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").
Cluster "kubernetes" set.
User "zhangsan" set.
Context "default" created.
Switched to context "default".
//查看证书
[root@master01 zhangsan]# cat zhangsan-kubeconfig 

3）验证

kubectl访问

• 使用zhangsan-kubeconfig 访问pod资源

[root@master01 zhangsan]# kubectl --kubeconfig=zhangsan-kubeconfig get pods -n csdn
NAME                    READY   STATUS    RESTARTS   AGE
nginx-dbddb74b8-9wbnp   1/1     Running   0          17m
nginx-dbddb74b8-tnvnl   1/1     Running   0          17m
nginx-dbddb74b8-x4285   1/1     Running   0          17m
//使用zhangsan-kubeconfig访问 svc资源就会被拒绝
[root@master01 zhangsan]# kubectl --kubeconfig=zhangsan-kubeconfig get svc -n csdn
Error from server (Forbidden): services is forbidden: User "zhangsan" cannot list resource "services" in API group "" in the namespace "csdn"
//也无法访问默认的命令空间
[root@master01 zhangsan]# kubectl --kubeconfig=zhangsan-kubeconfig get pods
Error from server (Forbidden): pods is forbidden: User "zhangsan" cannot list resource "pods" in API group "" in the namespace "default"
[root@master01 zhangsan]# kubectl --kubeconfig=zhangsan-kubeconfig get svc
Error from server (Forbidden): services is forbidden: User "zhangsan" cannot list resource "services" in API group "" in the namespace "default"

UI访问

• 访问地址 https://192.168.170.136:30001
• 查看admin的令牌并登录

[root@master01 zhangsan]# kubectl get svc -n kube-system
NAME                   TYPE       CLUSTER-IP   EXTERNAL-IP   PORT(S)         AGE
kubernetes-dashboard   NodePort   10.0.0.228           443:30001/TCP   16d

//查看令牌
[root@master01 zhangsan]# kubectl get secret -n kube-system
NAME                               TYPE                                  DATA   AGE
dashboard-admin-token-452j2        kubernetes.io/service-account-token   3      7d5h
[root@master01 zhangsan]# kubectl describe secret dashboard-admin-token-452j2 -n kube-system
。。。
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJkYXNoYm9hcmQtYWRtaW4tdG9rZW4tNDUyajIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGFzaGJvYXJkLWFkbWluIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiNGFiN2ZlZTEtOWNjYS0xMWVhLTlmYjQtMDAwYzI5MzBkNWNiIiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmUtc3lzdGVtOmRhc2hib2FyZC1hZG1pbiJ9.JWmIUjO6o4mrnCpwYZUfWWZwGuC3kuW5GjRuvcgHAIOTAfevcd9IixaOeM963kRgF1wwzvvoFxFrLu-gfVxP7368UXlY2RxX5Ytpta2sYFonJ2XDjDv5RT8ux-NBtsNfteHdhkeCzLigm1SuSE-9FpZ7wO4kVOyLCC71OK3PBM6Y4icNAC_yu9zFtibOf9dSTxy9Ob1ktX1Fxi_db348t5OhR7ghs43lTAvFj93SABIcbMnXx40NP-ZEWsA2EkZPN6Otki-GKn4ed-d597JfpSGCkZGtQhAEuo8TxK7bWu9tH4SZJNQz2Fdsi3Y0ACcWDJCrqDPwS-8fohXHx50ifA

• 可以正常访问并且可以看到资源信息
• 下面使用zhangsan用户的令牌访问，首先需要执着token

[root@master01 zhangsan]# vim sa.yaml   //创建资源
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-reader  
  namespace: csdn

---

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sa-read-pods
  namespace: csdn
subjects:
- kind: ServiceAccount
  name: pod-reader
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
[root@master01 zhangsan]# kubectl apply -f sa.yaml 
serviceaccount/pod-reader created
rolebinding.rbac.authorization.k8s.io/sa-read-pods created
[root@master01 zhangsan]# kubectl get sa -n csdn
NAME         SECRETS   AGE
default      1         27m
pod-reader   1         10s

• 查看token并登录

[root@master01 zhangsan]# kubectl describe secret pod-reader -n csdn
Name:         pod-reader-token-ghxlq
Namespace:    csdn
Labels:       
Annotations:  kubernetes.io/service-account.name: pod-reader
              kubernetes.io/service-account.uid: 88f97066-a278-11ea-9fb4-000c2930d5cb

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1359 bytes
namespace:  4 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJjc2RuIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InBvZC1yZWFkZXItdG9rZW4tZ2h4bHEiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoicG9kLXJlYWRlciIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6Ijg4Zjk3MDY2LWEyNzgtMTFlYS05ZmI0LTAwMGMyOTMwZDVjYiIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpjc2RuOnBvZC1yZWFkZXIifQ.fZsqTtdSRi8LayrZXE1hzSUjEecOzys3qhPRzkxTPZU7ApR0L4OuGtuEdzMMnSKo33eTMPPBe268CRLsLwu7Y9skx8XnYtMajhHb7sUNlGsHCVDn20fGleyC0Zp8RJvSKwMDafApwlfHSYHBmzMF2moJYvq7RI-LbFqr5ocnpdL637FT0nPElJONfNswoBbPiwOivtPSczCIsMVCIEY7F7h7IPxryUtH2znRvqzZYtVbOHf2Ujta-TLl9O2MY91E29p-G4-zNQkzcSC0VJIxeyoOFE4rmYpuln13rd7HJfGw8q3G7JRxhFBQc2X7sCId3hjNeYCMDAnZpo9BcOo1Cw

• 成功登录界面，但是只有权限查看到容器