前文我們聊到了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
=https://www.cnblogs.com/qiuhom-1874/archive/2020/12/30/===
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中的認證機制；
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/242179.html
標籤：其他