建站
咨詢
售后
建站咨詢
新聞中心
隨著Kubernetes被廣泛使用，成為業(yè)界公認(rèn)的容器編排管理的標(biāo)準(zhǔn)框架，許多開發(fā)人員以及管理員對(duì)部署、彈性伸縮以及管理容器化應(yīng)用程序等Kubernetes的關(guān)鍵概念都十分熟悉。而對(duì)于生產(chǎn)部署而言，Kubernetes的安全性至關(guān)重要。因此，了解平臺(tái)如何管理用戶和應(yīng)用程序的身份認(rèn)證和授權(quán)十分必要。
站在用戶的角度思考問題，與客戶深入溝通，找到丹東網(wǎng)站設(shè)計(jì)與丹東網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品，建站類型包括：網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站設(shè)計(jì)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、域名申請(qǐng)、網(wǎng)絡(luò)空間、企業(yè)郵箱。業(yè)務(wù)覆蓋丹東地區(qū)。
我們將推出一系列文章，以一種實(shí)踐性的視角來了解平臺(tái)內(nèi)部的Kubernetes和Pod外部用戶的身份認(rèn)證和授權(quán)。我也會(huì)解釋如何使用角色以及角色綁定來允許或限制資源訪問。
API Server——Kubernetes網(wǎng)關(guān)
API為Kubernetes各類資源對(duì)象(如節(jié)點(diǎn)、標(biāo)簽、Pod、服務(wù)、部署、secrets、configmaps以及ingress等)提供訪問接口。這些資源對(duì)象通過簡(jiǎn)單的REST API執(zhí)行基本的CRUD(增刪改查)操作。
Kubernetes的核心構(gòu)建塊之一是API Server，它作為Kubernetes的網(wǎng)關(guān)，是訪問和管理資源對(duì)象的唯一入口。內(nèi)部組件(如kubelet、調(diào)度程序和控制器)通過API Server訪問API以進(jìn)行編排和協(xié)調(diào)。分布式鍵/值數(shù)據(jù)庫(kù)、etcd只能通過API Server訪問。
通常我們可以通過命令行工具kubectl來與API Server進(jìn)行交互。從kubectl發(fā)送的任何內(nèi)容最終都會(huì)被API Server所接收。因此，多個(gè)工具和插件會(huì)直接或間接地使用相同的API。
即使在Kubernetes集群中訪問或者操作對(duì)象之前，該請(qǐng)求也需要由API Server進(jìn)行身份驗(yàn)證。REST路徑使用基于X.509證書的TLS協(xié)議來保護(hù)和加密流量。Kubectl在編碼和發(fā)送請(qǐng)求之前查找文件?/ .kube / config以檢索CA證書和客戶端證書。
- apiVersion: v1
- clusters:
- - cluster:
- certificate-authority: /Users/janakiramm/.minikube/ca.crt
- server: https://192.168.99.100:8443
- name: minikube
- contexts:
- - context:
- cluster: minikube
- user: minikube
- name: minikube
- current-context: minikube
- kind: Config
- preferences: {}
- users:
- - name: minikube
- user:
- client-certificate: /Users/janakiramm/.minikube/client.crt
- client-key: /Users/janakiramm/.minikube/client.key
文件ca.crt表示集群使用的CA證書，文件client.crt和client.key映射到用戶minikube。Kubectl使用上下文中的這些證書和密鑰對(duì)請(qǐng)求進(jìn)行編碼。
我們可以通過curl命令訪問API Server嗎?答案是肯定的。
即使最常見的操作是通過運(yùn)行kubectl proxy來使用tunnel協(xié)議，我們依然可以通過計(jì)算機(jī)上的可用證書來訪問路徑。除了CA證書之外，我們還需要在頭部嵌入base64編碼的令牌(token)。
如何檢索令牌(token)以及從curl調(diào)用API的命令如下：
- kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.clu
- Cluster name Server
- minikube https://192.168.99.100:8443
- export CLUSTER_NAME="minikube"
- APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")
接下來，一個(gè)重要的任務(wù)就是獲取與默認(rèn)service account關(guān)聯(lián)的令牌。無需擔(dān)心這一實(shí)體，我們將在之后的文章中更好地理解它。
- TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-a
現(xiàn)在我們擁有調(diào)用curl的所有數(shù)據(jù)了：
- curl -X GET \
- --cacert ~/.minikube/ca.crt \
- --header "Authorization: Bearer $TOKEN" \
- $APISERVER/version
Kubernetes訪問控制的三個(gè)層次
如上文所述，用戶和Pod在訪問或操作對(duì)象之前都要由API Server進(jìn)行身份認(rèn)證。
當(dāng)一個(gè)有效的請(qǐng)求發(fā)送到API Server時(shí)，在它被允許或被拒絕之前將經(jīng)歷3個(gè)步驟。
1、 身份認(rèn)證
一旦TLS連接建立，請(qǐng)求就進(jìn)入到身份認(rèn)證階段，在這一階段，請(qǐng)求有效負(fù)載由一個(gè)或多個(gè)認(rèn)證器模塊檢查。
認(rèn)證模塊時(shí)管理員在集群創(chuàng)建過程中配置的，一個(gè)集群可能有多個(gè)認(rèn)證模塊配置，每個(gè)模塊會(huì)依次嘗試認(rèn)證， 直到其中一個(gè)認(rèn)證成功。
在主流的認(rèn)證模塊中會(huì)包括客戶端證書、密碼、plain tokens、bootstrap tokens以及JWT tokens(用于service account)?？蛻舳俗C書的使用是默認(rèn)的并且是最常見的方案。
請(qǐng)注意，Kubernetes是沒有用于驗(yàn)證用戶身份的典型用戶數(shù)據(jù)庫(kù)或者配置文件。但是它使用從X.509證書以及令牌中提取的字符串，將它們傳遞到身份認(rèn)證模塊。OpenID，Github甚至LDAP提供的外部認(rèn)證機(jī)制可以通過其中一個(gè)認(rèn)證模塊與Kubernetes集成。
2、 授權(quán)
一旦API請(qǐng)求得到認(rèn)證，下一步就是確認(rèn)這一操作是否被允許執(zhí)行。這是訪問控制流程中的第二個(gè)步驟。
對(duì)于授權(quán)一個(gè)請(qǐng)求，Kubernetes主要關(guān)注三個(gè)方面——請(qǐng)求者的用戶名、請(qǐng)求動(dòng)作以及該動(dòng)作影響的對(duì)象。用戶名從嵌入token的頭部中提取，動(dòng)作是映射到CRUD操作的HTTP動(dòng)詞之一(如 GET、POST、PUT、DELETE)，對(duì)象是其中一個(gè)有效的Kubernetes對(duì)象，如pod或者service。
Kubernetes基于一個(gè)存在策略來決定授權(quán)。默認(rèn)情況下，Kubernetes遵循封閉開放的理念，這意味著需要一個(gè)明確的允許策略才可以訪問資源。
與身份認(rèn)證類似，授權(quán)也是基于一個(gè)或多個(gè)模塊配置的，如ABAC模式、RBAC模式以及Webhook模式。當(dāng)管理員創(chuàng)建集群時(shí)，他們配置與API sever集成的授權(quán)模塊。如果多個(gè)模塊都在使用，Kubernetes會(huì)檢查每個(gè)模塊并且如果其中任一模塊授權(quán)了請(qǐng)求，則請(qǐng)求授權(quán)通過。如果所有模塊全部拒絕請(qǐng)求，則請(qǐng)求被拒絕(HTTP狀態(tài)碼403)。
當(dāng)您使用默認(rèn)配置的kubectl時(shí)，所有的請(qǐng)求都會(huì)通過，因此此時(shí)您被認(rèn)為時(shí)集群管理員。但當(dāng)我們添加新的用戶，默認(rèn)狀態(tài)下他們會(huì)限制訪問權(quán)限。
3、 準(zhǔn)入控制
通過準(zhǔn)入控制是請(qǐng)求的最后一個(gè)步驟。與前兩個(gè)步驟類似，準(zhǔn)入控制也有許多模塊。
但與前兩個(gè)步驟不同的是，最后的階段可以修改目標(biāo)對(duì)象。準(zhǔn)入控制模塊作用于對(duì)象的創(chuàng)建、刪除、更新和連接(proxy)階段，但不包括對(duì)象的讀取。舉個(gè)例子，例如，準(zhǔn)入控制模塊可用于修改創(chuàng)建持久卷聲明(PVC)的請(qǐng)求以使用特定存儲(chǔ)類。模塊可以實(shí)施的另一個(gè)策略是每次創(chuàng)建容器時(shí)提取鏡像。
在這一過程中，如果任一準(zhǔn)入控制模塊拒絕，那么請(qǐng)求立刻被拒絕。一旦請(qǐng)求通過所有的準(zhǔn)入控制器，將使用對(duì)應(yīng)API對(duì)象的驗(yàn)證流程對(duì)其進(jìn)行驗(yàn)證，然后寫入對(duì)象存儲(chǔ)。
在下一部分的文章中，我們將更進(jìn)一步了解創(chuàng)建用戶以及為其配置身份認(rèn)證。保持關(guān)注喲~
標(biāo)題名稱：Kubernetes身份認(rèn)證和授權(quán)操作全攻略：K8s訪問控制入門
轉(zhuǎn)載來于：http://m.fisionsoft.com.cn/article/dhchcci.html
