kubernetes生產(chǎn)環(huán)境最佳實(shí)踐

本文僅提供在kubernetes上部署安全、可擴(kuò)展和彈性服務(wù)的可行性最佳實(shí)踐。僅供參考。

精選的最佳實(shí)踐清單，旨在幫助您發(fā)布到生產(chǎn)環(huán)境。

應(yīng)用開發(fā)

健康檢查

• 容器要有就緒探針
• 注意：readiness probe（就緒探針） 和 liveness probe（存活探針） 沒有默認(rèn)值。
• 如果您沒有設(shè)置就緒探測，kubelet 會(huì)假定應(yīng)用程序已準(zhǔn)備好在容器啟動(dòng)后立即接收流量。
• 如果容器需要 2 分鐘才能啟動(dòng)，那么在這 2 分鐘內(nèi)對(duì)它的所有請求都將失敗。
• 發(fā)生不可恢復(fù)錯(cuò)誤（致命錯(cuò)誤）時(shí)讓容器崩潰
• 如果應(yīng)用程序遇到不可恢復(fù)的錯(cuò)誤，您應(yīng)該讓它崩潰。
• 此類不可恢復(fù)錯(cuò)誤的示例如下：
• 未捕獲的異常
• 代碼中的錯(cuò)字（對(duì)于動(dòng)態(tài)語言）
• 無法加載標(biāo)頭或依賴項(xiàng)
• 請注意，您不應(yīng)發(fā)出失敗的 Liveness 探測信號(hào)。
• 相反，您應(yīng)該立即退出進(jìn)程并讓 kubelet 重新啟動(dòng)容器。
• 配置被動(dòng)liveness探測
• Liveness 探針旨在在容器卡住時(shí)重新啟動(dòng)容器。
• 考慮以下場景：如果您的應(yīng)用程序正在處理無限循環(huán)，則無法退出或?qū)で髱椭?/li>
• 當(dāng)進(jìn)程消耗 100% CPU 時(shí)，它沒有時(shí)間回復(fù)（其他）Readiness 探測檢查，最終會(huì)從 Service 中刪除。
• 但是，Pod 仍然注冊為當(dāng)前 Deployment 的活動(dòng)副本。
• 如果您沒有 Liveness 探針，它會(huì)保持運(yùn)行但與服務(wù)分離。
• 換句話說，該進(jìn)程不僅不服務(wù)任何請求，而且還在消耗資源。
• 你該怎么辦？
• 從您的應(yīng)用程序公開端點(diǎn)
• 端點(diǎn)始終回復(fù)成功響應(yīng)
• 使用 Liveness 探針中的端點(diǎn)
• 請注意，您不應(yīng)使用 Liveness 探針來處理應(yīng)用程序中的致命錯(cuò)誤并請求 Kubernetes 重新啟動(dòng)應(yīng)用程序。
• 相反，您應(yīng)該讓應(yīng)用程序崩潰。
• 只有在進(jìn)程沒有響應(yīng)的情況下，才應(yīng)將 Liveness 探針用作恢復(fù)機(jī)制。
• readiness probe（就緒探針） 和 liveness probe（存活探針）的值要確保不相同
• 如果Liveness和Readiness值相同時(shí)，如果應(yīng)用程序發(fā)出未準(zhǔn)備好或未上線的信號(hào)時(shí)，kubelet會(huì)將容器從服務(wù)中分離并刪除，可能會(huì)導(dǎo)致連接丟失。因?yàn)槿萜鳑]有足夠的時(shí)間來處理傳入的連接。

應(yīng)用程序獨(dú)立部署

readiness probe（就緒探針）是獨(dú)立的

就緒探測不包括對(duì)服務(wù)的依賴，例如：

• databases
• database migrations
• APIs
• 第三方服務(wù)

參考鏈接：https://blog.colinbreck.com/kubernetes-liveness-and-readiness-probes-how-to-avoid-shooting-yourself-in-the-foot/#shootingyourselfinthefootwithreadinessprobes

應(yīng)用程序的重連機(jī)制

當(dāng)應(yīng)用程序啟動(dòng)時(shí)，它不應(yīng)該因?yàn)閿?shù)據(jù)庫等依賴項(xiàng)尚未準(zhǔn)備好而崩潰。

相反，應(yīng)用程序應(yīng)該不斷重試連接到數(shù)據(jù)庫，直到成功。

Kubernetes 期望應(yīng)用程序組件可以以任何順序啟動(dòng)。

當(dāng)您確保您的應(yīng)用程序可以重新連接到依賴項(xiàng)（例如數(shù)據(jù)庫）時(shí)，您就知道您可以提供更強(qiáng)大和更有彈性的服務(wù)。

優(yōu)雅關(guān)閉應(yīng)用程序

應(yīng)用程序不會(huì)再接收到SIGTERM后立即關(guān)閉，等待一段時(shí)間后，優(yōu)雅終止連接

pod即使在收到終止信號(hào)后，可能也需要繼續(xù)接受連接，直到所有的kube-proxy完成對(duì)iptables規(guī)則或ipvs規(guī)則的更新。

可能ingress-controller以及Loadblance也會(huì)將連接轉(zhuǎn)發(fā)到POD。

為確保所有客戶端都不會(huì)遇到斷開連接，您必須等到所有客戶端都以某種方式通知您他們將不再將連接轉(zhuǎn)發(fā)到 pod。

但是顯然，這是不可能的，因?yàn)樗羞@些組件都分布在許多不同的計(jì)算機(jī)上。如果有一個(gè)沒有寫響應(yīng)，都會(huì)導(dǎo)致應(yīng)用無法關(guān)閉。

一般情況下我們會(huì)配置一個(gè)預(yù)停止的hook：

lifecycle: preStop: exec: command: – sh – c – “sleep 5”

將SIGTERM信號(hào)轉(zhuǎn)發(fā)給進(jìn)程

當(dāng)pod即將終止時(shí)，可以通過在應(yīng)用程序中捕獲SIGTERM信號(hào)?？梢允褂胻ini。tini項(xiàng)目地址：https://github.com/krallin/tini

關(guān)閉所有的空閑的kaap-alive套接字

如果調(diào)用應(yīng)用程序沒有關(guān)閉TCP連接；當(dāng)pod被刪除時(shí)；理想情況下，請求應(yīng)該發(fā)送到另一個(gè) Pod；但是，調(diào)用應(yīng)用程序與即將終止的 Pod 建立了長期連接，并將繼續(xù)使用它；不應(yīng)該突然終止長期連接；您應(yīng)該在關(guān)閉應(yīng)用程序之前終止它們。

容錯(cuò)機(jī)制

為部署的POD運(yùn)行多個(gè)副本

永遠(yuǎn)不要單獨(dú)運(yùn)行單個(gè) Pod。

而是考慮將 Pod 部署為 Deployment、DaemonSet、ReplicaSet 或 StatefulSet 的一部分。

運(yùn)行多個(gè) Pod 實(shí)例可確保刪除單個(gè) Pod 不會(huì)導(dǎo)致停機(jī)。

避免將 Pod 放置到單個(gè)節(jié)點(diǎn)中

考慮以下場景：單個(gè)集群節(jié)點(diǎn)上有 11 個(gè)副本。

如果節(jié)點(diǎn)不可用，則 11 個(gè)副本將丟失，并且您有停機(jī)時(shí)間。

您應(yīng)該將反關(guān)聯(lián)規(guī)則應(yīng)用于您的部署，以便 Pod 分布在集群的所有節(jié)點(diǎn)中。

pod間親和性和反親和性文檔描述了如何將 Pod 更改為位于（或不在）同一節(jié)點(diǎn)中。

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

Set Pod disruption budgets

翻譯過來就是配置POD干擾預(yù)算；通過設(shè)置應(yīng)用 Pod 處于正常狀態(tài)的最低個(gè)數(shù)或最低百分比，這樣可以保證在主動(dòng)銷毀 Pod 的時(shí)候，不會(huì)銷毀太多的 Pod 導(dǎo)致業(yè)務(wù)異常中斷，從而提高業(yè)務(wù)的可用性。

參考鏈接：https://zhuanlan.zhihu.com/p/367827614

官方文檔是了解Pod Disruption Budgetshttps://kubernetes.io/docs/concepts/workloads/pods/disruptions/

資源利用

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

資源限制用于限制您的容器可以使用多少 CPU 和內(nèi)存，并使用containerSpec 字段進(jìn)行配置。

調(diào)度程序使用這些作為指標(biāo)之一來決定哪個(gè)節(jié)點(diǎn)最適合當(dāng)前 Pod。

沒有做資源限制的容器調(diào)度優(yōu)先級(jí)為0.即當(dāng)發(fā)生OOM時(shí)，會(huì)先停掉此類容器。

由于 CPU 是一種可壓縮資源，因此如果您的容器超出限制，則進(jìn)程會(huì)受到限制。

請注意，如果您不確定正確的CPU 或內(nèi)存限制應(yīng)該是多少，您可以在 Kubernetes 中使用Vertical Pod Autoscaler并打開推薦模式。自動(dòng)縮放器會(huì)分析您的應(yīng)用并為其推薦限制。

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

除非您有計(jì)算密集型作業(yè)，否則建議將請求設(shè)置為 1 CPU 或以下。

禁用CPU限制

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

如果您想了解更多信息，本文將深入探討 CPU 請求和限制。https://medium.com/@betz.mark/understanding-resource-limits-in-kubernetes-cpu-time-9eff74d3161b

為namesapce（名稱空間）設(shè)置LimitRange

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

LimitRange 的官方文檔https://kubernetes.io/docs/concepts/policy/limit-range/

為Pod設(shè)置適當(dāng)?shù)腝os（服務(wù)質(zhì)量）

當(dāng)一個(gè)節(jié)點(diǎn)資源使用率過高時(shí)，kubernetes會(huì)嘗試驅(qū)驅(qū)逐該節(jié)點(diǎn)中的一些pod。

kubernetes會(huì)根據(jù)定義的優(yōu)先級(jí)以及Qos對(duì)pod進(jìn)行排名和驅(qū)逐。

關(guān)于如何配置Qos可參考官方文檔 :https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/

資源標(biāo)記

定義技術(shù)相關(guān)標(biāo)簽

下面是官方推薦的相關(guān)技術(shù)的標(biāo)簽：

官方文檔：https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/

• name, 應(yīng)用程序的名稱，例如“用戶 API”
• instance，標(biāo)識(shí)應(yīng)用程序?qū)嵗奈ㄒ幻Q（您可以使用容器image標(biāo)簽）
• version，應(yīng)用程序的當(dāng)前版本（增量計(jì)數(shù)器）
• component，架構(gòu)內(nèi)的組件，例如“API”或“數(shù)據(jù)庫”
• part-of, 一個(gè)更高級(jí)別的應(yīng)用程序的名稱，這是“支付網(wǎng)關(guān)”的一部分
• managed-by，用于管理應(yīng)用程序操作的工具，例如“kubectl”或“Helm”

示例：

apiVersion: apps/v1 kind: Deployment metadata: name: deployment labels: app.kubernetes.io/name: user-api app.kubernetes.io/instance: user-api-5fa65d2 app.kubernetes.io/version: “42” app.kubernetes.io/component: api app.kubernetes.io/part-of: payment-gateway app.kubernetes.io/managed-by: kubectl spec: replicas: 3 selector: matchLabels: application: my-app template: metadata: labels: app.kubernetes.io/name: user-api app.kubernetes.io/instance: user-api-5fa65d2 app.kubernetes.io/version: “42” app.kubernetes.io/component: api app.kubernetes.io/part-of: payment-gateway spec: containers: – name: app image: myapp

定義業(yè)務(wù)標(biāo)簽

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

• owner，用于標(biāo)識(shí)誰負(fù)責(zé)該資源
• project，用于確定資源所屬的項(xiàng)目
• business-unit，用于標(biāo)識(shí)與資源關(guān)聯(lián)的成本中心或業(yè)務(wù)單位；通常用于成本分配和跟蹤。

示例

apiVersion: apps/v1 kind: Deployment metadata: name: deployment labels: owner: payment-team project: fraud-detection business-unit: “80432” spec: replicas: 3 selector: matchLabels: application: my-app template: metadata: labels: owner: payment-team project: fraud-detection business-unit: “80432” spec: containers: – name: app image: myapp

定義安全標(biāo)簽

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

• confidentiality，資源支持的特定數(shù)據(jù)機(jī)密級(jí)別的標(biāo)識(shí)符
• compliance，旨在遵守特定合規(guī)性要求的工作負(fù)載標(biāo)識(shí)符

示例：

apiVersion: apps/v1 kind: Deployment metadata: name: deployment labels: confidentiality: official compliance: pci spec: replicas: 3 selector: matchLabels: application: my-app template: metadata: labels: confidentiality: official compliance: pci spec: containers: – name: app image: myapp

日志記錄

應(yīng)用程序日志輸出到stdout和stderr

有兩種日志記錄策略：passive（被動(dòng)） 和 active（主動(dòng)）

使用被動(dòng)策略的應(yīng)用程序?qū)⑷罩鞠⒂涗浀綐?biāo)準(zhǔn)輸出。

此最佳實(shí)踐是十二因素應(yīng)用程序的一部分。

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

主動(dòng)日志記錄被認(rèn)為是一種反模式，應(yīng)該避免。

避免使用sidecar進(jìn)行日志記錄（如果可以的話）

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

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

例如，您可能希望在將 Apache 日志傳送到日志基礎(chǔ)設(shè)施之前將其轉(zhuǎn)換為 Logstash JSON 格式。

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

您可以節(jié)省為集群中的每個(gè) Pod 運(yùn)行一個(gè)額外的容器。

縮放

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

容器有一個(gè)本地文件系統(tǒng)，你可能會(huì)想用它來持久化數(shù)據(jù)。

但是，將持久數(shù)據(jù)存儲(chǔ)在容器的本地文件系統(tǒng)中會(huì)阻止包含的 Pod 水平擴(kuò)展（即，通過添加或刪除 Pod 的副本）。

這是因?yàn)椋ㄟ^使用本地文件系統(tǒng)，每個(gè)容器都維護(hù)自己的“狀態(tài)”，這意味著 Pod 副本的狀態(tài)可能會(huì)隨著時(shí)間的推移而發(fā)散。這會(huì)導(dǎo)致從用戶的角度來看不一致的行為（例如，當(dāng)請求命中一個(gè) Pod 時(shí)，一條特定的用戶信息可用，但當(dāng)請求命中另一個(gè) Pod 時(shí)則不可用）。

相反，任何持久性信息都應(yīng)該保存在 Pod 之外的中心位置。例如，在集群中的一個(gè) PersistentVolume 中，甚至在集群外的一些存儲(chǔ)服務(wù)中更好。

將 Horizontal Pod Autoscaler 用于具有可變使用模式的應(yīng)用程序

Horizontal Pod Autoscaler (HPA)是一個(gè)內(nèi)置的 Kubernetes 功能，可以監(jiān)控您的應(yīng)用程序并根據(jù)當(dāng)前使用情況自動(dòng)添加或刪除 Pod 副本。

配置 HPA 可讓您的應(yīng)用在任何流量條件下（包括意外高峰）保持可用和響應(yīng)。

要將 HPA 配置為自動(dòng)縮放您的應(yīng)用程序，您必須創(chuàng)建一個(gè)HorizontalPodAutoscaler資源，該資源定義了要為您的應(yīng)用程序監(jiān)控的指標(biāo)。

HPA 可以監(jiān)控內(nèi)置資源指標(biāo)（Pod 的 CPU 和內(nèi)存使用情況）或自定義指標(biāo)。在自定義指標(biāo)的情況下，您還負(fù)責(zé)收集和公開這些指標(biāo)，例如，您可以使用Prometheus和Prometheus Adapter來做到這一點(diǎn)。

請勿在 Vertical Pod Autoscaler 仍處于測試階段時(shí)使用它

與Horizontal Pod Autoscaler (HPA)類似， Vertical Pod Autoscaler (VPA)也存在。

VPA 可以自動(dòng)適應(yīng)你 Pod 的資源請求和限制，這樣當(dāng)一個(gè) Pod 需要更多資源時(shí)，它可以得到它們（增加/減少單個(gè) Pod 的資源稱為垂直擴(kuò)展，而不是水平擴(kuò)展，這意味著增加/減少 Pod 的副本數(shù)）。

這對(duì)于擴(kuò)展無法水平擴(kuò)展的應(yīng)用程序很有用。

然而，VPA 目前處于 beta 階段，它有一些已知的限制（例如，通過改變 Pod 的資源需求來擴(kuò)展 Pod，需要?dú)⑺啦⒅匦聠?dòng) Pod）。

鑒于這些限制，以及 Kubernetes 上的大多數(shù)應(yīng)用程序無論如何都可以水平擴(kuò)展的事實(shí)，建議不要在生產(chǎn)中使用 VPA（至少在有穩(wěn)定版本之前）。

如果您有高度變化的工作負(fù)載，請使用 Cluster Autoscaler

Cluster Autoscaler是另一種類型的“autoscaler”（除了Horizo ntal Pod Autoscaler和Vertical Pod Autoscaler）。

Cluster Autoscaler 可以通過添加或刪除工作節(jié)點(diǎn)來自動(dòng)擴(kuò)展集群的大小。

當(dāng) Pod 由于現(xiàn)有工作節(jié)點(diǎn)上的資源不足而無法調(diào)度時(shí)，就會(huì)發(fā)生擴(kuò)展操作。在這種情況下，Cluster Autoscaler 會(huì)創(chuàng)建一個(gè)新的工作節(jié)點(diǎn)，以便 Pod 可以被調(diào)度。同樣，當(dāng)現(xiàn)有工作節(jié)點(diǎn)的利用率較低時(shí)，集群自動(dòng)縮放器可以通過從一個(gè)工作節(jié)點(diǎn)中逐出所有工作負(fù)載并將其移除來縮減規(guī)模。

使用 Cluster Autoscaler 對(duì)于高度可變的工作負(fù)載是有意義的，例如，當(dāng) Pod 的數(shù)量可能在短時(shí)間內(nèi)增加，然后又回到之前的值時(shí)。在這種情況下，Cluster Autoscaler 允許您通過過度配置工作節(jié)點(diǎn)來滿足需求高峰，而不會(huì)浪費(fèi)資源。

但是，如果您的工作負(fù)載變化不大，則可能不值得設(shè)置 Cluster Autoscaler，因?yàn)樗赡苡肋h(yuǎn)不會(huì)被觸發(fā)。如果您的工作負(fù)載增長緩慢且單調(diào)，那么監(jiān)控現(xiàn)有工作節(jié)點(diǎn)的利用率并在達(dá)到臨界值時(shí)手動(dòng)添加一個(gè)額外的工作節(jié)點(diǎn)可能就足夠了。

配置和Secret

外部化所有配置

配置應(yīng)在應(yīng)用程序代碼之外維護(hù)。

這有幾個(gè)好處。首先，更改配置不需要重新編譯應(yīng)用程序。其次，可以在應(yīng)用程序運(yùn)行時(shí)更新配置。第三，相同的代碼可以在不同的環(huán)境中使用。

在 Kubernetes 中，可以將配置保存在 ConfigMaps 中，然后可以將其掛載到容器中，因?yàn)榫碜鳛榄h(huán)境變量傳入。

在 ConfigMaps 中僅保存非敏感配置。對(duì)于敏感信息（例如憑證），請使用 Secret 資源。

將 Secret 掛載為卷，而不是環(huán)境變量

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

這是為了防止秘密值出現(xiàn)在用于啟動(dòng)容器的命令中，這可能會(huì)被不應(yīng)訪問秘密值的個(gè)人查看到。

Governance(治理)

命名空間限制

名稱空間配置LimitRange

沒有限制的容器可能會(huì)導(dǎo)致與其他容器的資源爭用和計(jì)算資源的未優(yōu)化消耗。

Kubernetes 有兩個(gè)限制資源使用的特性：ResourceQuota 和 LimitRange。

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

在該命名空間內(nèi)創(chuàng)建的任何容器，沒有明確指定請求和限制值，都會(huì)被分配默認(rèn)值。

資源配額，您應(yīng)該查看官方文檔。https://kubernetes.io/docs/concepts/policy/resource-quotas/

名稱空間配置ResourceQuota

使用 ResourceQuotas，您可以限制命名空間內(nèi)所有容器的總資源消耗。

為命名空間定義資源配額會(huì)限制屬于該命名空間的所有容器可以使用的 CPU、內(nèi)存或存儲(chǔ)資源的總量。

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

如果您認(rèn)為有人可以利用您的集群并創(chuàng)建 20000 個(gè) ConfigMap，那么使用 LimitRange 可以防止這種情況發(fā)生。

Pod安全策略

啟用Pod安全策略

可以使用 Kubernetes Pod 安全策略來限制：

• 訪問主機(jī)進(jìn)程或網(wǎng)絡(luò)命名空間
• 運(yùn)行特權(quán)容器
• 容器運(yùn)行的用戶
• 訪問主機(jī)文件系統(tǒng)
• Linux 功能、Seccomp 或 SELinux 配置文件

參考Kubernetes Pod安全策略最佳實(shí)戰(zhàn) https://www.mend.io/resources/blog/kubernetes-pod-security-policy/

禁用特權(quán)容器

在 Pod 中，容器可以在“特權(quán)”模式下運(yùn)行，并且?guī)缀蹩梢圆皇芟拗频卦L問主機(jī)系統(tǒng)上的資源。

雖然在某些特定用例中需要此級(jí)別的訪問權(quán)限，但總的來說，讓您的容器執(zhí)行此操作會(huì)帶來安全風(fēng)險(xiǎn)。

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

您可以從本文中了解有關(guān)安全上下文和權(quán)限容器的更多信息 ：https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

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

在容器中運(yùn)行只讀文件系統(tǒng)會(huì)強(qiáng)制容器不可變。

這不僅可以減輕一些舊的（和有風(fēng)險(xiǎn)的）做法，例如熱補(bǔ)丁，還可以幫助您防止惡意進(jìn)程在容器內(nèi)存儲(chǔ)或操作數(shù)據(jù)的風(fēng)險(xiǎn)。

使用只讀文件系統(tǒng)運(yùn)行容器可能聽起來很簡單，但它可能會(huì)帶來一些復(fù)雜性。

如果您需要在臨時(shí)文件夾中寫入日志或存儲(chǔ)文件怎么辦？

您可以在本文中了解有關(guān)在生產(chǎn)環(huán)境中安全運(yùn)行容器的權(quán)衡取舍： https://medium.com/@axbaretto/running-docker-containers-securely-in-production-98b8104ef68

防止容器以root身份運(yùn)行

在容器中運(yùn)行的進(jìn)程與主機(jī)上的任何其他進(jìn)程沒有什么不同，只是它有一小段元數(shù)據(jù)聲明它在容器中。

因此，容器中的 root 與主機(jī)上的 root (uid 0) 相同。

如果用戶設(shè)法突破在容器中以 root 身份運(yùn)行的應(yīng)用程序，他們可能能夠獲得對(duì)具有相同 root 用戶的主機(jī)的訪問權(quán)限。

將容器配置為使用非特權(quán)用戶，是防止提權(quán)攻擊的最佳方法。

如果您想了解更多信息，以下文章提供了一些詳細(xì)說明示例，說明當(dāng)您以 root 身份運(yùn)行容器時(shí)會(huì)發(fā)生什么 ：ttps://medium.com/@mccode/processes-in-containers-should-not-run-as-root-2feae3f0df3b

限制一些Linux功能

Linux 功能使進(jìn)程能夠執(zhí)行默認(rèn)情況下只有 root 用戶才能執(zhí)行的許多特權(quán)操作。

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

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

換句話說，如果您不想受到損害，您應(yīng)該只啟用您需要的功能。

但是應(yīng)該啟用哪些功能，為什么？

以下兩篇文章深入探討了有關(guān) Linux 內(nèi)核功能的理論和實(shí)踐最佳實(shí)踐：

• Linux 功能：它們?yōu)槭裁创嬖谝约八鼈兪侨绾喂ぷ鞯?：https://blog.container-solutions.com/linux-capabilities-why-they-exist-and-how-they-work
• 實(shí)踐中的 Linux 功能 https://blog.container-solutions.com/linux-capabilities-in-practice

防止Linux權(quán)限提升

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

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

集群中的惡意用戶要獲得對(duì)集群的訪問權(quán)限——他們可以向整個(gè)集群發(fā)出請求。

為了解決這個(gè)問題，您可以使用網(wǎng)絡(luò)策略定義如何允許 Pod 在當(dāng)前命名空間和跨命名空間中進(jìn)行通信。

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

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

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

Kubernetes 集群網(wǎng)絡(luò) : https://ahmet.im/blog/kubernetes-network-policy/

每個(gè)名稱空間中都應(yīng)該有一個(gè)默認(rèn)較保守的NetworkPolicy

如果想深入了解如何丟棄/限制運(yùn)行在 Kubernetes 上的應(yīng)用程序的流量，請查看此文檔。 https://github.com/ahmetb/kubernetes-network-policy-recipes

基于角色的訪問控制（RBAC）策略

禁用默認(rèn)ServiceAccount的自動(dòng)掛載

請注意，默認(rèn)的 ServiceAccount 會(huì)自動(dòng)掛載到所有 Pod 的文件系統(tǒng)中。

您可能希望禁用它并提供更精細(xì)的策略。

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

很難找到關(guān)于如何設(shè)置 RBAC 規(guī)則的好建議。在Kubernetes RBAC 的 3 種實(shí)際方法中，您可以找到三個(gè)實(shí)際場景和有關(guān)如何開始的實(shí)用建議。

實(shí)際場景參考文檔：https://thenewstack.io/three-realistic-approaches-to-kubernetes-rbac/

RBAC策略是細(xì)粒度且不共享

有一個(gè)簡明的策略來定義角色和 ServiceAccounts。

首先，他們描述了他們的要求：

• 用戶應(yīng)該能夠部署，但他們不應(yīng)該被允許閱讀 Secrets 例如
• 管理員應(yīng)該獲得對(duì)所有資源的完全訪問權(quán)限
• 默認(rèn)情況下，應(yīng)用程序不應(yīng)獲得對(duì) Kubernetes API 的寫入權(quán)限
• 應(yīng)該可以寫入 Kubernetes API 以用于某些用途。

這四個(gè)要求轉(zhuǎn)化為五個(gè)單獨(dú)的角色：

• 只讀
• 超級(jí)用戶
• 操作員
• 控制器
• 行政

您可以在此鏈接中了解他們的定義：https://kubernetes-on-aws.readthedocs.io/en/latest/dev-guide/arch/access-control/adr-004-roles-and-service-accounts.html

自定義策略

僅允許從已知的鏡像倉庫部署容器

在Ingress強(qiáng)制定義域名的唯一性

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

集群配置

推薦的Kubernetes配置

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

互聯(lián)網(wǎng)安全中心為保護(hù)您的代碼的最佳實(shí)踐提供了一些指南和基準(zhǔn)測試。

他們還維護(hù)了kubernetes的基準(zhǔn)；官網(wǎng)地址：https://www.cisecurity.org/benchmark/kubernetes

雖然您可以閱讀冗長的指南并手動(dòng)檢查您的集群是否合規(guī)，但更簡單的方法是下載并執(zhí)行kube-bench.

下載地址：https://github.com/aquasecurity/kube-bench

kube-bench是一種工具，旨在自動(dòng)化 CIS Kubernetes 基準(zhǔn)測試并報(bào)告集群中的錯(cuò)誤配置。

示例輸出：

[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)

當(dāng)master由云廠商托管的話，可能無法使用kube-bench。

限制對(duì)alpha或beta API功能的訪問

Alpha 和 beta Kubernetes 功能正在積極開發(fā)中，可能存在導(dǎo)致安全漏洞的限制或錯(cuò)誤。

始終評(píng)估 Alpha 或 Beta 功能可能提供的價(jià)值，以應(yīng)對(duì)您的安全狀況可能面臨的風(fēng)險(xiǎn)。

驗(yàn)證

使用 OpenID (OIDC) 令牌作為用戶身份驗(yàn)證策略

Kubernetes 支持各種身份驗(yàn)證方法，包括 OpenID Connect (OIDC)。

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

您無需單獨(dú)記住或管理憑據(jù)。

您可以將多個(gè)集群連接到同一個(gè) OpenID 提供程序。

有關(guān) Kubernetes 中的 OpenID 連接的更多信息。 可以訪問：https://thenewstack.io/kubernetes-single-sign-one-less-identity/

基于角色的訪問控制 (RBAC)

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

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

日志記錄設(shè)置

日志的保留和歸檔策略

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

從節(jié)點(diǎn)、控制平面、審計(jì)收集日志

從哪些方面收集日志：

• 節(jié)點(diǎn)（kubelet、容器運(yùn)行時(shí)）
• 控制平面（API 服務(wù)器、調(diào)度程序、控制器管理器）
• Kubernetes 審計(jì)（對(duì) API 服務(wù)器的所有請求）

你應(yīng)該收集什么：

• 應(yīng)用名稱。從元數(shù)據(jù)標(biāo)簽中檢索。
• 應(yīng)用實(shí)例。從元數(shù)據(jù)標(biāo)簽中檢索。
• 應(yīng)用程序版本。從元數(shù)據(jù)標(biāo)簽中檢索。
• 集群 ID。從 Kubernetes 集群中檢索。
• 容器名稱。從 Kubernetes API 中檢索。
• 運(yùn)行此容器的集群節(jié)點(diǎn)。從 Kubernetes 集群中檢索。
• 運(yùn)行容器的 Pod 名稱。從 Kubernetes 集群中檢索。
• 命名空間。從 Kubernetes 集群中檢索。

首選每個(gè)節(jié)點(diǎn)上的守護(hù)進(jìn)程來收集日志而不是邊車

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

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

參考地址：https://rclayton.silvrback.com/container-services-logging-with-docker#effective-logging-infrastructure

配置日志聚合工具

使用日志聚合工具，例如 EFK stack（Elasticsearch、Fluentd、Kibana）、DataDog、Sumo Logic、Sysdig、GCP Stackdriver、Azure Monitor、AWS CloudWatch。