摘要：安全功能的最新引入是一組稱為準(zhǔn)入控制器的插件。通過將標(biāo)志傳遞給服務(wù)器來配置啟用的準(zhǔn)入控制器集。本討論將僅關(guān)注基于的準(zhǔn)入控制器。摘要準(zhǔn)入控制器為安全性提供了顯著優(yōu)勢。

作者：Malte Isberner（StackRox）

Kubernetes極大地提高了當(dāng)今生產(chǎn)中后端群集的速度和可管理性。由于其靈活性、可擴(kuò)展性和易用性，Kubernetes已成為容器編排器的事實(shí)標(biāo)準(zhǔn)。Kubernetes也提供一系列保護(hù)生產(chǎn)工作負(fù)載的功能。安全功能的最新引入是一組稱為“準(zhǔn)入控制器”的插件。必須啟用準(zhǔn)入控制器才能使用Kubernetes的一些更高級的安全功能，例如，在整個(gè)命名空間中強(qiáng)制實(shí)施安全配置基線的pod安全政策。以下必須知道的提示和技巧，將幫助你利用準(zhǔn)入控制器，在Kubernetes中充分利用這些安全功能。

簡而言之，Kubernetes準(zhǔn)入控制器是管理和強(qiáng)制執(zhí)行集群使用方式的插件。可以將它們視為攔截（經(jīng)過身份驗(yàn)證的）API請求的網(wǎng)守，并且可以更改請求對象，或完全拒絕請求。準(zhǔn)入控制過程有兩個(gè)階段：首先執(zhí)行改變（mutating）階段，然后是驗(yàn)證（validating）階段。因此，準(zhǔn)入控制器可以充當(dāng)改變或驗(yàn)證控制器，或兩者的組合。例如，LimitRanger準(zhǔn)入控制器可以使用默認(rèn)資源請求和限制（改變階段）擴(kuò)充pod，并驗(yàn)證具有設(shè)置資源要求的pod，不超過LimitRange對象中指定的每命名空間限制（驗(yàn)證階段）。

準(zhǔn)入控制器階段

值得注意的是，許多用戶認(rèn)為是內(nèi)置的Kubernetes操作的某些方面，實(shí)際上由準(zhǔn)入控制器管理。例如，當(dāng)刪除命名空間并隨后進(jìn)入Terminating狀態(tài)時(shí)，NamespaceLifecycle準(zhǔn)入控制器將阻止在此命名空間中創(chuàng)建任何新對象。

在Kubernetes附帶的30多個(gè)準(zhǔn)入控制器中，有兩個(gè)因其幾乎無限的靈活性而發(fā)揮特殊作用 - ValidatingAdmissionWebhooks和MutatingAdmissionWebhooks，兩者在Kubernetes 1.13都處于beta狀態(tài)。我們將仔細(xì)研究這兩個(gè)準(zhǔn)入控制器，因?yàn)樗鼈儽旧聿]有實(shí)現(xiàn)任何政策決策邏輯。相反，相應(yīng)的操作是從集群內(nèi)運(yùn)行的服務(wù)的REST端點(diǎn)（webhook）獲得的。這種方法將準(zhǔn)入控制器邏輯與Kubernetes API服務(wù)器分離，從而允許用戶在Kubernetes集群中創(chuàng)建、更新或刪除資源時(shí)實(shí)現(xiàn)自定義邏輯。

兩種準(zhǔn)入控制器webhooks之間的差異幾乎是不言自明的：改變（mutating）準(zhǔn)入webhooks可能會改變對象，而驗(yàn)證（validating）準(zhǔn)入webhooks則不會。然而，即使是改變準(zhǔn)入webhook也可以拒絕請求，從而以驗(yàn)證的方式行事。驗(yàn)證入場webhooks比改變webhooks有兩個(gè)主要優(yōu)點(diǎn)：首先，出于安全原因，可能需要禁用MutatingAdmissionWebhook準(zhǔn)入控制器（或?qū)φl可能創(chuàng)建MutatingWebhookConfiguration對象應(yīng)用更嚴(yán)格的RBAC限制），因?yàn)樗赡軙a(chǎn)生混淆，甚至危險(xiǎn)的副作用。其次，如上圖所示，驗(yàn)證準(zhǔn)入控制器（以及webhooks）在改變控制器之后運(yùn)行。因此，驗(yàn)證webhook看到的任何請求對象都是將持久保存到etcd的最終版本。

通過將標(biāo)志傳遞給Kubernetes API服務(wù)器來配置啟用的準(zhǔn)入控制器集。請注意，舊的-admission-control標(biāo)志在1.10中已棄用，并替換為-enable-admission-plugins。

--enable-admission-plugins=ValidatingAdmissionWebhook,MutatingAdmissionWebhook

Kubernetes建議默認(rèn)啟用以下準(zhǔn)入控制器。

--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,Priority,ResourceQuota,PodSecurityPolicy

可以在Kubernetes官方參考中找到完整的準(zhǔn)入控制器列表及其說明。本討論將僅關(guān)注基于webhook的準(zhǔn)入控制器。

安全性：準(zhǔn)入控制器可以通過在整個(gè)命名空間或集群中，強(qiáng)制使用合理的安全基準(zhǔn)來提高安全性。內(nèi)置的PodSecurityPolicy準(zhǔn)入控制器可能是最突出的例子；例如，它可以用于禁止容器以root身份運(yùn)行，或者確保容器的根文件系統(tǒng)始終以只讀方式掛載。可通過基于webhook的自定義準(zhǔn)入控制器實(shí)現(xiàn)的其他用例包括：

允許僅從企業(yè)已知的特定倉庫中提取鏡像，同時(shí)拒絕未知的鏡像倉庫。

拒絕不符合安全標(biāo)準(zhǔn)的部署。例如，使用特權(quán)（privileged）標(biāo)志的容器可以規(guī)避許多安全檢查。基于webhook的準(zhǔn)入控制器可以減輕此風(fēng)險(xiǎn)，該準(zhǔn)入控制器拒絕此類部署（驗(yàn)證）或覆蓋特權(quán)（privileged）標(biāo)志，將其設(shè)置為false。

治理：準(zhǔn)入控制器允許你強(qiáng)制遵守某些做法，例如具有良好的標(biāo)簽、注釋、資源限制或其他設(shè)置。一些常見的場景包括：

對不同對象強(qiáng)制執(zhí)行標(biāo)簽驗(yàn)證，以確保將正確的標(biāo)簽用于各種對象，例如分配給團(tuán)隊(duì)或項(xiàng)目的每個(gè)對象，或指定應(yīng)用程序標(biāo)簽的每個(gè)部署。

自動向?qū)ο筇砑幼⑨專鐬椤癲ev”部署資源分配正確的成本中心。

配置管理：準(zhǔn)入控制器允許你驗(yàn)證群集中運(yùn)行對象的配置，并防止群集中任何明顯的錯(cuò)誤配置。準(zhǔn)入控制器可用于檢測和修復(fù)沒有語義標(biāo)簽的部署鏡像，例如：

自動添加資源限制或驗(yàn)證資源限制，

確保合理的標(biāo)簽被添加到pod，或

確保生產(chǎn)部署中使用的鏡像引用不使用最新的（latest）標(biāo)記或帶有-dev后綴的標(biāo)記。

通過這種方式，準(zhǔn)入控制器和政策管理有助于確保應(yīng)用程序在不斷變化的控制環(huán)境中保持合規(guī)。

為了說明如何利用準(zhǔn)入控制器webhook來建立自定義安全政策，讓我們考慮一個(gè)解決Kubernetes缺點(diǎn)之一的例子：它的許多默認(rèn)值都經(jīng)過優(yōu)化，易于使用并減少摩擦，有時(shí)以犧牲安全性為代價(jià)。其中一個(gè)設(shè)置是默認(rèn)允許容器以root身份運(yùn)行（并且，如果沒有進(jìn)一步的配置，Dockerfile中也沒有USER指令，也會這樣）。盡管容器在一定程度上與底層主機(jī)隔離，但以root身份運(yùn)行容器確實(shí)會增加部署的風(fēng)險(xiǎn)級別 - 作為許多安全性最佳實(shí)踐之一，這應(yīng)該避免。例如，最近暴露的runC漏洞（CVE-2019-5736）只有在容器以root身份運(yùn)行時(shí)才能被利用。

你可以使用自定義改變準(zhǔn)入控制器webhook來應(yīng)用更安全的默認(rèn)值：除非明確請求，否則我們的webhook將確保pod作為非root用戶運(yùn)行（如果未進(jìn)行明確分配，我們將分配用戶ID 1234）。請注意，此設(shè)置不會阻止你在群集中部署任何工作負(fù)載，包括那些合法需要以root身份運(yùn)行的工作負(fù)載。它只要求你在部署配置中，明確啟用此風(fēng)險(xiǎn)程序操作模式，而對所有其他工作負(fù)載默認(rèn)為非root模式。

完整的代碼以及部署說明可以在我們隨附的GitHub存儲庫中找到。在這里，我們將重點(diǎn)介紹webhook如何工作的一些更微妙的方面。

通過在Kubernetes中創(chuàng)建MutatingWebhookConfiguration對象來定義改變準(zhǔn)入控制器webhook。在我們的示例中，我們使用以下配置：

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration
metadata:
  name: demo-webhook
webhooks:
  - name: webhook-server.webhook-demo.svc
    clientConfig:
      service:
        name: webhook-server
        namespace: webhook-demo
        path: "/mutate"
      caBundle: ${CA_PEM_B64}
    rules:
      - operations: [ "CREATE" ]
        apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]

此配置定義webhook webhook-server.webhook-demo.svc，并指示Kubernetes API服務(wù)器在通過向/mutate URL發(fā)出HTTP POST請求創(chuàng)建pod時(shí)，在命名空間webhook-demo中查詢服務(wù)webhook-server。要使此配置生效，必須滿足幾個(gè)先決條件。

Kubernetes API服務(wù)器向給定服務(wù)和URL路徑發(fā)出HTTPS POST請求，并在請求正文中使用JSON編碼的AdmissionReview（設(shè)置了Request字段）。響應(yīng)應(yīng)該是JSON編碼的AdmissionReview，這次設(shè)置了Response字段。

我們的演示存儲庫包含一個(gè)處理序列化/反序列化樣板代碼的函數(shù)，并允許你專注于實(shí)現(xiàn)在Kubernetes API對象上運(yùn)行的邏輯。在我們的示例中，實(shí)現(xiàn)準(zhǔn)入控制器邏輯的函數(shù)稱為applySecurityDefaults，在/mutate URL下提供此功能的HTTPS服務(wù)器可以設(shè)置如下：

mux := http.NewServeMux()
mux.Handle("/mutate", admitFuncHandler(applySecurityDefaults))
server := &http.Server{
  Addr:    ":8443",
  Handler: mux,
}
log.Fatal(server.ListenAndServeTLS(certPath, keyPath))

請注意，要使服務(wù)器在沒有提升權(quán)限的情況下運(yùn)行，我們讓HTTP服務(wù)器偵聽端口8443。Kubernetes不允許在webhook配置中指定端口；它始終采用HTTPS端口443。但是，由于無論如何都需要服務(wù)對象，我們可以輕松地將服務(wù)的端口443映射到容器上的端口8443：

apiVersion: v1
kind: Service
metadata:
  name: webhook-server
  namespace: webhook-demo
spec:
  selector:
    app: webhook-server  # specified by the deployment/pod
  ports:
    - port: 443
      targetPort: webhook-api  # name of port 8443 of the container

在改變準(zhǔn)入控制器webhook中，通過JSON補(bǔ)丁執(zhí)行改變。雖然JSON補(bǔ)丁標(biāo)準(zhǔn)包含許多復(fù)雜性，遠(yuǎn)遠(yuǎn)超出了本討論的范圍，但我們的示例中的Go數(shù)據(jù)結(jié)構(gòu)，及其用法應(yīng)該為用戶提供有關(guān)JSON補(bǔ)丁如何工作的良好初步概述：

type patchOperation struct {
  Op    string      `json:"op"`
  Path  string      `json:"path"`
  Value interface{} `json:"value,omitempty"`
}

要將pod的字段.spec.securityContext.runAsNonRoot設(shè)置為true，我們構(gòu)造以下patchOperation對象：

patches = append(patches, patchOperation{
  Op:    "add",
  Path:  "/spec/securityContext/runAsNonRoot",
  Value: true,
})

由于必須通過HTTPS提供webhook，因此我們需要適當(dāng)?shù)姆?wù)器證書。這些證書可以是自簽名的（由自簽名CA簽名），但我們需要Kubernetes在與webhook服務(wù)器通信時(shí)指示相應(yīng)的CA證書。此外，證書的公用名（CN）必須與Kubernetes API服務(wù)器使用的服務(wù)器名稱匹配，內(nèi)部服務(wù)的名稱是..svc，在我們的案例中即webhook-server.webhook-demo.svc。由于自簽名TLS證書的生成在Internet上有詳細(xì)記錄，因此我們只需在示例中引用相應(yīng)的shell腳本。

之前顯示的webhook配置包含占位符${CA_PEM_B64}。在我們創(chuàng)建此配置之前，我們需要將此部分替換為CA的Base64編碼的PEM證書。openssl base64 -A命令可用于此目的。

在部署webhook服務(wù)器并對其進(jìn)行配置之后（可以通過從存儲庫調(diào)用./deploy.sh腳本來完成），現(xiàn)在是時(shí)候測試并驗(yàn)證webhook是否確實(shí)完成它的工作。存儲庫包含三個(gè)示例：

未指定安全上下文的pod（pod-with-defaults）。我們希望此pod以非root身份運(yùn)行，用戶ID為1234。

一個(gè)指定安全上下文的pod，明確允許它以root身份運(yùn)行（pod-with-override）。

具有沖突配置的pod，指定它必須以非root用戶身份運(yùn)行，但用戶ID為0（pod-with-conflict）。為了展示拒絕對象創(chuàng)建請求，我們增加了我們的準(zhǔn)入控制器邏輯，以拒絕這些明顯的錯(cuò)誤配置。

通過運(yùn)行kubectl create -f examples/.yaml創(chuàng)建其中一個(gè)pod。在前兩個(gè)示例中，你可以通過檢查日志來驗(yàn)證pod運(yùn)行的用戶ID，例如：

$ kubectl create -f examples/pod-with-defaults.yaml
$ kubectl logs pod-with-defaults
I am running as user 1234

在第三個(gè)示例中，應(yīng)該拒絕對象創(chuàng)建并提供適當(dāng)?shù)腻e(cuò)誤消息：

$ kubectl create -f examples/pod-with-conflict.yaml
Error from server (InternalError): error when creating "examples/pod-with-conflict.yaml": Internal error occurred: admission webhook "webhook-server.webhook-demo.svc" denied the request: runAsNonRoot specified, but runAsUser set to 0 (the root user)

你也可以使用自己的工作負(fù)載進(jìn)行測試。當(dāng)然，你還可以通過更改webhook的邏輯，并查看更改如何影響對象創(chuàng)建來進(jìn)一步實(shí)驗(yàn)。有關(guān)如何進(jìn)行此類更改實(shí)驗(yàn)的更多信息，請參閱存儲庫的自述文件。

Kubernetes準(zhǔn)入控制器為安全性提供了顯著優(yōu)勢。深入研究兩個(gè)功能強(qiáng)大的示例，并附帶可用的代碼，將幫助你開始利用這些強(qiáng)大的功能。

https://kubernetes.io/docs/re...

https://docs.okd.io/latest/ar...

https://kubernetes.io/blog/20...

https://medium.com/ibm-cloud/...

https://github.com/kubernetes...

https://github.com/istio/istio

https://www.stackrox.com/post...

KubeCon + CloudNativeCon + Open Source Summit大會日期：

會議日程通告日期：2019 年 4 月 10 日

會議活動舉辦日期：2019 年 6 月 24 至 26 日

KubeCon + CloudNativeCon + Open Source Summit贊助方案
KubeCon + CloudNativeCon + Open Source Summit多元化獎(jiǎng)學(xué)金現(xiàn)正接受申請
KubeCon + CloudNativeCon和Open Source Summit即將首次合體落地中國
KubeCon + CloudNativeCon + Open Source Summit購票窗口，立即購票！
CNCF邀請你加入最終用戶社區(qū)