今天就跟大家聊聊有關(guān)如何解析K8s安全中的訪(fǎng)問(wèn)控制，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

創(chuàng)新互聯(lián)建站長(zhǎng)期為上千余家客戶(hù)提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù)；打造開(kāi)放共贏平臺(tái)，與合作伙伴共同營(yíng)造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為豐城企業(yè)提供專(zhuān)業(yè)的成都做網(wǎng)站、成都網(wǎng)站制作、成都外貿(mào)網(wǎng)站建設(shè)，豐城網(wǎng)站改版等技術(shù)服務(wù)。擁有十載豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開(kāi)發(fā)。

導(dǎo)讀：訪(fǎng)問(wèn)控制是云原生安全的一個(gè)重要組成部分，也是 K8s 集群在多租環(huán)境下必要且基本的安全加固手段。在 K8s 體系中，訪(fǎng)問(wèn)控制又分為三個(gè)重要的組成部分，請(qǐng)求認(rèn)證，鑒權(quán)和運(yùn)行時(shí)刻的 admission 準(zhǔn)入控制。在本文中，作者將帶領(lǐng)大家了解這 3 部分的基本定義和使用方法，并給出多租環(huán)境下安全加固的相關(guān)最佳實(shí)踐。

一、Kubernetes API 請(qǐng)求訪(fǎng)問(wèn)控制

訪(fǎng)問(wèn)控制

大家都知道訪(fǎng)問(wèn)控制是云原生安全中的一個(gè)重要組成部分。也是一個(gè) Kubernetes 集群在多租戶(hù)環(huán)境下必須要采取的一個(gè)基本的安全防護(hù)手段。

那么在概念上可以抽象的定義為誰(shuí)在何種條件下可以對(duì)什么資源做什么操作。這里的資源就是在 Kubernetes 中我們熟知的：Pod、 ConfigMaps、Deployment、Secrets 等等這樣的資源模型。

Kubernetes API 請(qǐng)求

由上圖來(lái)介紹一下 Kubernetes API 的請(qǐng)求從發(fā)起到其持久化入庫(kù)的一個(gè)流程。

首先看一下請(qǐng)求的發(fā)起，請(qǐng)求的發(fā)起分為兩個(gè)部分：

• 第一個(gè)部分是人機(jī)交互的過(guò)程。 是大家非常熟悉的用 kubectl 對(duì) apiserver 的一個(gè)請(qǐng)求過(guò)程；

• 第二個(gè)部分是 Pod 中的業(yè)務(wù)邏輯與 apiserver 之間的交互。

當(dāng)我們的 apiserver 收到請(qǐng)求后，就會(huì)開(kāi)啟訪(fǎng)問(wèn)控制流程。這里面分為三個(gè)步驟：

• Authentication 認(rèn)證階段：判斷請(qǐng)求用戶(hù)是否為能夠訪(fǎng)問(wèn)集群的合法用戶(hù)。如果用戶(hù)是個(gè)非法用戶(hù)，那 apiserver 會(huì)返回一個(gè) 401 的狀態(tài)碼，并終止該請(qǐng)求；

• 如果用戶(hù)合法的話(huà)，我們的 apiserver 會(huì)進(jìn)入到訪(fǎng)問(wèn)控制的第二階段 Authorization：鑒權(quán)階段。在該階段中 apiserver 會(huì)判斷用戶(hù)是否有權(quán)限進(jìn)行請(qǐng)求中的操作。如果無(wú)權(quán)進(jìn)行操作，apiserver 會(huì)返回 403 的狀態(tài)碼，并同樣終止該請(qǐng)求；

• 如果用戶(hù)有權(quán)進(jìn)行該操作的話(huà)，訪(fǎng)問(wèn)控制會(huì)進(jìn)入到第三個(gè)階段：AdmissionControl。在該階段中 apiserver 的 admission controller 會(huì)判斷請(qǐng)求是否是一個(gè)安全合規(guī)的請(qǐng)求。如果最終驗(yàn)證通過(guò)的話(huà)，訪(fǎng)問(wèn)控制流程才會(huì)結(jié)束。

此時(shí)我們的請(qǐng)求將會(huì)轉(zhuǎn)換為一個(gè) Kubernetes objects 相應(yīng)的變更請(qǐng)求，最終持久化到 ETCD 中。

二、Kubernetes 認(rèn)證

Kubernetes 中的用戶(hù)模型

對(duì)于認(rèn)證來(lái)說(shuō)，首先我們要確定請(qǐng)求的發(fā)起方是誰(shuí)。并最終通過(guò)認(rèn)證過(guò)程將其轉(zhuǎn)換為一個(gè)系統(tǒng)可識(shí)別的用戶(hù)模型用于后期的鑒權(quán)，那么先來(lái)看一下 Kubernetes 中的用戶(hù)模型。

1. Kubernetes 沒(méi)有自身的用戶(hù)管理能力

什么是用戶(hù)管理能力呢？我們無(wú)法像操作 Pod 一樣，通過(guò) API 的方式創(chuàng)建刪除一個(gè)用戶(hù)實(shí)例。同時(shí)我們也無(wú)法在 ETCD 中找到用戶(hù)對(duì)應(yīng)的存儲(chǔ)對(duì)象。

2. Kubernetes 中的用戶(hù)通常是通過(guò)請(qǐng)求憑證設(shè)置

在 Kubernetes 的訪(fǎng)問(wèn)控制流程中用戶(hù)模型是如何產(chǎn)生的呢？答案就在請(qǐng)求方的訪(fǎng)問(wèn)控制憑證中，也就是我們平時(shí)使用的 kube-config 中的證書(shū)，或者是 Pod 中引入的 ServerAccount。經(jīng)過(guò) Kubernetes 認(rèn)證流程之后，apiserver 會(huì)將請(qǐng)求中憑證中的用戶(hù)身份轉(zhuǎn)化為對(duì)應(yīng)的 User 和 Groups 這樣的用戶(hù)模型。在隨后的鑒權(quán)操作和審計(jì)操作流程中，apiserver 都會(huì)使用到改用戶(hù)模型實(shí)例。

3、Kubernetes支持的請(qǐng)求認(rèn)證方式主要包括：

• Basic 認(rèn)證

該認(rèn)證方式下，管理員會(huì)將 Username 和 Password 組成的白名單放置在 apiserver 讀取的靜態(tài)配置文件上面進(jìn)行認(rèn)證，該方式一般用于測(cè)試場(chǎng)景，在安全方面是不推薦且不可拓展的一種方式。

• X509 證書(shū)認(rèn)證

該方式是 apiserver 中相對(duì)應(yīng)用較多的使用方式，首先訪(fǎng)問(wèn)者會(huì)使用由集群 CA 簽發(fā)的，或是添加在 apiserver Client CA 中授信 CA 簽發(fā)的客戶(hù)端證書(shū)去訪(fǎng)問(wèn) apiserver。apiserver 服務(wù)端在接收到請(qǐng)求后，會(huì)進(jìn)行 TLS 的握手流程。除了驗(yàn)證證書(shū)的合法性，apiserver 還會(huì)校驗(yàn)客戶(hù)端證書(shū)的請(qǐng)求源地址等信息。開(kāi)啟雙向認(rèn)證，X509 認(rèn)證是一個(gè)比較安全的方式，也是 Kubernetes 組件之間默認(rèn)使用的認(rèn)證方式，同時(shí)也是 kubectl 客戶(hù)端對(duì)應(yīng)的 kube-config 中經(jīng)常使用到的訪(fǎng)問(wèn)憑證。

• Bearer Tokens(JSON Web Tokens)

• Service Account

• OpenID Connect

• Webhooks

該方式的 Tokens 是通用的 JWT 的形式，其中包含了簽發(fā)者、用戶(hù)的身份、過(guò)期時(shí)間等多種元信息。它的認(rèn)證方式也是常見(jiàn)的私鑰加簽，公鑰驗(yàn)簽的一個(gè)基本流程。基于 Token 的認(rèn)證使用場(chǎng)景也很廣泛，比如 Kubernetes Pod 應(yīng)用中經(jīng)常使用到的 Service Account，其中就會(huì)自動(dòng)綁定一個(gè)簽名后的 JWT Token 用于請(qǐng)求 apiserver。

另外 apiserver 還支持基于 OpenID 協(xié)議的 Token 認(rèn)證，可以通過(guò)對(duì) apiserver 的配置連接一個(gè)指定的外部 IDP，同時(shí)可以通過(guò) Keycloak，Dex 這樣的開(kāi)源服務(wù)來(lái)管理 IDP，請(qǐng)求者可以按照自己熟悉的方式在原身份認(rèn)證服務(wù)上進(jìn)行登錄認(rèn)證，并最終返回一個(gè)相應(yīng)的 JWT token，為了后面的 apiserver 的鑒權(quán)流程。

除此之外，還可以使用 Webhooks 的方式，將請(qǐng)求的 Token 發(fā)送到指定外部服務(wù)進(jìn)行 Token 的驗(yàn)簽。

X509 證書(shū)認(rèn)證

對(duì)于一個(gè)集群證書(shū)體系來(lái)說(shuō)，認(rèn)證機(jī)構(gòu) (CA) 是一個(gè)非常重要的證書(shū)對(duì)。它會(huì)被默認(rèn)放置在集群 Master 節(jié)點(diǎn)上的 /etc/Kubernetes/pki/ 目錄下。集群中所有組件之間的通訊用到的證書(shū)，其實(shí)都是由集群根 CA 來(lái)簽發(fā)的。在證書(shū)中有兩個(gè)身份憑證相關(guān)的重要字段：一個(gè)是 CN，一個(gè)是 O。

另外可以通過(guò) openssl 命令來(lái)進(jìn)行證書(shū)的解析。上圖右側(cè)可以看到，通過(guò) Subject 中的 O 和 CN 字段可以查看對(duì)應(yīng)的信息。

上面每一個(gè)組件證書(shū)都有自己指定的 Common Name 和 Organization 用于特定角色的綁定。這樣的設(shè)置可以使各系統(tǒng)組件只綁定自身功能范圍內(nèi)的角色權(quán)限。從而保證了每個(gè)系統(tǒng)組件自身權(quán)限的最小化。

證書(shū)簽發(fā) API

Kubernetes 集群本身就提供了證書(shū)簽發(fā)的 API，而在集群的創(chuàng)建過(guò)程中，像 kubeadm 這樣的集群安裝工具，會(huì)基于不同的 CSR 簽發(fā)請(qǐng)求調(diào)用 apiserver 對(duì)應(yīng)接口。此時(shí) apiserver 會(huì)根據(jù)請(qǐng)求，以這種 csr 資源模型的形式創(chuàng)建對(duì)應(yīng)的簽發(fā)請(qǐng)求實(shí)例。剛開(kāi)始創(chuàng)建的簽發(fā)實(shí)例都會(huì)處于 pending 的狀態(tài)，直到有權(quán)限的管理員進(jìn)行審批后，這個(gè) csr 才會(huì)處于 approved 的狀態(tài)，請(qǐng)求對(duì)應(yīng)的證書(shū)就會(huì)被簽發(fā)。

通過(guò)上圖右側(cè)中的命令可以來(lái)查看相應(yīng)的證書(shū)內(nèi)容信息。

簽發(fā)用戶(hù)證書(shū)

首先開(kāi)發(fā)人員需用通過(guò) openssl 等證書(shū)工具生成私鑰，然后創(chuàng)建對(duì)應(yīng)的 x509 csr 請(qǐng)求文件，需要在 subj 字段中指定用戶(hù) user 和組 group，最后通過(guò) API 創(chuàng)建 K8s csr 實(shí)例并等待管理員審批。

對(duì)于集群管理員，他可以直接讀取集群根 CA，并通過(guò) x509 的 csr 請(qǐng)求文件簽發(fā)證書(shū)，所以它無(wú)需定義或?qū)徟?csr 實(shí)例。上圖中最后一行是一個(gè) openssl 簽發(fā)示例，命令中需要指明 csr 和 ca.crt 的文件路徑，以及簽發(fā)證書(shū)的過(guò)期時(shí)間信息。

另外各個(gè)云廠(chǎng)商也會(huì)基于登錄用戶(hù)和目標(biāo)集群一鍵化生成對(duì)應(yīng)的集群訪(fǎng)問(wèn)憑證，方便用戶(hù)的使用。

Service Account

除了證書(shū)認(rèn)證之外，Service Account 也是 apiserver 中應(yīng)用比較廣泛的一種方式。對(duì)于 Service Account 來(lái)說(shuō)，它是 K8s 中唯一能夠通過(guò) API 方式管理的 APIService 訪(fǎng)問(wèn)憑證，其他特性在上圖中可以看到。

圖中也給出了一些使用 kubectl 進(jìn)行 Service Account API 相關(guān)增刪改查的示例，同時(shí)我們可以為已經(jīng)存在的 serviceaccount 手動(dòng)創(chuàng)建其 token 對(duì)應(yīng)的 secret，有興趣的同學(xué)可以在 Kubernetes 集群中操作執(zhí)行一下。

接著看一下 Service Account 的使用。

首先可以通過(guò) get secret –oyaml 命令查看 serviceaccount 對(duì)應(yīng)的指定 secret，其中 token 字段即為經(jīng)過(guò)了 base64 編碼的 JWT 格式的認(rèn)證 token。

在部署一個(gè)應(yīng)用時(shí)，我們可以通過(guò) template -> spec -> containers 中的 serviceAccountName 字段聲明需要使用的 Service Account 名稱(chēng)。注意如果是在 Pod 創(chuàng)建過(guò)程中，發(fā)現(xiàn)制定的 ServiceAccount 不存在，則該 Pod 創(chuàng)建過(guò)程會(huì)被終止。

在生成的 pod 模板中可以看到指定 serviceaccount 對(duì)應(yīng)的 secret 中的 ca，namespace 和認(rèn)證 token 會(huì)以文件的形式掛載到容器中的指定目錄下。另外對(duì)于已經(jīng)創(chuàng)建的 Pod，我們不能更新其已經(jīng)掛載的 ServiceAccount 內(nèi)容。

生成 kubeconfig

kubeconfig 是用戶(hù)本地連接 Kubernetes 集群使用的重要訪(fǎng)問(wèn)憑證，接著來(lái)介紹一下 kubeconfig 的配置和使用。

使用 kubeconfig

三、Kubernetes 鑒權(quán) - RBAC

當(dāng)一個(gè)請(qǐng)求在完成 apiserver 認(rèn)證后，可以認(rèn)為它是一個(gè)合法的用戶(hù)，那么如何控制該用戶(hù)在集群中的哪些 namespace 中訪(fǎng)問(wèn)哪些資源，對(duì)這些資源又能進(jìn)行哪些操作呢？

這就由訪(fǎng)問(wèn)控制的第二步 Kubernetes 鑒權(quán)來(lái)完成。apiserver 本身支持多種鑒權(quán)方式，在本節(jié)內(nèi)容中，我們主要介紹在安全上推薦的鑒權(quán)方式 RBAC。

RBAC 鑒權(quán)三要素

• 第一要素是 Subjects，也就是主體。可以是開(kāi)發(fā)人員、集群管理員這樣的自然人，也可以是系統(tǒng)組件進(jìn)程，或者是 Pod 中的邏輯進(jìn)程；

• 第二個(gè)要素是 API Resource，也就是請(qǐng)求對(duì)應(yīng)的訪(fǎng)問(wèn)目標(biāo)。在 Kubernetes 集群中也就是各類(lèi)資源；

• 第三要素是 Verbs，對(duì)應(yīng)為請(qǐng)求對(duì)象資源可以進(jìn)行哪些操作，包括增刪改查、list、get、watch 等。

這里舉個(gè)例子，假設(shè)有個(gè)通過(guò)合法認(rèn)證的用戶(hù) Bob，他請(qǐng)求 list 某個(gè) namespace下的 Pods，改請(qǐng)求的鑒權(quán)語(yǔ)義記為：Can Bob list pods ？其中 Bob 即為請(qǐng)求中的 Subject，list 為對(duì)應(yīng)的請(qǐng)求動(dòng)作 Action，而 pods 為對(duì)應(yīng)的請(qǐng)求資源 Resource。

RBAC 權(quán)限粒度

上面介紹了 RBAC 角色模型的三要素，在整個(gè) RBAC 策略定義下，還需要將這個(gè)角色綁定到一個(gè)具體的控制域內(nèi)。這就是 Kubernetes 大家熟悉的命名空間。通過(guò) namespace 可以將 Kubernetes api 資源限定在不同的作用域內(nèi)。從而幫助我們?cè)谝粋€(gè)多租戶(hù)集群中，對(duì)用戶(hù)進(jìn)行邏輯上的隔離。

上面的事例可以改為 User A can create pods in namespace B。這里需要注意的是，如果不進(jìn)行任何的權(quán)限綁定，RBAC 會(huì)拒絕所有訪(fǎng)問(wèn)。

通常 RBAC 會(huì)進(jìn)行對(duì) apiserver 的細(xì)粒度訪(fǎng)問(wèn)控制，但是這個(gè)細(xì)粒度是個(gè)相對(duì)的概念，RBAC 是面向模型級(jí)別的綁定。它不能綁定到 namespace 中的一個(gè)具體的 object 實(shí)例，更不能綁定到指定資源的任意一個(gè) field。

RBAC 對(duì)訪(fǎng)問(wèn)權(quán)限的控制粒度上，它可以細(xì)化到 Kubernetes api 的 subresources 級(jí)別。比如針對(duì)一個(gè)訪(fǎng)問(wèn)者，我們可以控制其在指定 namespace 下對(duì) nodes/status 模型的訪(fǎng)問(wèn)。

RBAC - Role

接著介紹 RBAC 具體的綁定權(quán)限和對(duì)象。

首先是角色 Role，它定義了用戶(hù)在指定的 Kubernetes 命名空間資源上可以進(jìn)行哪些操作。比如可以定一個(gè) namespace 中 pod 的只讀權(quán)限，同時(shí)還可以定義一個(gè) namespace 管理員權(quán)限，它具有對(duì)這個(gè)命名空間下所有對(duì)象資源的所有操作權(quán)限。

如上圖所示，是一個(gè) Role 的定義模板編排文件，其中 resource 字段定義了這個(gè)角色可以訪(fǎng)問(wèn)哪些資源，verbs 字段定義了這個(gè)角色有哪些操作的權(quán)限。在 apiGroups 中，需要指定目標(biāo)資源的 apiGroups 名稱(chēng)，這里可以通過(guò)官方 API 文檔查詢(xún)，如果指定的 Group 是 core，那么在角色模板中的 apiGroups 可置為空。

RBAC - RoleBinding

當(dāng)我們完成了一個(gè) namespace 下的角色定義之后，還需要建立其與使用這個(gè)角色的主體之間在 namespace 下的綁定關(guān)系，這里需要一個(gè) RoleBinding 模型。使用 RoleBinding 可以將 Role 對(duì)應(yīng)的權(quán)限模型綁定到對(duì)應(yīng)的 Subject 上。

比如這里可以將名為 test 的 namespace 中的 pod 只讀權(quán)限同時(shí)綁定給用戶(hù) test1 和 test2 以及 proc1。也可以將 namespace test 只讀權(quán)限綁定 tech-lead group 中的 test1 用戶(hù)，這樣用戶(hù) test2 和 proc1 是沒(méi)有 get namespace 權(quán)限的。

接著看一下對(duì)應(yīng)的 RoleBinding 編排文件模板。

其中 roleRef 字段中聲明了我們需要綁定的角色，一個(gè)綁定只能指定唯一的 Role。在 subject 字段中定義了我們要綁定的對(duì)象，這里可以是 User，Group 或者是 Service Account。它同時(shí)支持綁定多個(gè)對(duì)象。

RBAC - ClusterRole

除了定義指定 namespace 中的權(quán)限模型，也可以通過(guò) ClusterRole 定義一個(gè)集群維度的權(quán)限模型。在一個(gè) Cluster 實(shí)例中，可以定義集群維度的權(quán)限使用權(quán)限，比如像 PV、Nodes 在 namespace 中不可見(jiàn)的資源權(quán)限，可以在 ClusterRole 中定義，而操作這些資源的動(dòng)作同樣是之前 Role 中支持的增刪改查和 list、watch 等操作。

下圖為 ClusterRole 編排文件模板：

ClusterRole 編排文件幾乎和 Role 是一模一樣的，唯一不同的地方是 ClusterRole 中是所有集群維度的權(quán)限定義，不支持 namespace 的定義。

RBAC - ClusterRoleBinding

同樣在 ClusterRole 的基礎(chǔ)上，可以將其綁定在對(duì)應(yīng)的 Subject 主體上。而 ClusterRoleBinding 模型實(shí)例可以幫助我們?cè)诩核忻臻g上將 ClusterRole 綁定到具體的 Subject 對(duì)象上。

比如這里可以將所有 namespace 的 list 權(quán)限綁定給 group 為 sre 或者 devops 的管理員 admin1 和 admin2。

相比較于 RoleBinding，ClusterRoleBinding 模板定義也只是在 namespace 和 roleRef 中的權(quán)限對(duì)象模型定義上有不同，其他的定義格式是一樣的。

RABC - Default ClusterRoleBinding

通過(guò)上文的學(xué)習(xí)，我們知道在不進(jìn)行任何權(quán)限的綁定下，RABC 會(huì)拒絕所有的訪(fǎng)問(wèn)。那么我們的系統(tǒng)組件之間是如何互相請(qǐng)求呢？

其實(shí)在集群創(chuàng)建的時(shí)候，處理系統(tǒng)各組件的客戶(hù)端證書(shū)，它們各自的角色和環(huán)境對(duì)象也會(huì)被創(chuàng)建出來(lái)，以滿(mǎn)足組件業(yè)務(wù)之間交互必須的權(quán)限要求。

下面看幾個(gè)預(yù)置的集群角色：

角色中的 verbs 如何設(shè)置？

通過(guò)以上對(duì) RBAC 的學(xué)習(xí)，大家應(yīng)該對(duì) Kubernetes 中 RBAC 中的模型定義有了一定的了解，但是在某些復(fù)雜的多租戶(hù)業(yè)務(wù)場(chǎng)景下，如何在權(quán)限模板中針對(duì)各個(gè) API 模型定義相應(yīng)的動(dòng)作策略，還是需要一定的理論和實(shí)踐基礎(chǔ)的。而對(duì)一個(gè)應(yīng)用開(kāi)發(fā)人員來(lái)說(shuō)，kubectl 可能更為直觀(guān)和熟悉些，這里也給出了一些 kubectl 操作和 RBAC 中的對(duì)應(yīng)關(guān)系。

比如當(dāng)我們希望 edit 一個(gè) deploy 的時(shí)候，需要在相應(yīng)的角色模板中增加對(duì) Deployment 資源的 get、patch 這樣的權(quán)限。如果希望 exec 到一個(gè) pod 中，需要在相應(yīng)的角色模板中增加對(duì) pod 的 get 權(quán)限，以及針對(duì) pod/exec 模型的 create 權(quán)限。

四、Security Context 的使用

CVE-2019-5736

通過(guò) docker hub 上的統(tǒng)計(jì)結(jié)果可以看到，主流的業(yè)務(wù)鏡像有 82.4% 是以 root 用戶(hù)來(lái)啟動(dòng)的。通過(guò)這個(gè)調(diào)查可以看到對(duì) Security Context 的相關(guān)使用是不容樂(lè)觀(guān)的。

Kubernetes Runtime 安全策略

經(jīng)過(guò)對(duì)上面的分析結(jié)果可以看出來(lái)，如果我們能夠?qū)I(yè)務(wù)容器配置足夠安全的運(yùn)行時(shí)刻參數(shù)，其實(shí)攻擊者很難有可乘之機(jī)。那么我們究竟應(yīng)該在部署 Kubernetes 集群中的業(yè)務(wù)容器做哪些 runtime 運(yùn)行時(shí)刻的安全加固呢？

• 首先還是要遵循權(quán)限最小化原則，除了業(yè)務(wù)運(yùn)行所必需的系統(tǒng)權(quán)限，其他權(quán)限都是可以去除的；

• 此外還可以通過(guò)在 pod 或者 container 維度設(shè)置 Security Context 參數(shù)，進(jìn)行業(yè)務(wù)容器運(yùn)行時(shí)刻的安全配置；

• 另外就是可以通過(guò)開(kāi)啟 Pod Security Policy，在 apiserver 請(qǐng)求的 Admission 階段強(qiáng)制校驗(yàn)容器的安全配置；

• 除了 PSP 的開(kāi)啟之外，如上圖還列舉了常見(jiàn)的，使用比較多的配置參數(shù)。

Pod Security Policy

由于 PSP 策略相對(duì)復(fù)雜一些，這里介紹一下使用注意事項(xiàng)。

首先可以通過(guò) API 直接操作 PSP 的安全策略實(shí)例，如上圖左側(cè)是 PSP 策略支持的配置參數(shù)，包括特權(quán)容器，系統(tǒng)capabilities，運(yùn)行時(shí)刻用戶(hù) id 和文件系統(tǒng)權(quán)限等多種配置。大家也可以在官方文檔找到各個(gè)參數(shù)的詳細(xì)說(shuō)明。

而 PSP 的作用正是在業(yè)務(wù)容器運(yùn)行前，基于這個(gè)策略校驗(yàn)安全參數(shù)配置，如果不滿(mǎn)足該安全策略，則禁止該 Pod 運(yùn)行。

最后在 PSP 的使用上，我們需要注意幾點(diǎn)，如上圖右側(cè)所示。

五、總結(jié) - 多租安全加固

最后在對(duì)多租環(huán)境下，如何利用 Kubernetes 下原生的安全能力做安全加固做一個(gè)最佳實(shí)踐的小結(jié)。

看完上述內(nèi)容，你們對(duì)如何解析K8s安全中的訪(fǎng)問(wèn)控制有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。

分享文章：如何解析K8s安全中的訪(fǎng)問(wèn)控制
文章地址：http://chinadenli.net/article32/gshhpc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站排名、商城網(wǎng)站、網(wǎng)站設(shè)計(jì)公司、網(wǎng)站策劃、手機(jī)網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀(guān)點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)