Kubernetes（K8s）已成為云計算領域高頻應用的搶手工具。作為一種開源的容器編排系統，Kubernetes可用于在云中擴展容器化應用程序。它可以管理容器生命周期，根據應用程序需求創建和銷毀容器，并提供了許多其他功能。Kubernetes的興起標志著應用程序開發和部署方式的轉變。

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

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

四大關鍵能力，深度保護Kubernetes集群

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

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

四重能力覆蓋全局

保障Kubernetes環境的安全性，創建體系化、精細化的安全策略，才能全面深度地洞見威脅、及時阻截。Akamai Guardicore Segmentation基于軟件的微分段解決方案，有助于企業準確監測Kubernetes集群，深入了解基礎架構所有層的實時狀況，確認流量的預期路徑。

用于Kubernetes集群分段的關鍵能力

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

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

三項原則構筑穩妥防線

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

Kubernetes環境中的安全性意味著要維護Kubernetes集群的穩定性和安全性。Kubernetes提供了基礎安全功能，以確保集群的安全。這種與安全相關的功能有很多，例如網絡安全、節點安全、身份驗證、授權、安全鏡像管理、機密管理、日志和監控、災難恢復……

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

1.借助網絡策略控制Pod的通信

Kubernetes的通信策略默認允許所有Pod相互通信。雖然這種策略對通信很有用，但也有可能使Pod暴露于不必要的連接中。因此如果想防止未經授權的訪問并保護Pod，就該使用網絡策略。

網絡策略是一種控制Pod間或Pod與其他網絡端點間通信的功能。通過網絡策略，我們可以根據IP地址、端口、協議和標簽等各種條件定義允許或拒絕流量的規則。此外，還可通過網絡策略設置只允許來自某些命名空間的流量。

網絡策略是使用Kubernetes網絡插件架構實現的。因此，不同網絡插件對網絡策略的支持程度可能各異。

Kubernetes網絡策略

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

設置網絡策略時，有三個元素非常重要：

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

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

最后，定義入口和出口流量的詳細策略，定義允許流量的命名空間、Pod、協議和端口號以及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

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

2. 基于角色的訪問控制（RBAC）權限

Kubernetes由許多資源組成，包括服務、網絡、命名空間、Pod、節點和容器。限制哪些用戶和服務可以訪問每種資源對保證集群安全至關重要。

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

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

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

下圖展示了基于角色的訪問控制的實現機制。

命名空間中的角色和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"]

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

接下來需要用一個RoleBinding將創建的角色分配給特定用戶。下面的示例聲明了一個名稱為dev-team-binding的RoleBinding，并設置用戶來分配特定角色。該示例為名為dev1的用戶分配了一個角色。最后，我們賦予dev1用戶dev-team角色。這將允許dev1用戶承擔上述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文件創建Role和RoleBinding。下面的示例代碼是kubectl命令的運行結果，該命令創建了“development”命名空間，并在該命名空間內創建了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基于角色的訪問控制允許集群管理員管理資源的訪問。這可以增強安全性，防止濫用造成的風險。我們還可以隔離不同用戶和服務賬戶之間的訪問權限，以保護敏感數據不被未經授權的用戶查看。

3. 安全地存儲敏感數據

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

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

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

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

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

然后創建一個YAML文件，用編碼后的數據創建一個機密。USER_NAME和PASSWORD的值是base64編碼值，但當Pod使用它們時，工作節點上的kubelet會對它們進行解碼，并提供給Pod和容器。

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

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

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

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

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

如您所在的企業也在考慮采購云服務或進行云遷移，

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