容器編排系統K8s之訪問控制--使用者認證
前文我們聊到了k8s的statefulset控制器相關使用說明，回顧請參考：https://www.cnblogs.com/qiuhom-1874/p/14201103.html；今天我們來聊一下k8s安全相關話題；
我們知道在k8s上APIserver是整個叢集的訪問入口，etcd是儲存整個叢集所有資源狀態配置資訊的kv鍵值儲存資料庫，一旦etcd宕機，k8s整個叢集將無法正常工作，為此我們需要對etcd做高可用；除此之外為了保證etcd中的資料安全，k8s只允許APIserver去訪問/操作etcd;這也是APIserver為什麼是整個叢集的訪問入口的原因；簡單講etcd的客戶端只有APIserver，我們用客戶端想要檢視對應資源的狀態或者修改對應資源屬性等等操作，都需要把請求傳送給APIserver，由APIserver再把客戶端的請求代理到etcd上，從而實現客戶端訪問/操作etcd中對應資源的狀態或屬性資訊；這樣一來APIserver就承擔了整個etcd的資料訪問安全；一旦APIserver出現問題，把惡意請求放進來，對應etcd的中的資料安全將無從保證；為此APIserver就必須擁有一套對客戶端請求進行驗證管控的機制；如下圖
1、使用者認證
首先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認證，訪問對應資源的資訊了；
使用者認證只是驗證對應客戶端是否是合法客戶端，這裡的驗證的機制是一票通過的機制；所謂一票通過是指在APIserver上有多種驗證機制（方法），它會從上至下依次進行驗證，如果對應驗證方法沒有明確拒絕，接著它會用下一個驗證方法，直到有一個機制通過以後，餘下的就不驗證了；比如，在k8s上有證書驗證，使用者名稱密碼驗證，token驗證，如果此時有一個客戶端拿著一個token來登陸APIserver，此時APIserver就會先用證書驗證的方法驗證客戶端，如果對應驗證方法沒有明確拒絕，說明此方法不識別對應的客戶端資訊，接著它會用使用者名稱密碼的方法進行驗證，如果對應方法也沒有明確拒絕，接著它會用token方法進行驗證，如果對應方法通過了，那麼接下來的其他方法驗證就不會再進行下去；如果所有驗證方法都沒有拒絕，說明該客戶端提供的認證資訊在k8s上不適配，此時apiserver 就會把對應客戶端歸納為匿名使用者；當然此類使用者雖然登陸到APIserver上，但它沒有許可權操作資源；
2、驗證授權
只有驗證通過的客戶端，才會有機會進行許可權驗證，所謂許可權驗證是指驗證對應客戶端是否擁有對應k8s上的資源訪問/操作許可權；驗證許可權也是一票通過的機制；只要對應客戶端有對應資源的操作/訪問許可權，則其他資源的許可權驗證就不會再進行下去；如果沒有對應資源訪問/操作許可權，此時APIserver就直接響應對應的客戶端請求沒有許可權訪問；如果對應客戶端有對資源的訪問/操作操作許可權，此時客戶端請求會進入到下一個步驟，准入控制；
3、准入控制
所謂准入控制是指檢查對應客戶端的請求是否符合對應請求/操作API規範；傳遞引數是否是正確的；比如我們要想k8s上建立一個pod，此時准入控制會檢查我們提交的資訊是否符合建立對應資源的規範，如果符合規範就建立，不符合規範就拒絕；准入控制這個環節是使用的一票否決的機制，所謂一票否決是指只要有一項不通過，則整個請求都將是拒絕的，即便餘下的檢查都是通過的；當然只要有一項沒有通過，餘下的驗證就不會再進行；除了檢查對應客戶端提交的資訊是否符合對應API資源的規範，准入控制還會幫助我們把我們沒有明確指定的欄位資訊，通過預設值的方式把對應的欄位填充到客戶端請求中；然後把填充好的資訊一併由APIserver把客戶端請求更新到對應資源在etcd中的對應資訊上；
k8s上的使用者
在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中的認證機