Kubernetes（K8s）已成為云計算領(lǐng)域高頻應(yīng)用的搶手工具。作為一種開源的容器編排系統(tǒng)，Kubernetes可用于在云中擴(kuò)展容器化應(yīng)用程序。它可以管理容器生命周期，根據(jù)應(yīng)用程序需求創(chuàng)建和銷毀容器，并提供了許多其他功能。Kubernetes的興起標(biāo)志著應(yīng)用程序開發(fā)和部署方式的轉(zhuǎn)變。

延伸閱讀，點擊鏈接了解 Akamai cloud-computing

廣為應(yīng)用的Kubernetes集群為業(yè)務(wù)帶來了前所未有的速度和靈活性，但大規(guī)模Kubernetes集群也成為了勒索軟件、加密挖礦和僵尸網(wǎng)絡(luò)等威脅的主要攻擊目標(biāo)。作為云時代一種重要“基礎(chǔ)設(shè)施”，Kubernetes本身的安全性開始引起了越來越多用戶關(guān)注。本文，我們將圍繞安全性，介紹可以增強(qiáng)Kubernetes集群安全性的四大必備能力和三個基本原則。

四大關(guān)鍵能力，深度保護(hù)Kubernetes集群

有調(diào)查發(fā)現(xiàn)，過去一年中，93%受訪者（包括300余名DevOps、工程設(shè)計和安全專業(yè)人員）的Kubernetes環(huán)境中至少出現(xiàn)過一次安全事件，攻擊者很有可能會利用此類事件安裝勒索軟件和其他惡意軟件。

因此，我們有必要強(qiáng)調(diào)對Kubernetes集群進(jìn)行分段的必要性，在于大量針對Kubernetes集群的攻擊開始采用規(guī)避和混淆技術(shù)以逃避檢測，包括打包攻擊載荷、使用Rootkit等方式運行惡意軟件。若想有效監(jiān)測、阻截勒索軟件攻擊中的橫向移動，就需要在保障業(yè)務(wù)連續(xù)性的情況下，以微分段策略限制威脅的擴(kuò)散與流動。

四重能力覆蓋全局

保障Kubernetes環(huán)境的安全性，創(chuàng)建體系化、精細(xì)化的安全策略，才能全面深度地洞見威脅、及時阻截。Akamai Guardicore Segmentation基于軟件的微分段解決方案，有助于企業(yè)準(zhǔn)確監(jiān)測Kubernetes集群，深入了解基礎(chǔ)架構(gòu)所有層的實時狀況，確認(rèn)流量的預(yù)期路徑。

用于Kubernetes集群分段的關(guān)鍵能力

• 映射監(jiān)測：Akamai Guardicore Segmentation配置有映射、多層標(biāo)簽功能。依賴項關(guān)系的映射圖譜，可用于監(jiān)測數(shù)據(jù)中心內(nèi)部和多個數(shù)據(jù)中心之間的通信狀況；通過使用多層標(biāo)簽，映射更得以準(zhǔn)確地反映應(yīng)用程序在集群中的部署方式，全方位提升客戶對Kubernetes層次結(jié)構(gòu)的可見性。
• 強(qiáng)制實施：Akamai Guardicore Segmentation具有非侵入性與靈活性，可使用原生Kubernetes CNI（Container Network Interface, 容器網(wǎng)絡(luò)接口）強(qiáng)制實施網(wǎng)絡(luò)分段；同時配置保護(hù)Kubernetes業(yè)務(wù)關(guān)鍵型應(yīng)用程序而設(shè)計的專用模板，幫助用戶輕松選擇域名空間、應(yīng)用程序等準(zhǔn)備隔離的對象。
• 高級監(jiān)控：利用高級日志記錄和監(jiān)控系統(tǒng)，可針對Kubernetes網(wǎng)絡(luò)調(diào)整專用網(wǎng)絡(luò)日志，顯示每個事件的目標(biāo)服務(wù)、節(jié)點IP、源端口和目標(biāo)端口以及進(jìn)程，有利于用戶更便捷地調(diào)查網(wǎng)絡(luò)中的異?；顒硬?shù)據(jù)導(dǎo)出到第三方應(yīng)用程序。
• 集群操作：在具體的運營活動中，及時進(jìn)行集群操作，也是踐行微分段策略的關(guān)鍵能力。專用集群操作屏幕提供了有關(guān)已部署集群的所有必要數(shù)據(jù)，包括監(jiān)控集群的代理數(shù)、標(biāo)記代理功能的警告和告警，以及Kubernetes編排的狀態(tài)等。

當(dāng)下，雖然零信任安全理念已經(jīng)深入人心，但真正實踐、落地“假設(shè)入侵”的工具還屈指可數(shù)。Akamai Guardicore Segmentation則正是填補(bǔ)這一技術(shù)空白的微分段解決方案，以高度適應(yīng)Kubernetes集群的拓展能力、非侵入性特點，精細(xì)化監(jiān)測Kubernetes集群等基礎(chǔ)架構(gòu)的安全狀況，并及時將攻擊行為扼殺于風(fēng)險擴(kuò)散早期。

三項原則構(gòu)筑穩(wěn)妥防線

Kubernetes通過以集成方式管理眾多容器的能力，在部署、運行和管理容器服務(wù)方面提供了許多優(yōu)勢，已經(jīng)成為很多云平臺不可或缺的重要組件和關(guān)鍵服務(wù)。然而這一特性也可能使應(yīng)用程序面臨安全漏洞。事實上，針對容器的安全攻擊呈上升趨勢，而且影響越來越嚴(yán)重。因此Kubernetes環(huán)境的安全性與任何其他開發(fā)或生產(chǎn)環(huán)境中的安全性一樣重要。

Kubernetes環(huán)境中的安全性意味著要維護(hù)Kubernetes集群的穩(wěn)定性和安全性。Kubernetes提供了基礎(chǔ)安全功能，以確保集群的安全。這種與安全相關(guān)的功能有很多，例如網(wǎng)絡(luò)安全、節(jié)點安全、身份驗證、授權(quán)、安全鏡像管理、機(jī)密管理、日志和監(jiān)控、災(zāi)難恢復(fù)……

本文將介紹其中最具代表性的三項：控制Kubernetes集群訪問的網(wǎng)絡(luò)策略、基于角色的訪問控制（RBAC）和安全存儲敏感信息的機(jī)密信息。

1.借助網(wǎng)絡(luò)策略控制Pod的通信

Kubernetes的通信策略默認(rèn)允許所有Pod相互通信。雖然這種策略對通信很有用，但也有可能使Pod暴露于不必要的連接中。因此如果想防止未經(jīng)授權(quán)的訪問并保護(hù)Pod，就該使用網(wǎng)絡(luò)策略。

網(wǎng)絡(luò)策略是一種控制Pod間或Pod與其他網(wǎng)絡(luò)端點間通信的功能。通過網(wǎng)絡(luò)策略，我們可以根據(jù)IP地址、端口、協(xié)議和標(biāo)簽等各種條件定義允許或拒絕流量的規(guī)則。此外，還可通過網(wǎng)絡(luò)策略設(shè)置只允許來自某些命名空間的流量。

網(wǎng)絡(luò)策略是使用Kubernetes網(wǎng)絡(luò)插件架構(gòu)實現(xiàn)的。因此，不同網(wǎng)絡(luò)插件對網(wǎng)絡(luò)策略的支持程度可能各異。

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

一些流行的網(wǎng)絡(luò)插件（如Calico、Cilium和Weave Net）原生支持網(wǎng)絡(luò)策略，而其他插件可能需要額外配置或定制開發(fā)。

設(shè)置網(wǎng)絡(luò)策略時，有三個元素非常重要：

• podSelector：指定策略適用的Pod。
• policyTypes：指定將應(yīng)用策略的流量，分為入口流量和出口流量。
• ingress/egress：指定入口/出口流量的詳細(xì)信息。

舉個例子。下面的示例是一個設(shè)置網(wǎng)絡(luò)策略的YAML文件。查看示例中的podSelector，可以看到“database”被指定為應(yīng)用策略的Pod。通過policyTypes設(shè)置，網(wǎng)絡(luò)策略將同時應(yīng)用于傳入和傳出的流量。

最后，定義入口和出口流量的詳細(xì)策略，定義允許流量的命名空間、Pod、協(xié)議和端口號以及IP段。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: my-nwpolicy
 namespace: default
spec:
 podSelector: 
 matchLabels:
 role: database
 policyTypes: 
 - Ingress
 - Egress
 ingress: 
 - from:
 - ipBlock: 
 cidr: 10.17.0.0/16
 - namespaceSelector: 
 matchLabels:
 name: my-ns
 - podSelector: 
 matchLabels:
 app: my-pod
 ports: 
 - protocol: TCP
 port: 6379
 egress: 
 - to:
 - ipBlock:
 cidr: 10.0.0.0/24
 ports:
 - protocol: TCP
 port: 5978

通過上述示例可以看出，它對入站和出站流量的控制就像網(wǎng)絡(luò)服務(wù)器上的防火墻或云實例上的安全組一樣。這樣，通過網(wǎng)絡(luò)策略，Kubernetes可以確定并控制安裝在Pod中的應(yīng)用程序可以接收哪些網(wǎng)絡(luò)請求，以及這些請求來自哪里。通過限制集群中Pod的網(wǎng)絡(luò)流量，即可保護(hù)集群免受各種安全攻擊。

2. 基于角色的訪問控制（RBAC）權(quán)限

Kubernetes由許多資源組成，包括服務(wù)、網(wǎng)絡(luò)、命名空間、Pod、節(jié)點和容器。限制哪些用戶和服務(wù)可以訪問每種資源對保證集群安全至關(guān)重要。

Kubernetes中基于角色的訪問控制（RBAC）通過為用戶和服務(wù)賬戶定義角色，并根據(jù)角色授予權(quán)限來控制對集群資源的訪問。我們可以使用Roles（為用戶或服務(wù)賬戶設(shè)置角色）和ClusterRole（在集群級別設(shè)置角色）定義安全規(guī)則，并將這些規(guī)則添加到組（用戶集合）中。

基于角色的訪問控制包括三個主要概念：

• Role：是一組授予集群資源訪問權(quán)限的特權(quán)。例如，可以定義一個名為“pod-reader”的角色，并授予同一命名空間內(nèi)所有Pod的讀取權(quán)限。
• RoleBinding：將角色分配給特定用戶或服務(wù)賬戶。換句話說，是一個將角色和賬戶進(jìn)行綁定的函數(shù)。例如，將“pod-reader”角色附加給用戶“user-1”，這樣用戶“user-1”就可以讀取同一命名空間中的所有Pod。
• ClusterRole：與Role類似，但權(quán)限范圍不同。Role分配的權(quán)限僅在特定命名空間內(nèi)有效，而ClusterRole分配的權(quán)限在整個集群范圍內(nèi)有效。需要通過ClusterRoleBinding來定義ClusterRole與用戶或服務(wù)賬戶之間的關(guān)聯(lián)。

下圖展示了基于角色的訪問控制的實現(xiàn)機(jī)制。

命名空間中的角色和K8s集群中的ClusterRole

我們還可以通過一個例子來了解基于角色的訪問控制。下面的示例是一個YAML文件，其中定義了一個名為dev-team的角色。

<role.yaml>
apiVersion: rbac.authorization.k8s.io/v1 
kind: Role
metadata:
 namespace: development 
 name: dev-team 
rules: 
- apiGroups: ["core", "extensions", "apps"] 
 resources: ["deployments", "replicasets", "pods"] 
 verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

該角色指定了特定用戶或服務(wù)賬戶可以在“開發(fā)”命名空間內(nèi)執(zhí)行的任務(wù)和目標(biāo)。仔細(xì)觀察會發(fā)現(xiàn)，它將可訪問的API組定義為Core、Extensions和Apps，它還提供了對Deployments、ReplicaSets和Pods資源的訪問權(quán)限。最后，它為資源授予了權(quán)限，如get、list和watch。通過這些設(shè)置，名為dev-team的角色就可以訪問屬于apps API組的部署資源，并執(zhí)行get操作來檢查資源的信息和狀態(tài)。

接下來需要用一個RoleBinding將創(chuàng)建的角色分配給特定用戶。下面的示例聲明了一個名稱為dev-team-binding的RoleBinding，并設(shè)置用戶來分配特定角色。該示例為名為dev1的用戶分配了一個角色。最后，我們賦予dev1用戶dev-team角色。這將允許dev1用戶承擔(dān)上述role.yaml示例文件中定義的角色。

<user-role.yaml>
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 namespace: development
 name: dev-team-binding 
subjects:
- kind: User 
 name: dev1
 apiGroup: ""
roleRef:
 kind: Role 
 name: dev-team
 apiGroup: ""

此外，我們還將舉例說明如何使用YAML文件創(chuàng)建Role和RoleBinding。下面的示例代碼是kubectl命令的運行結(jié)果，該命令創(chuàng)建了“development”命名空間，并在該命名空間內(nèi)創(chuàng)建了Role和RoleBinding。

$kubectl create namespace development
namespace/development created
$kubectl create -f role.yaml 
role.rbac.authorization.k8s.io/dev-team created
$kubectl create -f user-role.yaml 
rolebinding.rbac.authorization.k8s.io/dev-team-binding created

Kubernetes基于角色的訪問控制允許集群管理員管理資源的訪問。這可以增強(qiáng)安全性，防止濫用造成的風(fēng)險。我們還可以隔離不同用戶和服務(wù)賬戶之間的訪問權(quán)限，以保護(hù)敏感數(shù)據(jù)不被未經(jīng)授權(quán)的用戶查看。

3. 安全地存儲敏感數(shù)據(jù)

Kubernetes Secret是一種用于安全存儲敏感數(shù)據(jù)（如加密信息、令牌和密碼）的資源。在Kubernetes中，機(jī)密通常用于管理API密鑰、數(shù)據(jù)庫密碼、OAuth標(biāo)記等身份驗證信息。如果這些敏感信息以純文本形式包含在Pod的規(guī)范文件或容器鏡像中，可能會對安全造成威脅。因此，機(jī)密信息不會包含在容器鏡像中，而是在運行應(yīng)用程序時通過環(huán)境變量或卷掛載傳遞給容器。

機(jī)密存儲在ETCD中，通過卷和變量的方式使用

機(jī)密通常定義為base64編碼的鍵值對。機(jī)密會在容器運行時解密和使用，因此無需在使用機(jī)密的應(yīng)用程序中實施單獨的解密邏輯。機(jī)密的創(chuàng)建與使用敏感信息的Pod無關(guān)，相反，我們需要將敏感信息安全地存儲在單獨的etcd存儲庫中，并在Pod需要時將其提供給容器。

讓我們創(chuàng)建一個簡單的機(jī)密示例。創(chuàng)建并保存特定用戶的ID和密碼作為機(jī)密。假設(shè)有用戶數(shù)據(jù)"USER_NAME=admin"、"PASSWORD=1f2d1e2e67df"。首先，對信息進(jìn)行base64編碼，如下所示：

$echo -n "admin" | base64
YWRtaW4=
$echo -n "1f2d1e2e67df" | base64
MWYyZDFlMmU2N2Rm

然后創(chuàng)建一個YAML文件，用編碼后的數(shù)據(jù)創(chuàng)建一個機(jī)密。USER_NAME和PASSWORD的值是base64編碼值，但當(dāng)Pod使用它們時，工作節(jié)點上的kubelet會對它們進(jìn)行解碼，并提供給Pod和容器。

apiVersion: v1
kind: Secret
metadata:
 name: my-secret
type: Opaque
data: 
 USER_NAME: YWRtaW4=
 PASSWORD: MWYyZDFlMmU2N2Rm

以這種方式創(chuàng)建的機(jī)密信息存儲在Kubernetes集群控制平面的etcd數(shù)據(jù)庫中。etcd是Kubernetes集群的中央數(shù)據(jù)存儲庫，其中存儲了多種數(shù)據(jù)，包括所有Kubernetes資源信息、配置信息和運行時信息。機(jī)密也以base64編碼方式存儲在ETCD中。

請注意，Secret使用的是編碼和解碼技術(shù)，而不是加密技術(shù)。因此這并不是一種完美的數(shù)據(jù)保護(hù)方法。一些情況下可能還需要額外的安全措施。例如可以使用RBAC來限制僅授權(quán)用戶才能訪問和使用機(jī)密。還可以使用單獨的加密插件對機(jī)密數(shù)據(jù)進(jìn)行完全加密。但這需要外部服務(wù)，如密鑰管理服務(wù)（KMS）。

總之，Kubernetes Secret是保護(hù)和管理應(yīng)用程序使用的敏感信息的重要工具，我們可以借此保護(hù)Kubernetes集群中的敏感信息，從而規(guī)避很多安全隱患。

至此，我們已經(jīng)介紹了確保Kubernetes安全的四個必備能力和三大原則。事實上，Kubernetes的安全性是一個龐大的話題，限于篇幅，本文只是簡單接受了一些淺顯的內(nèi)容。但充分利用這些內(nèi)容，也能確保Kubernetes的基本安全。

如您所在的企業(yè)也在考慮采購云服務(wù)或進(jìn)行云遷移，

點擊鏈接了解Akamai Linode的解決方案