前言

隨著更多的組織開始擁抱云原生技術(shù)，Kubernetes已成為容器編排領(lǐng)域的行業(yè)標(biāo)準(zhǔn)。向 Kubernetes轉(zhuǎn)變的這股潮流，很大程度上簡(jiǎn)化了容器化應(yīng)用程序的部署、擴(kuò)展和管理，并實(shí)現(xiàn)了自動(dòng)化，為傳統(tǒng)的單體式系統(tǒng)提供了勝于傳統(tǒng)管理協(xié)議的眾多優(yōu)勢(shì)。

然而，管理大規(guī)模的Kubernetes帶來(lái)了一系列獨(dú)特挑戰(zhàn)，包括加固集群、保護(hù)供應(yīng)鏈以及運(yùn)行時(shí)檢測(cè)威脅。本文結(jié)合云原生計(jì)算基金會(huì)（CNCF）、美國(guó)國(guó)家安全局（NSA）以及網(wǎng)絡(luò)安全和基礎(chǔ)設(shè)施安全局（CISA）的諸多最佳實(shí)踐，整理出Kubernetes安全加固的6個(gè)建議，幫助組織降低風(fēng)險(xiǎn)。

集群設(shè)置和加固

保護(hù)Kubernetes環(huán)境從加固集群開始。對(duì)于使用托管Kubernetes服務(wù)（比如GKE、EKS或AKS）的用戶而言，由相應(yīng)的云提供商管理主節(jié)點(diǎn)安全，并為集群實(shí)施各種默認(rèn)安全設(shè)置。GKE Autopilot采取了額外措施，實(shí)施GKE加固準(zhǔn)則和GCP安全最佳實(shí)踐。但即使對(duì)于GKE Standard或EKS/AKS用戶而言，云提供商也有一套準(zhǔn)則，以保護(hù)用戶對(duì)Kubernetes API服務(wù)器的訪問(wèn)、對(duì)云資源的容器訪問(wèn)以及Kubernetes升級(jí)。

準(zhǔn)則如下：

• GKE加固指南

• EKS安全最佳實(shí)踐指南

• AKS集群安全

至于自我管理的Kubernetes集群（比如kube-adm或kops），kube-bench可用于測(cè)試集群是否符合CIS Kubernetes Benchmark中規(guī)定的安全準(zhǔn)則。主要的建議包括：加密存儲(chǔ)在靜態(tài)etcd中的機(jī)密信息、使用TLS證書保護(hù)控制平面通信以及開啟審計(jì)日志功能。

網(wǎng)絡(luò)和資源策略

默認(rèn)情況下，Kubernetes允許從任何pod到同一集群中另一個(gè)pod的通信。雖然這對(duì)于發(fā)現(xiàn)服務(wù)而言很理想，但沒(méi)有提供網(wǎng)絡(luò)分離，不法分子或中招的系統(tǒng)可以無(wú)限制地訪問(wèn)所有資源。如果團(tuán)隊(duì)使用命名空間作為Kubernetes內(nèi)部多租戶的主要手段，這就成為非常嚴(yán)重的問(wèn)題。

為了控制pod、命名空間和外部端點(diǎn)之間的流量，應(yīng)使用支持NetworkPolicy API的CNI插件（比如Calico、Flannel或針對(duì)特定云的CNI），用于網(wǎng)絡(luò)隔離。遵照零信任模型，最佳實(shí)踐是實(shí)施默認(rèn)一概拒絕的策略，阻止所有出入流量，除非另一項(xiàng)策略特別允許。

除了網(wǎng)絡(luò)策略外，Kubernetes還提供兩個(gè)資源級(jí)別的策略：LimitRange和ResourceQuotas。LimitRanges可用于限制單個(gè)資源的使用（如每個(gè)pod最多有2個(gè)CPU），而ResourceQuota控制聚合資源的使用（如在dev命名空間中總共有20個(gè)CPU）。

RBAC和服務(wù)賬戶

強(qiáng)大的網(wǎng)絡(luò)和資源策略到位后，下一步是強(qiáng)制執(zhí)行RBAC授權(quán)以限制訪問(wèn)。Kubernetes管理員可以對(duì)用戶和用戶組強(qiáng)制執(zhí)行RBAC以訪問(wèn)集群，以及限制服務(wù)訪問(wèn)集群內(nèi)外的資源（如云托管的數(shù)據(jù)庫(kù)）。另外，企業(yè)使用創(chuàng)建時(shí)掛載到每個(gè)pod的默認(rèn)服務(wù)賬戶時(shí)須謹(jǐn)慎。pod可能被授予過(guò)大的權(quán)限，這取決于授予默認(rèn)服務(wù)賬戶的權(quán)限。如果不需要與Kubernetes服務(wù)進(jìn)行任何特定的通信，將automountServiceAccountToken設(shè)置為false，以防止掛載。

系統(tǒng)加固

鑒于集群已安全，下一步是盡量縮小系統(tǒng)的攻擊面。這適用于節(jié)點(diǎn)上運(yùn)行的操作系統(tǒng)以及容器上的內(nèi)核。選擇為運(yùn)行容器而優(yōu)化的專用操作系統(tǒng)，如AWS Bottlerocket或GKE COS，而不是選擇通用的Linux節(jié)點(diǎn)。接下來(lái)，充分利用Linux內(nèi)核安全功能，如SELinux、AppArmor（自1.4起是測(cè)試版）及/或seccomp（自1.19起是穩(wěn)定版）。AppArmor為L(zhǎng)inux用戶或用戶組定義了將程序限制于一組有限資源的權(quán)限。一旦定義了AppArmor配置文件，帶有AppArmor標(biāo)注的pod將強(qiáng)制執(zhí)行這些規(guī)則。

apiVersion:???v1
kind:???Pod
metadata:
????????name:?apparmor
????????annotations:
?????????????????container.apparmor.security.beta.kubernetes.io/hello:???localhost/k8s-apparmor-example-deny-write
spec:
????????containers:
????????-?name:?hello
????????????image:?busybox
????????????command:?[?"sh",?"-c",?"echo?'Hello???AppArmor!'?&&?sleep?1h"?]

另一方面，Seccomp限制容器的系統(tǒng)調(diào)用。只要底層Kubernetes節(jié)點(diǎn)上有seccomp配置文件可用，就可以在securityContext這部分定義seccomp配置文件。

apiVersion:?v1
kind:?Pod
metadata:
??name:?audit-pod
??labels:
????????app:?audit-pod
spec:
??securityContext:
????????seccompProfile:
?????????????????type:?Localhost
?????????????????localhostProfile:?profiles/audit.json
??containers:
??-?name:?test-container
???????image:?hashicorp/http-echo:0.2.3
???????args:
????????-?"-text=just?made?some?syscalls!"

即使沒(méi)有seccomp配置文件，用戶仍然可以限制容器免受各種權(quán)限提升攻擊。在安全上下文中，Kubernetes允許配置容器是否可以以特權(quán)或root身份來(lái)運(yùn)行，或者將權(quán)限升級(jí)到root。用戶還可以限制hostPID、hostIPC、hostNetwork和hostPaths。所有這些設(shè)置都可以通過(guò)Pod Security Policy（v1.21中已被棄用）或使用其他開源工具（比如K-Rail、Kyverno和OPA/Gatekeeper）來(lái)執(zhí)行。

最后，如果需要額外的安全保證，可以配置自定義的RuntimeClass，以便充分利用硬件虛擬化（如gVisor或Kata）。在節(jié)點(diǎn)層面定義RuntimeClass，并在pod定義部分指定它。

apiVersion:???node.k8s.io/v1?#?RuntimeClass?is?defined?in?the?node.k8s.io?API?group
kind:???RuntimeClass
metadata:
??name:?myclass?#?The?name?the?RuntimeClass???will?be?referenced?by
??#?RuntimeClass?is?a?non-namespaced?resource
handler:???myconfiguration?#?The?name?of?the?corresponding?CRI?configuration
---
apiVersion:???v1
kind:???Pod
metadata:
??name:?mypod
spec:
??runtimeClassName:?myclass

供應(yīng)鏈安全

即使集群和系統(tǒng)安全，為保證整個(gè)應(yīng)用程序的端到端安全，也必須考慮到供應(yīng)鏈。若是內(nèi)部開發(fā)的應(yīng)用程序，請(qǐng)遵循創(chuàng)建容器的最佳實(shí)踐，即使用最小基礎(chǔ)鏡像以減小攻擊面、固定軟件包版本，并使用多階段構(gòu)建以創(chuàng)建小鏡像。此外，定義容器運(yùn)行所需的非root用戶，或使用podman構(gòu)建無(wú)root容器，以限制root訪問(wèn)。

下一步，使用開源工具（如Trivy、Clair或Anchore）或者商用工具掃描所有鏡像，以查找漏洞。一些工具還允許對(duì)鏡像進(jìn)行簽名和驗(yàn)證簽名，以確保容器在構(gòu)建和上傳過(guò)程中未被篡改。最后，定義Kubernetes可以使用ImagePolicyWebhook或上面提到的任何策略執(zhí)行工具從中提取鏡像的白名單注冊(cè)表。

監(jiān)控、日志和運(yùn)行時(shí)安全

至此，我們有了一個(gè)供應(yīng)鏈嚴(yán)加保護(hù)的安全集群，可以生成干凈的、經(jīng)過(guò)驗(yàn)證的鏡像，有限的訪問(wèn)權(quán)限。然而環(huán)境是動(dòng)態(tài)的，安全團(tuán)隊(duì)需能夠響應(yīng)運(yùn)行環(huán)境中的事件。首先，將readOnlyRootFilesystem設(shè)置為true，并將tmp日志文件存儲(chǔ)到emptyDir，以此確保容器在運(yùn)行時(shí)不變。除了典型的應(yīng)用程序監(jiān)控（如Prometheus/Grafana）或日志（如EFK）存儲(chǔ)外，還可以使用Falco或Sysdig來(lái)分析系統(tǒng)調(diào)用進(jìn)程和Kubernetes API日志。

這兩種工具都可以在運(yùn)行時(shí)解析來(lái)自內(nèi)核的Linux系統(tǒng)調(diào)用，并在違反規(guī)則時(shí)觸發(fā)警報(bào)。示例規(guī)則包括：權(quán)限提升時(shí)發(fā)出警報(bào)，已知目錄上檢測(cè)到讀/寫事件時(shí)發(fā)出警報(bào)，或調(diào)用shell時(shí)發(fā)出警報(bào)。最后，將Kubernetes API審計(jì)日志與現(xiàn)有日志聚合和警報(bào)工具整合起來(lái)，以監(jiān)控集群中的所有活動(dòng)。這包括API請(qǐng)求歷史記錄、性能指標(biāo)、部署、資源消耗、操作系統(tǒng)調(diào)用和網(wǎng)絡(luò)流量。

總結(jié)

由于云原生系統(tǒng)很復(fù)雜，需要采用多層方法來(lái)保護(hù)Kubernetes環(huán)境。建議Kubernetes做好云原生安全的4C：云、集群、容器和代碼。首先，加固集群，并遵循云安全最佳實(shí)踐；其次，嚴(yán)加保護(hù)容器，減小攻擊面，限制訪問(wèn)，并確保運(yùn)行時(shí)不變；再次，保護(hù)供應(yīng)鏈，分析代碼和容器以查找漏洞。最后，監(jiān)控運(yùn)行時(shí)的所有活動(dòng)，將防御機(jī)制融入Kubernetes內(nèi)運(yùn)行的每一層軟件中。

最新評(píng)論