|
我們知道在k8s上APIserver是整個集群的訪問入口，etcd是保存整個集群所有資源狀態(tài)配置信息的kv鍵值存儲數(shù)據(jù)庫，一旦etcd宕機，k8s整個集群將無法正常工作，為此我們需要對etcd做高可用；除此之外為了保證etcd中的數(shù)據(jù)安全，k8s只允許APIserver去訪問/操作etcd;這也是APIserver為什么是整個集群的訪問入口的原因；簡單講etcd的客戶端只有APIserver，我們用客戶端想要查看對應(yīng)資源的狀態(tài)或者修改對應(yīng)資源屬性等等操作，都需要把請求發(fā)送給APIserver，由APIserver再把客戶端的請求代理到etcd上，從而實現(xiàn)客戶端訪問/操作etcd中對應(yīng)資源的狀態(tài)或?qū)傩孕畔ⅲ贿@樣一來APIserver就承擔(dān)了整個etcd的數(shù)據(jù)訪問安全；一旦APIserver出現(xiàn)問題，把惡意請求放進(jìn)來，對應(yīng)etcd的中的數(shù)據(jù)安全將無從保證；為此APIserver就必須擁有一套對客戶端請求進(jìn)行驗證管控的機制；如下圖
1、用戶認(rèn)證 首先APIserver要驗證客戶端是否是合法客戶端，在k8s上我們用kubectl工具去管理k8s集群，APIserver首先要驗證kubectl客戶端的證書，同時kubectl也要驗證對應(yīng)APIserver的證書；這個過程我們叫k8s用戶認(rèn)證的過程；在k8s上除了有通過證書方式認(rèn)證客戶端，還有其他機制，比如用戶名和密碼，利用token機制去驗證對應(yīng)客戶端；其中利用token機制中有明文token（plain token）和引導(dǎo)token（bootstrap token）；不管是用戶名密碼還是token方式認(rèn)證用戶，在發(fā)送給APIserver時都是通過把對應(yīng)的信息轉(zhuǎn)化成http協(xié)議頭部信息傳遞給APIserver；對應(yīng)APIserver收到對應(yīng)客戶端請求，就會把對應(yīng)頭部信息檢索下來，進(jìn)行驗證；不同的是plain token主要用于驗證對應(yīng)客戶端是否合法，是否能夠登陸APIserver；而對應(yīng)bootstrap token是用來驗證對應(yīng)節(jié)點是否能夠加入到k8s集群，如果bootstrap認(rèn)證通過后，對應(yīng)APIserver會調(diào)用ca給對應(yīng)節(jié)點上的kubelet和kubeproxy頒發(fā)證書；此后kubelet和kubeproxy就可以通過APIserver認(rèn)可的ca頒發(fā)的證書到APIserver認(rèn)證，訪問對應(yīng)資源的信息了； 用戶認(rèn)證只是驗證對應(yīng)客戶端是否是合法客戶端，這里的驗證的機制是一票通過的機制；所謂一票通過是指在APIserver上有多種驗證機制（方法），它會從上至下依次進(jìn)行驗證，如果對應(yīng)驗證方法沒有明確拒絕，接著它會用下一個驗證方法，直到有一個機制通過以后，余下的就不驗證了；比如，在k8s上有證書驗證，用戶名密碼驗證，token驗證，如果此時有一個客戶端拿著一個token來登陸APIserver，此時APIserver就會先用證書驗證的方法驗證客戶端，如果對應(yīng)驗證方法沒有明確拒絕，說明此方法不識別對應(yīng)的客戶端信息，接著它會用用戶名密碼的方法進(jìn)行驗證，如果對應(yīng)方法也沒有明確拒絕，接著它會用token方法進(jìn)行驗證，如果對應(yīng)方法通過了，那么接下來的其他方法驗證就不會再進(jìn)行下去；如果所有驗證方法都沒有拒絕，說明該客戶端提供的認(rèn)證信息在k8s上不適配，此時apiserver 就會把對應(yīng)客戶端歸納為匿名用戶；當(dāng)然此類用戶雖然登陸到APIserver上，但它沒有權(quán)限操作資源； 2、驗證授權(quán) 只有驗證通過的客戶端，才會有機會進(jìn)行權(quán)限驗證，所謂權(quán)限驗證是指驗證對應(yīng)客戶端是否擁有對應(yīng)k8s上的資源訪問/操作權(quán)限；驗證權(quán)限也是一票通過的機制；只要對應(yīng)客戶端有對應(yīng)資源的操作/訪問權(quán)限，則其他資源的權(quán)限驗證就不會再進(jìn)行下去；如果沒有對應(yīng)資源訪問/操作權(quán)限，此時APIserver就直接響應(yīng)對應(yīng)的客戶端請求沒有權(quán)限訪問；如果對應(yīng)客戶端有對資源的訪問/操作操作權(quán)限，此時客戶端請求會進(jìn)入到下一個步驟，準(zhǔn)入控制； 3、準(zhǔn)入控制 所謂準(zhǔn)入控制是指檢查對應(yīng)客戶端的請求是否符合對應(yīng)請求/操作API規(guī)范；傳遞參數(shù)是否是正確的；比如我們要想k8s上創(chuàng)建一個pod，此時準(zhǔn)入控制會檢查我們提交的信息是否符合創(chuàng)建對應(yīng)資源的規(guī)范，如果符合規(guī)范就創(chuàng)建，不符合規(guī)范就拒絕；準(zhǔn)入控制這個環(huán)節(jié)是使用的一票否決的機制，所謂一票否決是指只要有一項不通過，則整個請求都將是拒絕的，即便余下的檢查都是通過的；當(dāng)然只要有一項沒有通過，余下的驗證就不會再進(jìn)行；除了檢查對應(yīng)客戶端提交的信息是否符合對應(yīng)API資源的規(guī)范，準(zhǔn)入控制還會幫助我們把我們沒有明確指定的字段信息，通過默認(rèn)值的方式把對應(yīng)的字段填充到客戶端請求中；然后把填充好的信息一并由APIserver把客戶端請求更新到對應(yīng)資源在etcd中的對應(yīng)信息上； k8s上的用戶 在k8s上用戶有兩類，一類是常規(guī)用戶（normal users），一類是服務(wù)賬號（Service Account）；所謂常規(guī)用戶就是指對應(yīng)客戶端現(xiàn)實生活中的操作者，這個有點類似Linux上的登錄用戶；它把對應(yīng)操作該客戶端的人，映射到對應(yīng)客戶端的名稱上；比如我們用kubectl去操作k8s集群，在k8s上我們自己就是對應(yīng)kubeclt持有的證書信息中的/CN對應(yīng)的字符串；服務(wù)賬號是指非人類操作的客戶端所用到的用戶名，有點類似Linux系統(tǒng)上的系統(tǒng)賬號；它的存在只是為了在k8s上方便權(quán)限的劃分；簡單講服務(wù)賬號就是用來針對那些程序自身向apiserver發(fā)起連接時，附加的用戶信息，主要作用是apiserver可以根據(jù)對應(yīng)的用戶信息，來判斷對應(yīng)客戶端在apiserver上的權(quán)限；如下所示
提示：上圖是一個pod的詳細(xì)信息，其中我們并沒有定義存儲卷，創(chuàng)建pod后，它默認(rèn)會生成這個存儲卷；這個存儲卷被掛載到對應(yīng)pod容器內(nèi)部的//var/run/secrets/kubernetes.io/serviceaccount 這個路徑；其實這個就是對應(yīng)pod檢索/更新自己的狀態(tài)信息，要在apiserver上進(jìn)行認(rèn)證的serviceaccount信息，保存在secret存儲卷中；如下圖所示
提示：對應(yīng)pod掛載secret存儲卷，主要作用是在檢索/更新自己的狀態(tài)信息時，它會把這個token發(fā)送給apiserver進(jìn)行驗證；apiserver認(rèn)證通過后就把對應(yīng)狀態(tài)信息更新到etcd中進(jìn)行保存；正是因為pod提供了sa（serviceaccount的簡寫）賬號token信息，使得apiserver才能正常判斷出對應(yīng)token對應(yīng)用戶的權(quán)限；這個token是在創(chuàng)建pod時，對應(yīng)準(zhǔn)入控制器自動生成sa賬號，并把對應(yīng)的sa賬號的token信息以secret存儲卷的方式掛載至對應(yīng)pod的對應(yīng)位置，pod更新或檢索自己的信息時，它會把/var/run/secrets/kubernetes.io/serviceaccount這個文件中的信息發(fā)送給apiserver進(jìn)行驗證；此時apiserver一驗證對應(yīng)token信息，就能知道這個token是對應(yīng)sa賬號的token信息，從而識別到對應(yīng)sa賬號的權(quán)限；所以pod才能夠正常的通過apiserver更新/檢索自己的狀態(tài)信息； 客戶端配置文件kubeconfig 在k8s上各個客戶端都是優(yōu)先使用證書來做認(rèn)證，apiserver通過驗證各客戶端的證書來確認(rèn)對應(yīng)的客戶端是否能夠正常訪問apiserver；在k8s上證書驗證是雙向的，apiserver會驗證客戶端的證書中的subj中的CN（common name）的信息，是否符合對應(yīng)客戶端持有的身份信息，即用戶名稱；把證書中的subj中的O（organization）信息視為對應(yīng)用戶組；除此之外apiserver還會驗證對應(yīng)客戶端證書是否是自己信任的CA所頒發(fā)的證書；對于客戶端來說，也是同樣的邏輯，它也需要驗證apiserver的證書是否吻合對應(yīng)apiserver的名稱，是否是同一CA頒發(fā)的證書；那么問題來了，每次客戶端是怎么向apiserver發(fā)送自己的的證書信息的呢？在k8s上每一個客戶端都有一個配置文件，這個配置文件主要用來記錄客戶端證書驗證相關(guān)信息；這個配置文件有一個統(tǒng)一的稱呼叫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客戶端工具去訪問對應(yīng)apiserver時，默認(rèn)沒有指定其配置文件，主要原因是在對應(yīng)Linux用戶的家目錄下有一個.kube的目錄里有一個config文件；這個文件是我們在初始化集群后，從/etc/kubernetes/admin.conf文件復(fù)制過來的，兩者內(nèi)容一樣；默認(rèn)不指定其配置文件kubectl會到當(dāng)前Linux用戶所在家目錄下的.kube/config文件作為對應(yīng)訪問apiserver的認(rèn)證文件； 查看kubctl的配置文件內(nèi)容 [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是指定用戶賬號以及相關(guān)認(rèn)證列表；clusters用來指定目標(biāo)集群列表；contexts用來指定以哪個user接入那個cluster的對應(yīng)連接組合；curren-context是用來指定當(dāng)前使用的context；從上面的信息可以看到當(dāng)前使用的是kubernetes-admin@kubernetes context連接k8s集群，對應(yīng)context中，集群名叫kubernetes,使用的用戶是kubernetes-admin；而對應(yīng)集群的地址是https://192.168.0.41:6443,對應(yīng)用戶的的證書和私鑰這里被隱藏了； 查看集群列表 [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]# 查看當(dāng)前使用的context [root@master01 manifests]# kubectl config current-context kubernetes-admin@kubernetes [root@master01 manifests]# 示例：創(chuàng)建一個集群、常規(guī)用戶、context，把對應(yīng)信息保存到一個配置文件中，用對應(yīng)配置文件去apiserver上請求資源，看看是否能夠請求到對應(yīng)資源信息？ 創(chuàng)建私鑰 [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用戶簽發(fā)證書 [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來簽發(fā)證書，否則apiserver它不認(rèn)； 創(chuàng)建集群，指定對應(yīng)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表示隱藏證書信息；這里默認(rèn)沒有指定將配置信息保存在那個配置文件，默認(rèn)就保存在當(dāng)前配置文件（用戶家目錄的./kube/config文件中）；如果要想指定保存在某個配置文件中，可以在后面加上--kubeconfig選項來指定對應(yīng)的配置文件即可； 把創(chuàng)建集群的配置保存在/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編碼處理以后的信息； 創(chuàng)建用戶，指定對應(yīng)用戶名稱，用戶證書和私鑰信息 [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的信息識別為對應(yīng)用戶信息；這里補充一點，在k8s上沒有真正的人類用戶，它是把對應(yīng)客戶端的證書中的CN信息識別成對應(yīng)操作該客戶端的用戶；只要對應(yīng)的證書能夠通過認(rèn)證，不管對應(yīng)操作者是誰，k8s并不關(guān)心；就像我們在使用Linux時，拿著root用戶登錄了系統(tǒng)，只要密碼正確，Linux內(nèi)核就認(rèn)為是root在操作；這里的證書就好比Linuxroot的密碼； 創(chuàng)建context，把tom用戶和myk8s集群做關(guān)聯(lián)，并指定對應(yīng)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 ~]#
提示：創(chuàng)建context盡量做到見名知意；一般都是使用用戶名@集群名的格式為context命名； 到此，對應(yīng)tom用戶的配置文件就做好了，我們在/tmp/myk8s.config文件中保存了對應(yīng)新建的用戶、集群、context信息，在當(dāng)前配置文件中也保存了相應(yīng)的配置信息； 測試：在沒有切換配置之前，查看集群運行在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 ~]#
提示：當(dāng)前配置還是用的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列表就看不到；這里提示我們權(quán)限拒絕；其實看不到才是正常的，因為我們只是把tom用戶接入到apiserver上進(jìn)行認(rèn)證，并沒有給他授權(quán)，所以tom用戶目前只是通過了驗證，并沒有對資源的操作權(quán)限，在權(quán)限驗證時給拒絕了； 使用/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，響應(yīng)我們對應(yīng)資源禁止訪問； 切回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以后，對應(yīng)的用戶認(rèn)證在apiserver有查看對應(yīng)資源的權(quán)限； 創(chuàng)建一個sa賬號 [root@master01 ~]# cat sa-demo.yaml apiVersion: v1 kind: ServiceAccount metadata: name: sa-demo namespace: default [root@master01 ~]# 提示：sa是k8s上的一個標(biāo)準(zhǔn)資源，其群組為v1，類型為ServiceAccount；其中metadata.name是用來指定sa賬號的名稱，namespace用來指定其名稱空間信息；創(chuàng)建一個sa資源用戶只需要定義對應(yīng)的名稱和名稱空間就可以了；對應(yīng)secret資源會自動創(chuàng)建并生成的對應(yīng)的token信息；這樣一來就意味著只要我們創(chuàng)建一個sa賬號，在k8s上就能夠被認(rèn)證通過；因為創(chuàng)建sa它自動創(chuàng)建secret并將對應(yīng)的token生成好；我們可以理解為創(chuàng)建secret并生成token的過程就是在把對應(yīng)sa賬號和對應(yīng)token進(jìn)行關(guān)聯(lián)； 應(yīng)用資源清單 [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 ~]#
提示：可以看到應(yīng)用資源清單以后，對應(yīng)sa就成功被創(chuàng)建，同時查看sa的詳細(xì)信息，它關(guān)聯(lián)了一個secret資源，對應(yīng)secret資源的詳細(xì)信息中明確標(biāo)注了對應(yīng)sa用戶名稱為sa-demo；從上面反饋的信息我們不難理解，創(chuàng)建sa賬號，它會自動創(chuàng)建一個secret，并且把對應(yīng)的secret中的token與sa賬號做綁定；這就意味著，我們只要拿著對應(yīng)的token去apiserver認(rèn)證，對應(yīng)apiserver一定能夠在etcd中查到對應(yīng)的token綁定的sa賬號；從而對應(yīng)sa賬號就能順利的通過apiserver中的認(rèn)證機制； |
|
|
