K8S使用姿勢最佳實踐Check List

一篇從應(yīng)用部署/服務(wù)管治/集群配置三個方便來check你的K8S使用姿勢是否正確,包含單不限于服務(wù)監(jiān)控檢查/資源使用/標(biāo)簽/HPA，VPA/安全策略/RBAC/日志/監(jiān)控是否為最佳實踐的check list。

一 應(yīng)用部署

1.1 健康檢查

readiness probe確定容器何時可以接收流量。

Kubelet執(zhí)行檢查并確定應(yīng)用程序是否可以接收流量。

liveness probe確定何時應(yīng)重新啟動容器。

kubelet執(zhí)行檢查并確定是否應(yīng)重新啟動容器。

1.1.1 容器就緒性探針

就緒性和存活性探針沒有默認(rèn)值，如果您未設(shè)置就緒探針，則kubelet會假定該應(yīng)用程序已準(zhǔn)備就緒，可以在容器啟動后立即接收流量。

1.1.2 發(fā)生致命錯誤時容器崩潰

如果應(yīng)用程序遇到不可恢復(fù)的錯誤，則應(yīng)使其崩潰，例如：

未捕獲的異常

代碼中的錯字（用于動態(tài)語言）

無法加載標(biāo)頭或依賴項

請注意，您不應(yīng)發(fā)信號通知Liveness探針失敗，相反，您應(yīng)該立即退出該過程，并讓kubelet重新啟動容器。

1.1.3 配置被動的存活性探針

Liveness探針旨在在卡住容器時重新啟動容器，例如：

如果您的應(yīng)用程序正在處理無限循環(huán)，則無法退出或?qū)で髱椭?/p>

當(dāng)該進(jìn)程消耗100％的CPU時，將沒有時間回復(fù)（其他）Readiness探針檢查，并且最終將其從服務(wù)中刪除。但是，該P(yáng)od仍被注冊為當(dāng)前Deployment的活動副本。如果沒有Liveness探針，它將保持運(yùn)行狀態(tài)，但與服務(wù)分離。換句話說，該過程不僅不處理任何請求，而且還消耗資源。

此時應(yīng)該怎么辦：

從您的應(yīng)用程序公開端點

端點總是回復(fù)成功響應(yīng)

使用“活力”探針獲取端點

請注意，您不應(yīng)該使用Liveness探針來處理應(yīng)用程序中的致命錯誤，并要求Kubernetes重新啟動應(yīng)用程序。相反，您應(yīng)該讓應(yīng)用程序崩潰。

僅在過程無響應(yīng)的情況下，才應(yīng)將“活動性”探針用作恢復(fù)機(jī)制。

1.1.4 存活性探針與就緒性探針的區(qū)別

當(dāng)“活力”和“就緒”探針指向相同的端點時，探針的作用會合并在一起。

當(dāng)應(yīng)用程序發(fā)出信號表明尚未準(zhǔn)備就緒或尚待運(yùn)行時，kubelet會將容器與服務(wù)分離并同時將其刪除。

您可能會注意到連接斷開，因為容器沒有足夠的時間耗盡當(dāng)前連接或處理傳入的連接。

可以參考：article that discussed graceful shutdown.

1.2 應(yīng)用的獨立性

如果應(yīng)用程序連接到數(shù)據(jù)庫，也許你認(rèn)為如果數(shù)據(jù)庫為就緒就返回一個失敗的就緒就ok了，但是事實并非如此，例如您有一個依賴于后端API的前端應(yīng)用程序。如果該API不穩(wěn)定（例如由于錯誤而有時不可用），則就緒探測器將失敗，并且前端應(yīng)用程序中的相關(guān)就緒也將失敗。這就會導(dǎo)致停機(jī)時間。更一般而言，下游依賴項的故障可能會傳播到上游的所有應(yīng)用程序，并最終也降低前端面層

1.2.1 就緒性探針應(yīng)該獨立

就緒性探針不應(yīng)該依以下服務(wù)：

數(shù)據(jù)庫

數(shù)據(jù)庫遷移

APIs

第三方服務(wù)

詳細(xì)可參考：explore what happens when there’re dependencies in the readiness probes in this essay.

1.2.2 應(yīng)用程序重連到依賴服務(wù)

應(yīng)用啟動時，它不應(yīng)該因為數(shù)據(jù)庫等依賴項尚未就緒就崩潰，而是，應(yīng)用程序應(yīng)繼續(xù)嘗試重新連接數(shù)據(jù)庫，直到成功為止。

Kubernetes希望可以以任何順序啟動應(yīng)用程序組件。當(dāng)您確保您的應(yīng)用程序可以重新連接到諸如數(shù)據(jù)庫之類的依賴項時，這樣可以大大提升服務(wù)的健壯性。

1.3 優(yōu)雅的關(guān)機(jī)

您應(yīng)該等待現(xiàn)有連接耗盡并停止處理新連接。請注意，當(dāng)Pod終止時，該P(yáng)od的端點將從服務(wù)中刪除。

但是，可能需要一些時間才能將諸如kube-proxy或Ingress控制器之類的組件通知更改。

詳細(xì)可參考：handling client requests correctly with Kubernetes.

正確的優(yōu)雅停止順序

在收到SIGTERM后

服務(wù)器停止接受新的鏈接

完成現(xiàn)有所有的請求

然后殺死所有的keepalive鏈接

進(jìn)程退出

可以利用工具測試：test that your app gracefully shuts down with this tool: kube-sigterm-test.

1.3.1 應(yīng)用程序未通過SIGTERM信號關(guān)閉，但它已經(jīng)終止了鏈接

可能需要一些時間才能將諸如kube-proxy或Ingress控制器之類的組件通知端點更改。

因此，盡管標(biāo)記為已終止，但流量仍可能流向Pod。

該應(yīng)用程序應(yīng)停止接受所有剩余連接上的新請求，并在耗盡傳出隊列后將其關(guān)閉。

1.3.2 應(yīng)用程序仍在寬限期處理請求

您可能要考慮使用容器生命周期事件，例如the preStop handler自定義pod刪除之前的動作

1.3.3 Dockerfile中的CMD將SIGTERM轉(zhuǎn)發(fā)到進(jìn)程

通過在應(yīng)用中捕獲SIGTERM信號，可以在Pod即將終止時收到通知。

你應(yīng)該注意：forwarding the signal to the right process in your container.

1.3.4 關(guān)閉所有空閑的保持活動套接字

如果調(diào)用方應(yīng)用未關(guān)閉TCP連接（例如使用TCP保持活動狀態(tài)或連接池），它將連接到一個Pod，而不使用該服務(wù)中的其他Pod。

當(dāng)時當(dāng)pod刪除的時候會發(fā)生什么呢，理想狀態(tài)請求應(yīng)該使用其他POD，但是，調(diào)用方應(yīng)用程序與即將終止的Pod的連接壽命很長，它將繼續(xù)使用它。

另一方面，你不應(yīng)該突然終止一個長鏈接，相反，您應(yīng)該先關(guān)閉它們，然后再關(guān)閉應(yīng)用程序。

您可以在有關(guān)以下內(nèi)容的文章中閱讀有關(guān)保持活動連接的信息：gracefully shutting down a Nodejs HTTP server.

1.4 容錯能力

物理機(jī)硬件故障

云供應(yīng)商或管理程序

kernel恐慌

pod部署在這些節(jié)點上也將丟失

在以下情況下可以刪除pod

直接刪除一個pod

draining一個node

從節(jié)點上刪除Pod，以允許另一個Pod適合該節(jié)點

以上任何情況都可能影響您的應(yīng)用程序的可用性，并可能導(dǎo)致停機(jī)。

您應(yīng)該避免所有Pod都無法使用并且無法提供實時流量的情況。

1.4.1 部署運(yùn)行多個副本

永遠(yuǎn)不要僅運(yùn)行一個pod

利用控制器Deployment, DaemonSet, ReplicaSet or StatefulSet.來運(yùn)行pod，不應(yīng)該將應(yīng)用運(yùn)行為自主式pod

可以參考：Running more than one instance your of your Pods guarantees that deleting a single Pod won’t cause downtime.

1.4.2 避免將Pod放置在單個節(jié)點中

即使您運(yùn)行Pod的多個副本，也無法保證丟失節(jié)點不會破壞您的服務(wù)。

如果你在單一node上運(yùn)行一個11個副本集的pod，如果這個node故障，這個服務(wù)也一樣會停機(jī)

運(yùn)行反親和性在集群中：You should apply anti-affinity rules to your Deployments so that Pods are spread in all the nodes of your cluster.

詳細(xì)可以參考：inter-pod affinity and anti-affinity

1.4.3 設(shè)置Pod中斷預(yù)算

當(dāng)一個node被打上污點，pod是要被刪除并且重新調(diào)度

但是如果你的系統(tǒng)壓力很大，不能接受丟失50%的pod這時候改怎么辦呢，驅(qū)逐pod可能會影響你的服務(wù)

為了保護(hù)部署免受可能同時摧毀多個Pod的意外事件的影響，可以定義Pod中斷預(yù)算。

想象一下：“ Kubernetes，請確保我的應(yīng)用始終至少有5個Pod在運(yùn)行”。

如果最終狀態(tài)導(dǎo)致該部署的Pod少于5個，Kubernetes將阻止耗盡事件。

官網(wǎng)參考文檔：Pod Disruption Budgets.

1.5 資源使用

為了最大化調(diào)度程序的效率，您應(yīng)該與Kubernetes共享詳細(xì)信息，例如資源利用，工作負(fù)載優(yōu)先級和開銷。

1.5.1 設(shè)置所有容器的內(nèi)存限制和請求

資源限制用于限制容器可以使用多少CPU和內(nèi)存，并使用containerSpec的resources屬性設(shè)置。調(diào)度程序?qū)⑦@些用作度量標(biāo)準(zhǔn)之一，以確定哪個節(jié)點最適合當(dāng)前Pod。根據(jù)調(diào)度程序，沒有內(nèi)存限制的容器的內(nèi)存利用率為零。如果可調(diào)度在任何節(jié)點上的Pod數(shù)量不受限制，則會導(dǎo)致資源超額使用，并可能導(dǎo)致節(jié)點（和kubelet）崩潰。

同用的可以適用于CPU限制

但是，您是否應(yīng)該始終設(shè)置內(nèi)存和CPU的限制和要求？

如果您的進(jìn)程超出內(nèi)存限制，則該進(jìn)程將終止。由于CPU是可壓縮的資源，因此如果您的容器超出限制，則將限制該過程。

如果您想更深入地研究CPU和內(nèi)存限制，則應(yīng)查看以下文章：

Understanding resource limits in kubernetes: memory

Understanding resource limits in kubernetes: cpu time

請注意，如果不確定什么是正確的CPU或內(nèi)存限制，則可以在建議模式打開的情況下使用Kubernetes中的Vertical Pod Autoscaler。自動縮放器會分析您的應(yīng)用并建議限制。

1.5.2 將CPU請求設(shè)置為1個CPU或以下

除非你有計算類型的實例類型job

it is recommended to set the request to 1 CPU or below.

1.5.3 禁用CPU限制—除非您有很好的用例

CPU以每個時間單位的CPU時間單位來度量。

cpu：1表示每秒1個CPU秒。

如果您有1個線程，則每秒消耗的CPU時間不能超過1秒。

如果您有2個線程，則可以在0.5秒內(nèi)消耗1個CPU秒。

8個線程可以在0.125秒內(nèi)消耗1個CPU秒。之后，您的過程將受到限制。

如果不確定您的應(yīng)用程序的最佳設(shè)置是什么，最好不要設(shè)置CPU限制。

深入研究可參考：this article digs deeper in CPU requests and limits.

1.5.4 命名空間具有LimitRange

如果您認(rèn)為可能忘記設(shè)置內(nèi)存和CPU限制，則應(yīng)考慮使用LimitRange對象為當(dāng)前名稱空間中部署的容器定義標(biāo)準(zhǔn)大小。

可參考：The official documentation about LimitRange

1.5.5 為Pod設(shè)置適當(dāng)?shù)姆?wù)質(zhì)量（QoS）

當(dāng)一個節(jié)點進(jìn)入過量使用狀態(tài)（即使用過多資源）時，Kubernetes試圖驅(qū)逐該節(jié)點中的某些Pod。Kubernetes根據(jù)定義明確的邏輯對Pod進(jìn)行排名和逐出。

參考：configuring the quality of service for your Pods

1.6 標(biāo)記資源

1.6.1 資源已定義技術(shù)標(biāo)簽

你能通過以下tag標(biāo)記pod

名稱，應(yīng)用程序的名稱，例如“用戶API”

實例，標(biāo)識應(yīng)用程序?qū)嵗奈ㄒ幻Q（您可以使用容器圖像標(biāo)簽）

版本，應(yīng)用程序的當(dāng)前版本（增量計數(shù)器）

組件，架構(gòu)中的組件，例如“ API”或“數(shù)據(jù)庫”

部分，該應(yīng)用程序所屬的更高級別應(yīng)用程序的名稱，例如“支付網(wǎng)關(guān)”由…

管理，用于管理應(yīng)用程序（例如“ kubectl”或“ Helm”）的操作的工具

標(biāo)簽可參考：recommended by the official documentation.

建議不要標(biāo)記所有資源。

1.6.2 資源已定義業(yè)務(wù)標(biāo)簽

您可以使用以下標(biāo)簽標(biāo)記Pod：

owner：標(biāo)示改資源的負(fù)責(zé)人

project：聲明資源所屬的項目

business-unit：用于標(biāo)識與資源關(guān)聯(lián)的成本中心或業(yè)務(wù)部門；通常用于成本分配和跟蹤

1.6.3 資源定義安全等級標(biāo)簽

tag pod通過以下label

confidentiality：資源支持的特定數(shù)據(jù)保密級別的標(biāo)識符

compliance：an identifier for workloads designed to adhere to specific compliance requirements

1.7 日志

日志對于調(diào)試問題和監(jiān)視應(yīng)用程序活動特別有用。

1.7.1 應(yīng)用程序記錄到stdout和stderr

有兩種日志策略，主動方式與被動方式

使用被動方式日志記錄的應(yīng)用程序不需要了解了解日志記錄基礎(chǔ)結(jié)構(gòu)，而是將消息記錄到標(biāo)準(zhǔn)輸出中。

主動方式，該應(yīng)用程序與中間聚合器建立了網(wǎng)絡(luò)連接，將數(shù)據(jù)發(fā)送到第三方日志記錄服務(wù)，或直接寫入數(shù)據(jù)庫或索引。

最佳實踐：the twelve-factor app.

1.7.2 避免日志使用sidecars模式

如果希望將日志轉(zhuǎn)換應(yīng)用于具有非標(biāo)準(zhǔn)日志事件模型的應(yīng)用程序，則可能需要使用sidecar容器。

使用Sidecar容器，您可以在將日志條目運(yùn)送到其他地方之前對其進(jìn)行規(guī)范化。

例如，您可能需要先將Apache日志轉(zhuǎn)換為Logstash JSON格式，然后再將其發(fā)送到日志基礎(chǔ)結(jié)構(gòu)。

但是，如果您可以控制應(yīng)用程序，則可以從一開始就輸出正確的格式。

sidecares啟動需要時間，您可以節(jié)省為群集中的每個Pod運(yùn)行額外的容器的時間。

1.8 伸縮

容器具有本地文件系統(tǒng)，您可能會想使用它來持久化數(shù)據(jù)。

但是，將持久性數(shù)據(jù)存儲在容器的本地文件系統(tǒng)中會阻止包圍的Pod進(jìn)行水平縮放（即通過添加或刪除Pod的副本）。

這是因為，通過使用本地文件系統(tǒng)，每個容器都維護(hù)自己的“狀態(tài)”，這意味著Pod副本的狀態(tài)可能會隨時間而變化。從用戶的角度來看，這會導(dǎo)致行為不一致（例如，當(dāng)請求命中一個Pod時，特定的用戶信息可用，但當(dāng)請求命中另一個Pod時，則不可用）。

相反，任何持久性信息都應(yīng)保存在Pod外部的中央位置。例如，在集群中的PersistentVolume中，或者在集群外部的某些存儲服務(wù)中甚至更好。

1.8.1 容器在其本地文件系統(tǒng)中不存儲任何狀態(tài)

容器具有本地文件系統(tǒng)，您可能會想使用它來持久化數(shù)據(jù)。

但是，將持久性數(shù)據(jù)存儲在容器的本地文件系統(tǒng)中會阻止包圍的Pod進(jìn)行水平縮放（即通過添加或刪除Pod的副本）。

這是因為，通過使用本地文件系統(tǒng)，每個容器都維護(hù)自己的“狀態(tài)”，這意味著Pod副本的狀態(tài)可能會隨時間而變化。從用戶的角度來看，這會導(dǎo)致行為不一致（例如，當(dāng)請求命中一個Pod時，特定的用戶信息可用，但當(dāng)請求命中另一個Pod時，則不可用）。

相反，任何持久性信息都應(yīng)保存在Pod外部的中央位置。例如，在集群中的PersistentVolume中，或者在集群外部的某些存儲服務(wù)中甚至更好。

1.8.2 對于可變使用模式的應(yīng)用應(yīng)該使用HPA

HPA是kubernetes內(nèi)置的一個特性它能夠監(jiān)控當(dāng)前的應(yīng)用和根據(jù)當(dāng)前的使用率自動添加及刪除POD副本

通過配置HPA來保障你的應(yīng)用在任何情況下包括（異常流量峰值）能夠保存可用及正常響應(yīng)

配置HPA自動伸縮你的應(yīng)用，需要去創(chuàng)建一個HPA的資源對象，該對象定義了監(jiān)控你應(yīng)用的什么指標(biāo)

HPA也能夠健康k8s內(nèi)置的資源指標(biāo)（POD的CPU/MEM資源使用率）或者自定義指標(biāo)，對于自定義指標(biāo)，你需要去收集和暴露這些指標(biāo)，例如你可用使用Prometheus/Prometheus Adapter

1.8.3 不要使用VPA，因為改特性還在測試中

當(dāng)POD需要更多資源時，VPA能夠通過自動的調(diào)整你的POD的資源請求和限制，

VPA非常適用于單體應(yīng)用無法進(jìn)行橫向副本數(shù)的擴(kuò)張

但是目前VPA仍然處于測試階段，垂直方向調(diào)整POD資源需要重啟POD

考慮到這些限制，更多的應(yīng)用在k8s中可用橫行擴(kuò)張，因此不要在生產(chǎn)環(huán)境中使用VPA

1.8.4 如果有很高的工作負(fù)載，可以使用集群自動伸縮

集群伸縮是區(qū)別于（HPA/VPA）的另一種伸縮類型

集群自動伸縮能夠通過增加或移除node節(jié)點來自動縮放集群的大小

當(dāng)由于現(xiàn)有一個node節(jié)點的資源不足導(dǎo)致pod調(diào)度失敗時，此刻集群會進(jìn)行擴(kuò)增操作，集群會增加一個work node來保證pod能夠正常調(diào)度，相似的，如果一個worker node資源使用率低，那么集群自動伸縮會先驅(qū)逐這個worker node上面的pod，最終去移除此node

對于集群工作負(fù)載很高的應(yīng)用場景下，就去自動伸縮非常有用，集群自動縮分可以讓你滿足需求高峰，而不會通過過度陪你走工作節(jié)點來浪費(fèi)資源。

對于工作負(fù)載不大的應(yīng)用場景，可以不用去設(shè)置集群自動伸縮，因為可能永遠(yuǎn)都使用不到改規(guī)則，如果你的集群工作負(fù)載緩慢增長，可以通過監(jiān)控系統(tǒng)來手動添加worker node

1.9 配置和密鑰

1.9.1 外部化所有配置

配置應(yīng)該在應(yīng)用之外的代碼維護(hù)，這有一些好處

更改配置不用重新編譯代碼

當(dāng)應(yīng)用程序正在運(yùn)行，配置文件可以單獨被更新

相同的代碼能夠被用于不同的環(huán)境

在Kubernetes中，可以將配置保存在ConfigMaps中，然后可以在將卷作為環(huán)境變量傳入時將其安裝到容器中。

在ConfigMap中僅保存非敏感配置。對于敏感信息（例如憑據(jù)），請使用Secret資源。

1.9.2 將Secrets作為卷而不是環(huán)境變量

Secret資源的內(nèi)容應(yīng)作為卷掛載到容器中，而不是作為環(huán)境變量傳遞。

這是為了防止秘密值出現(xiàn)在用于啟動容器的命令中，該命令可能由不應(yīng)該訪問秘密值的人員檢查

二 管治

2.1 名稱空間限制

您不應(yīng)允許用戶使用比您事先同意的資源更多的資源。

群集管理員可以設(shè)置約束，以使用配額和限制范圍限制項目中使用的對象數(shù)量或計算資源數(shù)量。

詳細(xì)可參考；limit ranges

2.1.1 名稱空間限制范圍

如果為設(shè)置容器資源消耗限制，那么會出現(xiàn)容器資源爭搶導(dǎo)致其他容器異常狀況發(fā)生，

k8s有兩個特性來約束資源使用：ResourceQuota 和 LimitRange.

使用LimitRange對象，您可以定義資源請求的默認(rèn)值和名稱空間內(nèi)單個容器的限制。

在該命名空間內(nèi)創(chuàng)建的任何容器（未明確指定請求和限制值）都將分配默認(rèn)值。

2.1.2 名稱控制資源配額

你能夠在名稱空間中通過資源配額限制所有容器資源的總消耗量

定義名稱空間的資源配額會限制屬于該名稱空間的所有容器可以消耗的CPU，內(nèi)存或存儲資源的總量。

您還可以為其他Kubernetes對象設(shè)置配額，例如當(dāng)前名稱空間中的Pod數(shù)量。

如果您認(rèn)為有人可以利用您的集群并創(chuàng)建20000 ConfigMap，則可以使用LimitRange來防止這種情況。

2.2 POD安全策略

遭到破壞的容器

容器使用節(jié)點上不允許的資源，例如進(jìn)程，網(wǎng)絡(luò)或文件系統(tǒng)

一般來說，應(yīng)該將Pod的功能限制在最低限度。

2.2.1 啟用POD安全策略

例如，您可以使用Kubernetes Pod安全策略來限制：

訪問主機(jī)進(jìn)程或者網(wǎng)絡(luò)名稱空間

運(yùn)行授權(quán)的容器

容器運(yùn)行時的用戶

訪問主機(jī)的文件系統(tǒng)

linux能力，Seccomp or SELinux profiles

選擇正確的策略依賴于集群原生的特性，可以參考：Kubernetes Pod Security Policy best practices

2.2.2 禁用特權(quán)容器

在一個POD中，容器能夠作為特權(quán)模式容器運(yùn)行來不受限制訪問主機(jī)系統(tǒng)的資源

通常這樣是危險的，你應(yīng)該給有必要的制定容器可以訪問的等級，

特權(quán)Pod的有效使用案例包括在節(jié)點上使用硬件，例如GPU。

可以參考：learn more about security contexts and privileges containers from this article.

2.2.3 容器使用只讀文件系統(tǒng)

容器中使用只讀文件系統(tǒng)來強(qiáng)制保障容器的無狀態(tài)話

這種方式不僅能減輕風(fēng)險例如熱補(bǔ)丁，而且可以避免避免惡意程序在容器內(nèi)存儲或者操作數(shù)據(jù)的風(fēng)險。

使用只讀文件系統(tǒng)聽起來很簡單，但是實際還是有一些復(fù)雜

如果你需要寫日志或者存儲一些臨時文件在一個臨時目錄該怎么辦呢，可以參考：running containers securely in production.

2.2.4 避免利用root用戶啟動容器

在容器中運(yùn)行一個進(jìn)程與主機(jī)上運(yùn)行一個進(jìn)程沒有太大區(qū)別，只不過一些很小的元數(shù)據(jù)在容器中聲明

因此容器中的uid為0的用戶與主機(jī)上的root用戶相同

如果用戶設(shè)法脫離了以root用戶身份在容器中運(yùn)行的應(yīng)用程序，則他們可以使用同一root用戶獲得對主機(jī)的訪問權(quán)限。

配置容器以使用非特權(quán)用戶是防止特權(quán)升級攻擊的最佳方法。

詳細(xì)可以參考：article offers some detailed explanation examples of what happens when you run your containers as root.

2.2.5 限制能力

Linux功能使進(jìn)程能夠執(zhí)行許多特權(quán)操作，其中只有root用戶默認(rèn)可以執(zhí)行。

例如，CAP_CHOWN允許進(jìn)程“對文件UID和GID進(jìn)行任意更改”。

即使您的進(jìn)程不是以root身份運(yùn)行，進(jìn)程也有可能通過提升特權(quán)來使用那些類似root的功能。

最佳實踐：

Linux Capabilities: Why They Exist and How They Work

Linux Capabilities In Practice

2.2.6 防止特權(quán)升級

您應(yīng)該在關(guān)閉特權(quán)升級的情況下運(yùn)行容器，以防止使用setuid或setgid二進(jìn)制文件提升特權(quán)。

2.3 網(wǎng)絡(luò)策略

容器可以在與其他容器進(jìn)行網(wǎng)絡(luò)通訊，不需要進(jìn)行地址轉(zhuǎn)換

集群中的node節(jié)點可以與其他節(jié)點進(jìn)行網(wǎng)絡(luò)通訊

一個容器的IP地址始終是相同的，從另一個容器或其本身看時是獨立的。

如果您打算將群集分成較小的塊并在名稱空間之間進(jìn)行隔離，則第一條規(guī)則無濟(jì)于事。

想象一下您的集群中的用戶是否能夠使用集群中的任何其他服務(wù)。

現(xiàn)在，想象一下如果集群中的惡意用戶要獲得對集群的訪問權(quán)限，他們可以向整個集群發(fā)出請求。

要解決此問題，您可以定義如何使用網(wǎng)絡(luò)策略允許Pods在當(dāng)前名稱空間和跨名稱空間中進(jìn)行通信。

2.3.1 啟用網(wǎng)絡(luò)策略

Kubernetes網(wǎng)絡(luò)策略指定Pod組的訪問權(quán)限，就像云中的安全組用于控制對VM實例的訪問一樣。

換句話說，它在Kubernetes集群上運(yùn)行的Pod之間創(chuàng)建了防火墻。

可參考：Securing Kubernetes Cluster Networking.

2.3.2 每個命名空間中都有一個保守的NetworkPolicy

該存儲庫包含Kubernetes網(wǎng)絡(luò)策略的各種用例和示例YAML文件，以在您的設(shè)置中利用。如果你想知道

how to drop/restrict traffic to applications running on Kubernetes

2.4 基于角色的訪問控制RBAC

放棄所需的最小權(quán)限是一種常見的做法，但是實際操作又如何量化最小權(quán)限？

細(xì)粒度的策略提供了更高的安全性，但是需要更多的精力來進(jìn)行管理。

更大范圍的授權(quán)可以使不必要的API訪問服務(wù)帳戶，但更易于控制。

2.4.1 禁用默認(rèn)服務(wù)帳戶的自動掛載

請注意，默認(rèn)的ServiceAccount將自動安裝到所有Pod的文件系統(tǒng)中。您可能要禁用它并提供更詳細(xì)的策略。

可以參考：the default ServiceAccount is automatically mounted into the file system of all Pods.

2.4.2 RBAC策略設(shè)置為所需的最少特權(quán)

尋找有關(guān)如何設(shè)置RBAC規(guī)則的好的建議是一項挑戰(zhàn)。在Kubernetes RBAC的3種現(xiàn)實方法中，您可以找到三種實用場景和有關(guān)如何入門的實用建議。

參考；3 realistic approaches to Kubernetes RBAC

2.4.3 RBAC策略是精細(xì)的，不能共享

需求：

允許用戶可以部署，但是不允許去讀secrets

admin應(yīng)該可以訪問所有資源

默認(rèn)情況下，應(yīng)用程序不應(yīng)獲得對Kubernetes API的寫訪問權(quán)限

對于某些用途，應(yīng)該可以寫入Kubernetes API。

四個要求轉(zhuǎn)化為五個單獨的角色：

ReadOnly

PowerUser

Operator

Controller

Admin

2.5 自定義策略

例如，您可能要避免從公共互聯(lián)網(wǎng)下載容器，而希望首先批準(zhǔn)這些容器。

也許您有一個內(nèi)部注冊表，并且只有此注冊表中的映像可以部署在您的群集中。

您如何強(qiáng)制只能在群集中部署受信任的容器？沒有針對此的RBAC政策。

2.5.1 僅允許從已知注冊表部署容器

您可能要考慮的最常見的自定義策略之一是限制可以在群集中部署的映像。

The following tutorial explains how you can use the Open Policy Agent to restrict not approved images.

2.5.2 強(qiáng)制Ingress主機(jī)名唯一

用戶創(chuàng)建Ingress清單時，可以使用其中的任何主機(jī)名。

但是，您可能希望阻止用戶多次使用相同的主機(jī)名并互相覆蓋。Open Policy Agent的官方文檔包含有關(guān)如何在驗證Webhook中檢查Ingress資源的教程。

a tutorial on how to check Ingress resources as part of the validation webhook.

2.5.3 僅在Ingress主機(jī)名中使用批準(zhǔn)的域名

用戶創(chuàng)建Ingress清單時，可以使用其中的任何主機(jī)名。一種

但是，您可能希望阻止用戶使用無效的主機(jī)名。Open Policy Agent的官方文檔包含有關(guān)如何在驗證Webhook中檢查Ingress資源的教程。

三 集群配置

最好的選擇是將群集與標(biāo)準(zhǔn)參考進(jìn)行比較。

對于Kubernetes，參考是Internet安全中心（CIS）基準(zhǔn)。

3.1 批準(zhǔn)的Kubernetes配置

3.1.1 集群通過CIS基準(zhǔn)測試

Internet安全中心提供了一些準(zhǔn)則和基準(zhǔn)測試，以確保代碼安全的最佳實踐。

他們還維護(hù)了Kubernetes的基準(zhǔn)，您可以download from the official website.

kube-bench是一種工具，用于自動執(zhí)行CIS Kubernetes基準(zhǔn)測試并報告集群中的錯誤配置。

[INFO] 1 Master Node Security Configuration
[INFO] 1.1 API Server
[WARN] 1.1.1 Ensure that the --anonymous-auth argument is set to false (Not Scored)
[PASS] 1.1.2 Ensure that the --basic-auth-file argument is not set (Scored)
[PASS] 1.1.3 Ensure that the --insecure-allow-any-token argument is not set (Not Scored)
[PASS] 1.1.4 Ensure that the --kubelet-https argument is set to true (Scored)
[PASS] 1.1.5 Ensure that the --insecure-bind-address argument is not set (Scored)
[PASS] 1.1.6 Ensure that the --insecure-port argument is set to 0 (Scored)
[PASS] 1.1.7 Ensure that the --secure-port argument is not set to 0 (Scored)
[FAIL] 1.1.8 Ensure that the --profiling argument is set to false (Scored)

請注意，無法使用kube-bench檢查托管集群（例如GKE，EKS和AKS）的主節(jié)點。主節(jié)點由云提供商控制。

3.1.2 禁用元數(shù)據(jù)云提供程序元數(shù)據(jù)API

云平臺（AWS，Azure，GCE等）通常將本地元數(shù)據(jù)服務(wù)公開給實例。

默認(rèn)情況下，實例上運(yùn)行的Pod可以訪問這些API，并且可以包含該節(jié)點的云憑據(jù)或諸如kubelet憑據(jù)之類的置備數(shù)據(jù)。

這些憑據(jù)可用于在群集內(nèi)升級或升級到同一帳戶下的其他云服務(wù)。

3.1.3 限制對Alpha或Beta功能的訪問

Alpha和Beta Kubernetes功能正在積極開發(fā)中，并且可能會存在限制或錯誤，從而導(dǎo)致安全漏洞。

始終評估Alpha或Beta功能可能提供的價值，以防對您的安全狀況造成潛在風(fēng)險。

如有疑問，請禁用不使用的功能。

3.2 認(rèn)證

kubernetes提供了不同的認(rèn)證策略

Static Tokens:很難使之無效，應(yīng)避免

Bootstrap Tokens：與上面的靜態(tài)令牌相同

Basic Authentication：通過網(wǎng)絡(luò)以明文形式傳輸憑據(jù)

X509 client certs：需要定期更新和重新分發(fā)客戶端證書

Service Account Tokens：是集群中運(yùn)行的應(yīng)用程序和工作負(fù)載的首選身份驗證策略

OpenID Connect (OIDC) Tokens：OIDC與您的身份提供商（例如AD，AWS IAM，GCP IAM等）集成后，為最終用戶提供了最佳的身份驗證策略。

更多詳細(xì)策略可參考：in the official documentation.

3.2.1 使用OpenID（OIDC）令牌作為用戶身份驗證策略

Kubernetes支持各種身份驗證方法，包括OpenID Connect（OIDC）。

OpenID Connect允許單點登錄（SSO）（例如您的Google身份）連接到Kubernetes集群和其他開發(fā)工具。

你不用分別取記憶和管理認(rèn)證，您可能有多個群集連接到同一OpenID提供程序。

詳細(xì)可以參考：learn more about the OpenID connect in Kubernetes

3.3 RBAC

3.3.1 ServiceAccount令牌僅適用于應(yīng)用程序和控制器

服務(wù)帳戶令牌不應(yīng)該用于嘗試與Kubernetes群集進(jìn)行交互的最終用戶，但對于在Kubernetes上運(yùn)行的應(yīng)用程序和工作負(fù)載，它們是首選的身份驗證策略。

3.4 日志設(shè)定

3.4.1 有一個日志保留和歸檔策略

您應(yīng)該保留30-45天的歷史日志。

3.4.2 從節(jié)點，控制平面，審核中收集日志

從那收集日志?

Nodes（kubelet，container runtime）

控制平面（API server，scheduler，controller manager）

k8s 審計（對API服務(wù)器的所有請求）

應(yīng)該收集什么?

應(yīng)用名稱

應(yīng)用實例

應(yīng)用版本

集群ID

容器名稱

容器運(yùn)行在集群的那個node節(jié)點上

容器運(yùn)行在那個pod內(nèi)

名稱空間

3.4.3 在每個節(jié)點上最好使用守護(hù)程序來收集日志，而不是在每個中運(yùn)行sidecars

應(yīng)用程序應(yīng)該登錄到標(biāo)準(zhǔn)輸出，而不是文件。

每個節(jié)點上的守護(hù)程序可以從容器運(yùn)行時收集日志（如果記錄到文件，則可能需要每個pod的sidecar容器）。

3.4.4 提供日志聚合工具

使用日志聚合工具，例如EFK堆棧（Elasticsearch，F(xiàn)luentd，Kibana），DataDog，Sumo Logic，Sysdig，GCP Stackdriver，Azure Monitor，AWS CloudWatch。

審核編輯：黃飛