容器編排系統K8s之訪問控制--用戶認證

時間 2020-12-30

標籤 html mysql nginx web sql docker 數據庫 json bootstrap api 欄目 HTML 简体版

原文原文鏈接

　　前文咱們聊到了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中的認證機制；