前文咱们聊到了k8s的statefulset控制器相关使用说明,回顾请参考:http://www.javashuo.com/article/p-zxcudtzr-ny.html;今天咱们来聊一下k8s安全相关话题;html
咱们知道在k8s上APIserver是整个集群的访问入口,etcd是保存整个集群全部资源状态配置信息的kv键值存储数据库,一旦etcd宕机,k8s整个集群将没法正常工做,为此咱们须要对etcd作高可用;除此以外为了保证etcd中的数据安全,k8s只容许APIserver去访问/操做etcd;这也是APIserver为何是整个集群的访问入口的缘由;简单讲etcd的客户端只有APIserver,咱们用客户端想要查看对应资源的状态或者修改对应资源属性等等操做,都须要把请求发送给APIserver,由APIserver再把客户端的请求代理到etcd上,从而实现客户端访问/操做etcd中对应资源的状态或属性信息;这样一来APIserver就承担了整个etcd的数据访问安全;一旦APIserver出现问题,把恶意请求放进来,对应etcd的中的数据安全将无从保证;为此APIserver就必须拥有一套对客户端请求进行验证管控的机制;以下图mysql
一、用户认证nginx
首先APIserver要验证客户端是不是合法客户端,在k8s上咱们用kubectl工具去管理k8s集群,APIserver首先要验证kubectl客户端的证书,同时kubectl也要验证对应APIserver的证书;这个过程咱们叫k8s用户认证的过程;在k8s上除了有经过证书方式认证客户端,还有其余机制,好比用户名和密码,利用token机制去验证对应客户端;其中利用token机制中有明文token(plain token)和引导token(bootstrap token);不论是用户名密码仍是token方式认证用户,在发送给APIserver时都是经过把对应的信息转化成http协议头部信息传递给APIserver;对应APIserver收到对应客户端请求,就会把对应头部信息检索下来,进行验证;不一样的是plain token主要用于验证对应客户端是否合法,是否可以登录APIserver;而对应bootstrap token是用来验证对应节点是否可以加入到k8s集群,若是bootstrap认证经过后,对应APIserver会调用ca给对应节点上的kubelet和kubeproxy颁发证书;此后kubelet和kubeproxy就能够经过APIserver承认的ca颁发的证书到APIserver认证,访问对应资源的信息了;web
用户认证只是验证对应客户端是不是合法客户端,这里的验证的机制是一票经过的机制;所谓一票经过是指在APIserver上有多种验证机制(方法),它会从上至下依次进行验证,若是对应验证方法没有明确拒绝,接着它会用下一个验证方法,直到有一个机制经过之后,余下的就不验证了;好比,在k8s上有证书验证,用户名密码验证,token验证,若是此时有一个客户端拿着一个token来登录APIserver,此时APIserver就会先用证书验证的方法验证客户端,若是对应验证方法没有明确拒绝,说明此方法不识别对应的客户端信息,接着它会用用户名密码的方法进行验证,若是对应方法也没有明确拒绝,接着它会用token方法进行验证,若是对应方法经过了,那么接下来的其余方法验证就不会再进行下去;若是全部验证方法都没有拒绝,说明该客户端提供的认证信息在k8s上不适配,此时apiserver 就会把对应客户端概括为匿名用户;固然此类用户虽然登录到APIserver上,但它没有权限操做资源;sql
二、验证受权docker
只有验证经过的客户端,才会有机会进行权限验证,所谓权限验证是指验证对应客户端是否拥有对应k8s上的资源访问/操做权限;验证权限也是一票经过的机制;只要对应客户端有对应资源的操做/访问权限,则其余资源的权限验证就不会再进行下去;若是没有对应资源访问/操做权限,此时APIserver就直接响应对应的客户端请求没有权限访问;若是对应客户端有对资源的访问/操做操做权限,此时客户端请求会进入到下一个步骤,准入控制;数据库
三、准入控制json
所谓准入控制是指检查对应客户端的请求是否符合对应请求/操做API规范;传递参数是不是正确的;好比咱们要想k8s上建立一个pod,此时准入控制会检查咱们提交的信息是否符合建立对应资源的规范,若是符合规范就建立,不符合规范就拒绝;准入控制这个环节是使用的一票否决的机制,所谓一票否决是指只要有一项不经过,则整个请求都将是拒绝的,即使余下的检查都是经过的;固然只要有一项没有经过,余下的验证就不会再进行;除了检查对应客户端提交的信息是否符合对应API资源的规范,准入控制还会帮助咱们把咱们没有明确指定的字段信息,经过默认值的方式把对应的字段填充到客户端请求中;而后把填充好的信息一并由APIserver把客户端请求更新到对应资源在etcd中的对应信息上;bootstrap
k8s上的用户api
在k8s上用户有两类,一类是常规用户(normal users),一类是服务账号(Service Account);所谓常规用户就是指对应客户端现实生活中的操做者,这个有点相似Linux上的登陆用户;它把对应操做该客户端的人,映射到对应客户端的名称上;好比咱们用kubectl去操做k8s集群,在k8s上咱们本身就是对应kubeclt持有的证书信息中的/CN对应的字符串;服务账号是指非人类操做的客户端所用到的用户名,有点相似Linux系统上的系统帐号;它的存在只是为了在k8s上方便权限的划分;简单讲服务账号就是用来针对那些程序自身向apiserver发起链接时,附加的用户信息,主要做用是apiserver能够根据对应的用户信息,来判断对应客户端在apiserver上的权限;以下所示
提示:上图是一个pod的详细信息,其中咱们并无定义存储卷,建立pod后,它默认会生成这个存储卷;这个存储卷被挂载到对应pod容器内部的//var/run/secrets/kubernetes.io/serviceaccount 这个路径;其实这个就是对应pod检索/更新本身的状态信息,要在apiserver上进行认证的serviceaccount信息,保存在secret存储卷中;以下图所示
提示:对应pod挂载secret存储卷,主要做用是在检索/更新本身的状态信息时,它会把这个token发送给apiserver进行验证;apiserver认证经过后就把对应状态信息更新到etcd中进行保存;正是由于pod提供了sa(serviceaccount的简写)帐号token信息,使得apiserver才能正常判断出对应token对应用户的权限;这个token是在建立pod时,对应准入控制器自动生成sa帐号,并把对应的sa帐号的token信息以secret存储卷的方式挂载至对应pod的对应位置,pod更新或检索本身的信息时,它会把/var/run/secrets/kubernetes.io/serviceaccount这个文件中的信息发送给apiserver进行验证;此时apiserver一验证对应token信息,就能知道这个token是对应sa帐号的token信息,从而识别到对应sa帐号的权限;因此pod才可以正常的经过apiserver更新/检索本身的状态信息;
客户端配置文件kubeconfig
在k8s上各个客户端都是优先使用证书来作认证,apiserver经过验证各客户端的证书来确认对应的客户端是否可以正常访问apiserver;在k8s上证书验证是双向的,apiserver会验证客户端的证书中的subj中的CN(common name)的信息,是否符合对应客户端持有的身份信息,即用户名称;把证书中的subj中的O(organization)信息视为对应用户组;除此以外apiserver还会验证对应客户端证书是不是本身信任的CA所颁发的证书;对于客户端来讲,也是一样的逻辑,它也须要验证apiserver的证书是否吻合对应apiserver的名称,是不是同一CA颁发的证书;那么问题来了,每次客户端是怎么向apiserver发送本身的的证书信息的呢?在k8s上每个客户端都有一个配置文件,这个配置文件主要用来记录客户端证书验证相关信息;这个配置文件有一个统一的称呼叫kubeconfig;保存在/etc/kubernetes/目录下;
[root@master01 ~]# ll /etc/kubernetes/ total 32 -rw------- 1 root root 5567 Dec 22 20:00 admin.conf -rw------- 1 root root 5599 Dec 22 20:00 controller-manager.conf -rw------- 1 root root 1955 Dec 22 20:01 kubelet.conf drwxr-xr-x 2 root root 113 Dec 22 20:00 manifests drwxr-xr-x 3 root root 4096 Dec 22 20:00 pki -rw------- 1 root root 5547 Dec 22 20:00 scheduler.conf [root@master01 ~]#
提示:咱们使用kubectl客户端工具去访问对应apiserver时,默认没有指定其配置文件,主要缘由是在对应Linux用户的家目录下有一个.kube的目录里有一个config文件;这个文件是咱们在初始化集群后,从/etc/kubernetes/admin.conf文件复制过来的,二者内容同样;默认不指定其配置文件kubectl会到当前Linux用户所在家目录下的.kube/config文件做为对应访问apiserver的认证文件;
查看kubctl的配置文件内容
[root@master01 manifests]# kubectl config view apiVersion: v1 clusters: - cluster: certificate-authority-data: DATA+OMITTED server: https://192.168.0.41: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 [root@master01 manifests]#
提示;k8s上的客户端配置文件主要有4部分组成,分别是,users、clusters、contexts、current-context;users是指定用户账号以及相关认证列表;clusters用来指定目标集群列表;contexts用来指定以哪一个user接入那个cluster的对应链接组合;curren-context是用来指定当前使用的context;从上面的信息能够看到当前使用的是kubernetes-admin@kubernetes context链接k8s集群,对应context中,集群名叫kubernetes,使用的用户是kubernetes-admin;而对应集群的地址是https://192.168.0.41:6443,对应用户的的证书和私钥这里被隐藏了;
查看集群列表
[root@master01 manifests]# kubectl config get-clusters NAME kubernetes [root@master01 manifests]#
查看用户列表
[root@master01 manifests]# kubectl config get-users NAME kubernetes-admin [root@master01 manifests]#
查看context列表
[root@master01 manifests]# kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * kubernetes-admin@kubernetes kubernetes kubernetes-admin [root@master01 manifests]#
查看当前使用的context
[root@master01 manifests]# kubectl config current-context kubernetes-admin@kubernetes [root@master01 manifests]#
示例:建立一个集群、常规用户、context,把对应信息保存到一个配置文件中,用对应配置文件去apiserver上请求资源,看看是否可以请求到对应资源信息?
建立私钥
[root@master01 manifests]# cd /etc/kubernetes/pki/ [root@master01 pki]# ls apiserver.crt apiserver-kubelet-client.crt etcd front-proxy-client.key apiserver-etcd-client.crt apiserver-kubelet-client.key front-proxy-ca.crt sa.key apiserver-etcd-client.key ca.crt front-proxy-ca.key sa.pub apiserver.key ca.key front-proxy-client.crt [root@master01 pki]# openssl genrsa -out tom.key 2048 Generating RSA private key, 2048 bit long modulus ..............+++ ..........................................................................................................................................................................................................................................+++ e is 65537 (0x10001) [root@master01 pki]# ls apiserver.crt apiserver-kubelet-client.crt etcd front-proxy-client.key apiserver-etcd-client.crt apiserver-kubelet-client.key front-proxy-ca.crt sa.key apiserver-etcd-client.key ca.crt front-proxy-ca.key sa.pub apiserver.key ca.key front-proxy-client.crt tom.key [root@master01 pki]#
使用tom.key为tom用户生成签署请求文件tom.csr
[root@master01 pki]# openssl req -new -key ./tom.key -out tom.csr -subj "/CN=tom/O=myuser" [root@master01 pki]# ls apiserver.crt apiserver-kubelet-client.key front-proxy-ca.key tom.csr apiserver-etcd-client.crt ca.crt front-proxy-client.crt tom.key apiserver-etcd-client.key ca.key front-proxy-client.key apiserver.key etcd sa.key apiserver-kubelet-client.crt front-proxy-ca.crt sa.pub [root@master01 pki]#
使用apiserver信任的ca给tom用户签发证书
[root@master01 pki]# openssl x509 -req -in tom.csr -CA ./ca.crt -CAkey ./ca.key -CAcreateserial -out tom.crt -days 365 Signature ok subject=/CN=tom/O=myuser Getting CA Private Key [root@master01 pki]# ls apiserver.crt apiserver-kubelet-client.key front-proxy-ca.key tom.crt apiserver-etcd-client.crt ca.crt front-proxy-client.crt tom.csr apiserver-etcd-client.key ca.key front-proxy-client.key tom.key apiserver.key etcd sa.key apiserver-kubelet-client.crt front-proxy-ca.crt sa.pub [root@master01 pki]#
提示:这里使用的CA必需要用apiserver信任的ca来签发证书,不然apiserver它不认;
建立集群,指定对应ca的证书信息,集群名字以及集群的地址
[root@master01 ~]# kubectl config set-cluster myk8s --server="https://192.168.0.41:6443" --certificate-authority=/etc/kubernetes/pki/ca.crt --embed-certs=true Cluster "myk8s" set. [root@master01 ~]# kubectl config get-clusters NAME myk8s kubernetes [root@master01 ~]#
提示:--embed-certs=ture表示隐藏证书信息;这里默认没有指定将配置信息保存在那个配置文件,默认就保存在当前配置文件(用户家目录的./kube/config文件中);若是要想指定保存在某个配置文件中,能够在后面加上--kubeconfig选项来指定对应的配置文件便可;
把建立集群的配置保存在/tmp/myk8s.config文件中
[root@master01 ~]# kubectl config set-cluster myk8s --server="https://192.168.0.41:6443" --certificate-authority=/etc/kubernetes/pki/ca.crt --embed-certs=true --kubeconfig=/tmp/myk8s.config Cluster "myk8s" set. [root@master01 ~]# kubectl config get-clusters --kubeconfig=/tmp/myk8s.config NAME myk8s [root@master01 ~]# cat /tmp/myk8s.config apiVersion: v1 clusters: - cluster: certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1ekNDQWMrZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJd01USXdPREEyTXpnMU5Gb1hEVE13TVRJd05qQTJNemcxTkZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSzZXCjl5Mkc5YUxFc3h1Q3dNQllBbEdtRys5TG5nMU9OWm9aRDZDd2ZLUUY3Y3lHSStuN1BwSDJFT2o1K292WlBNWG0KckpNaVFHOXB2bVNDZC9FRkxod05YRWNOREZDbGF6Y0cvQ1B0QjlCRlQ1ZGdVMXJnMGxvRUxEVXduUk16eU43QwozRkdacW9maW9kMXJZaGhRaHpDc2N6a0w3dWJjcTBOS2NFQjY0OTB1N0hyeVZ5Y0pGSmwzR0ZKVnN0d0pYZkV1CmtVQ2s2bVlYNFFWb2NObHlKVWZLaWZUMFBZSVQwVVBqZWwvc2NrTnJIUjFFTU5sVXJOWXlHMkJ1cTFhSENhZ2oKRGNrUWh5dU44cTZqNERiSGwrS0pJUTNtN0dxL29vTzBSMm5LNFlKUVMyZjI4bkFhWkRlRWZZcDEwdmg0ditUQwpjaXI5RStmYm1EYWFUQXNsVGdrQ0F3RUFBYU5DTUVBd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZMNVRSSG9QUGJDWk4vUFRVcjdCZGVidmdkMFRNQTBHQ1NxR1NJYjMKRFFFQkN3VUFBNElCQVFBQTRxa3prejNsTGFRYlQ3a0x3SnBoTXZnczJUdzU1b01VYWlzdlBJczVwSk1aZmNwNQpDcFdiRnc1VzR6R0RqWFBpRUExb3BvOEFEQzlXTERZem01eHV3V1ZQeWlWZzRmWjYxK3hISU9KMnlnQW4rWEo1CjRVUHMzYUl3RUJ3OHNPdTM4c1N0a29HNDJTY1gzTXR5cDRjRHJDakFGYnVrMUR5U3E5RytOWG9iL3FVdWxDWC8KSkdzSUJZd3pHVmVDSzVweVJDdHUwY0VRWkp4N1pQc2RhOXcwWXVBdGt5dFN3YkxVakU5MWpMNDV4blRHdllpMwo4eC9ocmJOYVBKUjVlNStpZlZqQVR1TDNHM3liNkduaVNsMGNBSDlNeEUzNE50MStwUFlOTmduVk9HdC9SZTdwClVubzVocXd4RTB2cmQxanU2YlVmVDZ6U0ozb1hpejI5Ri93RwotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== server: https://192.168.0.41:6443 name: myk8s contexts: null current-context: "" kind: Config preferences: {} users: null [root@master01 ~]#
提示:这里的证书信息是一base64编码处理之后的信息;
建立用户,指定对应用户名称,用户证书和私钥信息
[root@master01 ~]# kubectl config set-credentials tom --client-certificate=/etc/kubernetes/pki/tom.crt --client-key=/etc/kubernetes/pki/tom.key --username=tom --embed-certs=true User "tom" set. [root@master01 ~]# kubectl config set-credentials tom --client-certificate=/etc/kubernetes/pki/tom.crt --client-key=/etc/kubernetes/pki/tom.key --username=tom --embed-certs=true --kubeconfig=/tmp/myk8s.config User "tom" set. [root@master01 ~]# kubectl config view --kubeconfig=/tmp/myk8s.config apiVersion: v1 clusters: - cluster: certificate-authority-data: DATA+OMITTED server: https://192.168.0.41:6443 name: myk8s contexts: null current-context: "" kind: Config preferences: {} users: - name: tom user: client-certificate-data: REDACTED client-key-data: REDACTED username: tom [root@master01 ~]#
提示:--username指定的名字尽可能同证书中的CN名称相同,由于apiserver会把CN的信息识别为对应用户信息;这里补充一点,在k8s上没有真正的人类用户,它是把对应客户端的证书中的CN信息识别成对应操做该客户端的用户;只要对应的证书可以经过认证,无论对应操做者是谁,k8s并不关心;就像咱们在使用Linux时,拿着root用户登陆了系统,只要密码正确,Linux内核就认为是root在操做;这里的证书就比如Linuxroot的密码;
建立context,把tom用户和myk8s集群作关联,并指定对应context的名称
[root@master01 ~]# kubectl config set-context tom@myk8s --cluster=myk8s --user=tom Context "tom@myk8s" created. [root@master01 ~]# kubectl config set-context tom@myk8s --cluster=myk8s --user=tom --kubeconfig=/tmp/myk8s.config Context "tom@myk8s" created. [root@master01 ~]# kubectl config view --kubeconfig=/tmp/myk8s.config apiVersion: v1 clusters: - cluster: certificate-authority-data: DATA+OMITTED server: https://192.168.0.41:6443 name: myk8s contexts: - context: cluster: myk8s user: tom name: tom@myk8s current-context: "" kind: Config preferences: {} users: - name: tom user: client-certificate-data: REDACTED client-key-data: REDACTED username: tom [root@master01 ~]#
提示:建立context尽可能作到见名知意;通常都是使用用户名@集群名的格式为context命名;
到此,对应tom用户的配置文件就作好了,咱们在/tmp/myk8s.config文件中保存了对应新建的用户、集群、context信息,在当前配置文件中也保存了相应的配置信息;
测试:在没有切换配置以前,查看集群运行在default名称空间运行的pod
[root@master01 ~]# kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * kubernetes-admin@kubernetes kubernetes kubernetes-admin tom@myk8s myk8s tom [root@master01 ~]# kubectl get pods NAME READY STATUS RESTARTS AGE nginx-pod-demo 1/1 Running 0 117m web-0 1/1 Running 1 27h web-1 1/1 Running 1 27h web-2 1/1 Running 1 27h web-3 1/1 Running 2 27h [root@master01 ~]#
提示:当前配置仍是用的kubernetes-admin@kubernetes这个context,查看default名称空间下的pod可以正常查询到;
切换context到tom@myk8s context上,看看是否还能看到default名称空间下的pod 呢?
[root@master01 ~]# kubectl config use-context tom@myk8s Switched to context "tom@myk8s". [root@master01 ~]# kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE kubernetes-admin@kubernetes kubernetes kubernetes-admin * tom@myk8s myk8s tom [root@master01 ~]# kubectl get pods Error from server (Forbidden): pods is forbidden: User "tom" cannot list resource "pods" in API group "" in the namespace "default" [root@master01 ~]#
提示:能够看到切换到tom@myk8s这个context后,再次查看default名称空间下pod列表就看不到;这里提示咱们权限拒绝;其实看不到才是正常的,由于咱们只是把tom用户接入到apiserver上进行认证,并无给他受权,因此tom用户目前只是经过了验证,并无对资源的操做权限,在权限验证时给拒绝了;
使用/tmp/myk8s.config配置文件查看default名称空间下的pod列表
[root@master01 ~]# kubectl config get-contexts --kubeconfig=/tmp/myk8s.config CURRENT NAME CLUSTER AUTHINFO NAMESPACE tom@myk8s myk8s tom [root@master01 ~]# kubectl config use-context tom@myk8s --kubeconfig=/tmp/myk8s.config Switched to context "tom@myk8s". [root@master01 ~]# kubectl config get-contexts --kubeconfig=/tmp/myk8s.config CURRENT NAME CLUSTER AUTHINFO NAMESPACE * tom@myk8s myk8s tom [root@master01 ~]# kubectl get pods --kubeconfig=/tmp/myk8s.config Error from server (Forbidden): pods is forbidden: User "tom" cannot list resource "pods" in API group "" in the namespace "default" [root@master01 ~]#
提示:使用/tmp/myk8s.config配置文件去apiserver上验证,也是同样的状况看不到pod,响应咱们对应资源禁止访问;
切回kubernetes-admin@kubernetes context再次查看default名称空间下的pod列表
[root@master01 ~]# kubectl config use-context kubernetes-admin@kubernetes Switched to context "kubernetes-admin@kubernetes". [root@master01 ~]# kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * kubernetes-admin@kubernetes kubernetes kubernetes-admin tom@myk8s myk8s tom [root@master01 ~]# kubectl get pods NAME READY STATUS RESTARTS AGE nginx-pod-demo 1/1 Running 0 132m web-0 1/1 Running 1 27h web-1 1/1 Running 1 27h web-2 1/1 Running 1 27h web-3 1/1 Running 2 27h [root@master01 ~]#
提示:切回kubernetes-admin@kubernetes context后,查看default名称空间下的pod列表,可以正常查看到,这是由于切换context之后,对应的用户认证在apiserver有查看对应资源的权限;
建立一个sa帐号
[root@master01 ~]# cat sa-demo.yaml apiVersion: v1 kind: ServiceAccount metadata: name: sa-demo namespace: default [root@master01 ~]#
提示:sa是k8s上的一个标准资源,其群组为v1,类型为ServiceAccount;其中metadata.name是用来指定sa帐号的名称,namespace用来指定其名称空间信息;建立一个sa资源用户只须要定义对应的名称和名称空间就能够了;对应secret资源会自动建立并生成的对应的token信息;这样一来就意味着只要咱们建立一个sa帐号,在k8s上就可以被认证经过;由于建立sa它自动建立secret并将对应的token生成好;咱们能够理解为建立secret并生成token的过程就是在把对应sa帐号和对应token进行关联;
应用资源清单
[root@master01 ~]# kubectl apply -f sa-demo.yaml serviceaccount/sa-demo created [root@master01 ~]# kubectl get sa NAME SECRETS AGE default 1 21d sa-demo 1 5s [root@master01 ~]# kubectl describe sa sa-demo Name: sa-demo Namespace: default Labels: <none> Annotations: <none> Image pull secrets: <none> Mountable secrets: sa-demo-token-8kjhc Tokens: sa-demo-token-8kjhc Events: <none> [root@master01 ~]# kubectl get secret NAME TYPE DATA AGE default-token-xvd4c kubernetes.io/service-account-token 3 21d docker-registry.io kubernetes.io/dockerconfigjson 1 3d1h mysql-auth Opaque 2 3d sa-demo-token-8kjhc kubernetes.io/service-account-token 3 26s test-secret-demo Opaque 2 2d23h test-secret-demo1 Opaque 2 2d23h test-tls kubernetes.io/tls 2 3d www-myapp-com-ingress-secret kubernetes.io/tls 2 7d23h [root@master01 ~]# kubectl describe secret sa-demo-token-8kjhc Name: sa-demo-token-8kjhc Namespace: default Labels: <none> Annotations: kubernetes.io/service-account.name: sa-demo kubernetes.io/service-account.uid: 34cb62e8-23bd-4f2b-be82-4a8c9afc4037 Type: kubernetes.io/service-account-token Data ==== ca.crt: 1066 bytes namespace: 7 bytes token: eyJhbGciOiJSUzI1NiIsImtpZCI6IjM4WnU0Z1Q1c0hBNmR5Q1V0ejRaMFk4d2J2WncwWjNiUTAxZk02SGN4OTgifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InNhLWRlbW8tdG9rZW4tOGtqaGMiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoic2EtZGVtbyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjM0Y2I2MmU4LTIzYmQtNGYyYi1iZTgyLTRhOGM5YWZjNDAzNyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OnNhLWRlbW8ifQ.XyYaqpeZXexal1wr1aiBaZOelRJtlQ2drElDcvWIep1yj4TNYKhqsEUA11fzazStUahpLzuTMXGHMDG7AKA8MqBgBUxRW7UPNBxF7_radK4dfUxig_049Dp7nBYpPKl3sRyPfZcm_R0bXrnXfiMj7KEsfenx3_Skr7R0Wtc4asuVcLgYR1PGFMKbAqi_FDLlZYsledP74fGs3pGNnQ46LNaZ7-ZrsDuIOCxsaJ-QKR_zUQni8wmmKYzGmuVTRvSmlk79DCjMhmVJ6B-AOtXLc8N8yoZ35_ZtXc5VyBTdGTYtIE6x7O6kUlNMFZQLwYgRnUQJdwbfSEUAJXD4b7KMQw [root@master01 ~]#
提示:能够看到应用资源清单之后,对应sa就成功被建立,同时查看sa的详细信息,它关联了一个secret资源,对应secret资源的详细信息中明确标注了对应sa用户名称为sa-demo;从上面反馈的信息咱们不难理解,建立sa帐号,它会自动建立一个secret,而且把对应的secret中的token与sa帐号作绑定;这就意味着,咱们只要拿着对应的token去apiserver认证,对应apiserver必定可以在etcd中查到对应的token绑定的sa帐号;从而对应sa帐号就能顺利的经过apiserver中的认证机制;