Kubernetes1.5的新特性有什么,很多新手對此不是很清楚,為了幫助大家解決這個難題,下面小編將為大家詳細(xì)講解,有這方面需求的人可以來學(xué)習(xí)下,希望你能有所收獲。
成都創(chuàng)新互聯(lián)于2013年開始,先為象山等服務(wù)建站,象山等地企業(yè),進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為象山企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。背景介紹
在Kubernetes1.5中,對于kubelet新增加了幾個同認(rèn)證/授權(quán)相關(guān)的幾個啟動參數(shù),分別是:
認(rèn)證相關(guān)參數(shù):
anonymous-auth參數(shù):是否啟用匿名訪問,可以選擇true或者false,默認(rèn)是true,表示啟用匿名訪問。 authentication-token-webhook參數(shù):使用tokenreviewAPI來進(jìn)行令牌認(rèn)證。 authentication-token-webhook-cache-ttl參數(shù):webhook令牌認(rèn)證緩存響應(yīng)時長。 client-ca-file參數(shù):表示使用x509證書認(rèn)證,如果設(shè)置此參數(shù),那么就查找client-ca-file參數(shù)設(shè)置的認(rèn)證文件,任何請求只有在認(rèn)證文件中存在的對應(yīng)的認(rèn)證,那么才可以正常訪問。
授權(quán)相關(guān)參數(shù):
authorization-mode參數(shù):kubelet的授權(quán)模式,可以選擇AlwaysAllow或者Webhook,如果設(shè)置成Webhook,那么使用SubjectAccessReviewAPI進(jìn)行授權(quán)。 authorization-webhook-cache-authorized-ttl參數(shù):webhook授權(quán)時,已經(jīng)被授權(quán)內(nèi)容的緩存時長。 authorization-webhook-cache-unauthorized-ttl參數(shù):webhook授權(quán)時,沒有被授權(quán)內(nèi)容的緩存時長。
認(rèn)證
默認(rèn)anonymous-auth參數(shù)設(shè)置成true,也就是可以進(jìn)行匿名認(rèn)證,這時對kubelet API的請求都以匿名方式進(jìn)行,系統(tǒng)會使用默認(rèn)匿名用戶和默認(rèn)用戶組來進(jìn)行訪問,默認(rèn)用戶名“system:anonymous”,默認(rèn)用戶組名“system:unauthenticated”。
可以禁止匿名請求,這時就需要設(shè)置kubelet啟動參數(shù):“–anonymous-auth=false”,這時如果請求時未經(jīng)過認(rèn)證的,那么會返回“401 Unauthorized”。
可以使用x509證書認(rèn)證(X.509格式的證書是最通用的一種簽名證書格式)。這時就需要設(shè)置kubelet啟動參數(shù):“–client-ca-file”,提供認(rèn)證文件,通過認(rèn)證文件來進(jìn)行認(rèn)證。同時還需要設(shè)置api server組件啟動參數(shù):“–kubelet-client-certificate”和“–kubelet-client-key”。在認(rèn)證文件中一個用戶可以屬于多個用戶組,比如下面例子產(chǎn)生的認(rèn)證:
openssl req -new -key jbeda.pem -outjbeda-csr.pem -subj “/CN=jbeda/O=app1/O=app2”
這個例子創(chuàng)建了csr認(rèn)證文件,這個csr認(rèn)證文件作用于用戶jbeda,這個用戶屬于兩個用戶組,分別是app1和app2。
可以啟用令牌認(rèn)證,這時需要通過 命令 “–runtime-config=authentication.k8s.io/v1beta1=true“啟用api server組件authentication.k8s.io/v1beta1相關(guān)的API,還需要啟用kubelet組件的“–authentication-token-webhook”、“–kubeconfig”、“–require-kubeconfig”三個參數(shù)。
kubeconfig參數(shù):設(shè)置kubelet配置文件路徑,這個配置文件用來告訴kubelet組件api server組件的位置,默認(rèn)路徑是。
require-kubeconfig參數(shù):這是一個布爾類型參數(shù),可以設(shè)置成true或者false,如果設(shè)置成true,那么表示啟用kubeconfig參數(shù),從kubeconfig參數(shù)設(shè)置的配置文件中查找api server組件,如果設(shè)置成false,那么表示使用kubelet另外一個參數(shù)“api-servers”來查找api server組件位置。
在kubernetes源代碼中,有一個錯誤的注釋:
func NewKubeletServer() *KubeletServer { versioned:= &v1alpha1.KubeletConfiguration{} api.Scheme.Default(versioned) config:= componentconfig.KubeletConfiguration{} api.Scheme.Convert(versioned,&config, nil) return&KubeletServer{ KubeConfig: flag.NewStringFlag(“/var/lib/kubelet/kubeconfig”), RequireKubeConfig: false, // in 1.5, default to true KubeletConfiguration:config, } }
這里面對RequireKubeConfig參數(shù)默認(rèn)值的設(shè)置是false,但是在注釋中寫的確實true。
啟用令牌認(rèn)證后,kubelet會調(diào)用TokenReview API來進(jìn)行令牌認(rèn)證。
下面是一個kubeconfig文件格式樣例:
clusters: -name: name-of-remote-authn-service cluster: certificate-authority: /path/to/ca.pem # 校驗遠(yuǎn)程服務(wù)的認(rèn)證文件 server: https://authn.example.com/authenticate # 遠(yuǎn)程服務(wù)訪問https路徑 users: -name: name-of-api-server user: client-certificate: /path/to/cert.pem # webhook插件使用的認(rèn)證文件 client-key: /path/to/key.pem # 認(rèn)證文件對應(yīng)的密鑰文件 current-context: webhook contexts: – context: cluster: name-of-remote-authn-service user: name-of-api-sever name: webhook
認(rèn)證請求格式樣例如下:
{ “apiVersion”: “authentication.k8s.io/v1beta1”, “kind”: “TokenReview”, “spec”: { “token”: “(BEARERTOKEN)” } }
成功的認(rèn)證響應(yīng)如下:
{ “apiVersion”: “authentication.k8s.io/v1beta1”, “kind”: “TokenReview”, “status”: { “authenticated”: true, “user”: { “username”: “janedoe@example.com”, “uid”: “42”, “groups”: [ “developers”, “qa” ], “extra”: { “extrafield1”: [ “extravalue1”, “extravalue2” ] } } } }
失敗的認(rèn)證響應(yīng)如下:
{ “apiVersion”: “authentication.k8s.io/v1beta1”, “kind”: “TokenReview”, “status”: { “authenticated”: false } }
授權(quán)
任何請求被成功認(rèn)證后才會被授權(quán),包括匿名認(rèn)證請求。默認(rèn)的授權(quán)模式是AlwaysAllow,意味著允許任何請求。其實對于API的請求是需要進(jìn)行更細(xì)粒度劃分和授權(quán)的,有下面兩點原因:
雖然允許匿名用戶請求,但是應(yīng)該限制匿名用戶可以訪問的API。
雖然允許認(rèn)證用戶請求,但是不同認(rèn)證用戶應(yīng)該可以訪問不同的API,而不能所有認(rèn)證用戶只能訪問相同的API。
要想進(jìn)行API權(quán)限控制,需要通過 命令 “–runtime-config= authorization.k8s.io /v1beta1=true“啟用api server組件authorization.k8s.io/v1beta1相關(guān)的API,還需要將授權(quán)模式參數(shù)“–authorization-mode”設(shè)置成Webhook,然后啟用kubelet組件的“–kubeconfig”和“–require-kubeconfig”兩個參數(shù),這兩個參數(shù)的作用在上面認(rèn)證章節(jié)已經(jīng)詳細(xì)介紹過了,這里不再介紹。
Kubelet接著就會調(diào)用api server組件的SubjectAccessReviewAPI來判斷哪個請求需要進(jìn)行授權(quán)控制。
請求動作類型是根據(jù)HTTP訪問類型進(jìn)行劃分的,如下面表格所示:
HTTP verb request verb POST create GET, HEAD get PUT update PATCH patch DELETE delete
資源訪問請求是根據(jù)不同請求路徑來進(jìn)行劃分的,如下面表格所示:
Kubelet API 資源名稱 子資源名稱 /stats/* nodes stats /metrics/* nodes metrics /logs/* nodes log /spec/* nodes spec all others nodes proxy
對于資源訪問請求,訪問時名字空間和API組這兩個屬性永遠(yuǎn)都是空值,資源名稱的屬性值就是kubelet所在節(jié)點對象名稱。
要是想讓kubelete API可以進(jìn)行權(quán)限控制,還需要確保api server組件已經(jīng)啟用了“–kubelet-client-certificate”和“–kubelet-client-key”連個參數(shù),
kubelet-client-certificate參數(shù):客戶端認(rèn)證文件路徑
kubelet-client-key參數(shù):客戶端密鑰文件路徑
還確??蛻舳吮皇跈?quán)可以訪問下面屬性:
verb=*, resource=nodes,subresource=proxy verb=*, resource=nodes, subresource=stats verb=*, resource=nodes,subresource=log verb=*, resource=nodes,subresource=spec verb=*, resource=nodes,subresource=metrics
Kubernetes1.5中增加了kubele API的認(rèn)證和授權(quán)功能,從中可以發(fā)現(xiàn)社區(qū)對K8S在生產(chǎn)環(huán)節(jié)中安全性的設(shè)計日趨完善,也說明有越來越多的客戶在生產(chǎn)環(huán)境中使用K8S了。經(jīng)常訪問K8S社區(qū)就會發(fā)現(xiàn),在基礎(chǔ)功能日趨完善的情況下,K8S社區(qū)現(xiàn)在對于跨云(Federation)和安全認(rèn)證(Security/Auth)這兩方面有了長足的進(jìn)步,將來的K8S會適合更多的生產(chǎn)環(huán)境,會成為一款特別受歡迎的容器編排開源軟件產(chǎn)品。
看完上述內(nèi)容是否對您有幫助呢?如果還想對相關(guān)知識有進(jìn)一步的了解或閱讀更多相關(guān)文章,請關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道,感謝您對創(chuàng)新互聯(lián)的支持。