Kubernetes容器雲原生安全策略

– 11 分鐘閱讀

Kubernetes 的普及也帶來了新的安全挑戰，尤其在微服務架構下，傳統的安全邊界變得模糊。本文旨在探討如何應對這些挑戰，並建立一個全面的安全與可觀測性策略。從容器映像檔的建構與掃描、CI/CD 流程中的安全檢查、機密資訊的妥善管理，到根據角色的許可權控制（RBAC）以及網路政策的實施，都是確保 Kubernetes 叢集安全的重要環節。此外，執行階段的 Pod 安全策略、系統呼叫監控，以及完善的日誌收集和分散式追蹤機制，則能提供更深入的可觀測性，協助及早發現並應對潛在威脅。

Kubernetes安全與可觀測性：容器與雲原生應用的全方位防護策略

隨著雲原生技術的快速發展，Kubernetes已成為容器編配的標準。然而，隨著其日益普及，安全性和可觀測性成為了企業面臨的一大挑戰。本篇文章將探討Kubernetes安全與可觀測性的關鍵概念，並提供全方位的防護策略。

Kubernetes安全性的新挑戰

在傳統的單體架構中，安全性的邊界相對清晰。然而，在Kubernetes的世界裡，應用程式被拆分成多個微服務，並執行在多個容器中。這種分散式的架構使得安全性變得更加複雜。

佈署工作負載的安全性

在Kubernetes中佈署工作負載時，需要考慮多個階段的安全性：

  1. 建置階段的安全性：採用「左移」策略，將安全性檢查盡早納入CI/CD流程中。
  2. 佈署階段的安全性：使用Kubernetes的內建功能，如RBAC和Network Policy，來控制資源的存取。
  3. 執行階段的安全性：監控容器的執行狀態，並使用Runtime Security工具來檢測異常行為。

可觀測性：確保系統的透明度

可觀測性是確保系統穩定性和安全性的關鍵。在Kubernetes中，可觀測性涵蓋了以下幾個方面：

  1. 日誌收集和分析：收集容器的日誌，並使用工具進行分析，以檢測潛在的安全威脅。
  2. 指標監控：監控容器的效能指標，如CPU和記憶體使用率，以確保系統的穩定性。
  3. 追蹤和除錯：使用分散式追蹤工具來追蹤請求的流程，並進行除錯。

安全框架和最佳實踐

為了確保Kubernetes叢集的安全性，需要採用一系列的安全框架和最佳實踐：

  1. 主機強化：強化主機的安全性，如關閉不必要的服務和組態防火牆。
  2. 叢集強化：強化叢集的安全性，如組態RBAC和加密Kubernetes Secrets。
  3. 持續監控和合規檢查：持續監控叢集的狀態，並進行合規檢查，以確保符合相關的法規要求。

Kubernetes 安全與可觀測性策略

Kubernetes 並非預設安全。企業與雲端安全面臨著 Kubernetes 動態特性的挑戰，組織敏捷性的提升往往伴隨著新的安全風險。要在這個新環境中成功確保關鍵微服務的安全、觀察和故障排除，需要對廣泛的考量因素有全面的瞭解。

為何需要整體安全與可觀測性策略

現有的 Kubernetes 資源雖然豐富，但在制定全面的安全和可觀測性策略時仍可能讓人感到無從下手，導致安全態勢出現重大漏洞。我們撰寫本文的目的就是引導讀者建立整體的安全和可觀測性策略，並提供最佳實踐和工具，幫助您將應用程式遷移到 Kubernetes。

Kubernetes 安全挑戰與最佳實踐

在 Tigera 開發 Calico（一款 Kubernetes 網路和安全工具）多年來，我們近距離觀察了使用者的旅程。許多使用者在未仔細考慮安全或可觀測性策略的情況下就將工作負載佈署到 Kubernetes，然後在試圖瞭解如何保護和觀察如此複雜的分散式系統時遇到困難。

容器安全

  1. 映像檔建置與掃描

    • 選擇適當的基礎映像檔
    • 強化容器映像檔
    • 使用容器映像檔掃描方案

  2. CI/CD 安全

    • 在登入檔中掃描映像檔
    • 建置後掃描映像檔
    • 行內映像檔掃描
    • Kubernetes 准入控制器

  3. 機密管理

    • 使用 etcd 儲存機密資訊
    • 機密管理服務
    • Kubernetes Secrets Store CSI Driver

身份驗證與授權

  1. 身份驗證

    • X509 使用者端憑證
    • Bearer Token
    • OIDC Tokens
    • 身份驗證 Proxy

  2. 授權

    • Node
    • ABAC
    • AlwaysDeny/AlwaysAllow
    • RBAC（角色存取控制）

工作負載執行階段安全

  1. Pod 安全政策（PSP）

    • 使用 PSP
    • PSP 功能
    • Pod 安全上下文

  2. 系統呼叫監控

    • Kubernetes 原生監控
    • Seccomp
    • SELinux
    • AppArmor
    • Sysctl

可觀測性

  1. 監控與可觀測性

    • 如何在 Kubernetes 中實作可觀測性
    • Linux 核心工具
    • 可觀測性元件

  2. 日誌聚合與相關性分析

    • 視覺化
    • 服務圖譜

  3. 分散式追蹤

    • 網路流量視覺化

網路政策與信任管理

  1. 網路政策

    • 網路政策最佳實踐
    • Ingress 和 Egress 控制

  2. 跨團隊信任管理

    • 角色存取控制（RBAC）
    • 網路政策限制
    • 准入控制器

Kubernetes 採用的三個階段

任何成功的 Kubernetes 採用之旅都遵循三個不同的階段：學習階段、試點/預生產階段和生產階段。

學習階段

作為新使用者，您首先需要學習 Kubernetes 的運作方式、建立沙盒環境，並開始思考如何在您的環境中使用 Kubernetes。在此階段，您希望利用可用的線上 Kubernetes 資源並使用開源技術。

試點/預生產階段

一旦您熟悉了 Kubernetes 並瞭解其運作方式，您就會開始思考採用 Kubernetes 的高層策略。在此階段，您通常會進行試點專案以建立叢集並上線幾個應用程式。隨著在此階段的進展，您將對使用哪些平台以及它們是在本地還是雲端有初步的想法。如果您選擇雲端，您將決定是自行託管叢集還是利用雲端供應商提供的受管 Kubernetes 服務。您還需要思考保護應用程式的策略。到目前為止，您已經意識到 Kubernetes 由於其宣告式性質而有所不同。這意味著該平台抽象了許多有關網路、基礎設施、主機等的細節，因此使您能夠非常輕鬆地為應用程式使用該平台。正因為如此，您目前用於保護應用程式、基礎設施和網路的方法根本行不通，因此您現在需要考慮原生於 Kubernetes 的安全性。

生產階段

到目前為止，您已經完成了試點專案並成功地上線了幾個應用程式。您的重點是執行生產中的關鍵任務應用程式，並考慮是否將大多數應用程式遷移到 Kubernetes。在此階段，您需要制定詳細的安全性、合規性、故障排除和可觀察性計劃，以便安全有效地將應用程式遷移到生產環境中，並實作 Kubernetes 平台的所有優勢。

Kubernetes 作為根據容器的應用程式平台，其流行和成功讓許多人急於採用它。在過去幾年中，受管 Kubernetes 服務供應商一直在努力創新，以使採用變得更加容易。新使用者可能會想跳過學習和試點階段，以便快速進入生產階段。我們警告不要跳過盡職調查。在將關鍵任務應用程式上線到 Kubernetes 之前，您必須將安全性和可觀察性視為關鍵的第一步；如果沒有它們，您的 Kubernetes 採用就不完整，而且可能不安全。

本文適用物件

本文適用於處於試點/預生產階段的廣大 Kubernetes 從業者。您可能是平台工程師或安全團隊或 DevOps 團隊的一員。其中一些人是組織中第一個採用 Kubernetes 的人，希望從一開始就正確地進行安全性和可觀察性。其他人則正在幫助建立已經採用 Kubernetes 但尚未解決其帶來的安全性和可觀察性挑戰的組織的最佳實踐。我們假設您對 Kubernetes 有基本的瞭解——它是什麼以及如何將其用作託管應用程式的協調工具。我們還假設您瞭解應用程式如何在 Kubernetes 叢集中佈署及其分散式特性。

在這個廣泛的讀者群中，有許多不同的角色。以下是幫助設計和實施根據 Kubernetes 架構的團隊的非詳盡清單，這些團隊將在本文中找到價值。請注意，您的組織中的角色名稱可能不同，因此請檢視每個角色的職責，以確定您組織中對應的角色。在本文中，我們將使用這些名稱來幫助您瞭解某個概念如何影響每個角色。

平台團隊

平台工程團隊負責設計和實施 Kubernetes 平台。許多企業選擇實施容器即服務（CaaS）策略。這是一個跨企業用於實施根據容器的工作負載的平台。平台工程團隊負責平台元件，並將其作為服務提供給應用程式團隊。本文將幫助您瞭解保護平台的重要性以及保護平台層的最佳實踐——這樣您就可以為應用程式團隊提供一種在安全的 Kubernetes 平台上上線應用程式的方法。它還將幫助您瞭解如何管理新應用程式對平台的安全風險。

網路團隊

網路團隊負責將 Kubernetes 叢集整合到企業網路中。我們看到這些團隊在本地佈署 Kubernetes 和在雲端環境中自託管或利用受管 Kubernetes 服務的 Kubernetes 叢集中扮演不同的角色。您將瞭解網路安全性的重要性以及如何建立具有強大安全態勢的網路。本文涵蓋的主題包括：在 Kubernetes 平台外部公開應用程式的最佳實踐，以及應用程式存取外部網路的最佳實踐。您還將學習如何與其他團隊合作實施網路安全性，以保護 Kubernetes 外部的元素免受 Kubernetes 內部工作負載的影響。

前言

在企業中，安全團隊是受到雲原生應用程式發展影響最大的團隊。雲原生應用程式是專為雲端環境設計的，與傳統應用程式有著本質上的不同。這些應用程式分佈在網路基礎設施的各個角落。本文將幫助您瞭解如何保護用於託管應用程式的 Kubernetes 平台，並提供完整的視角來保護關鍵工作負載。您將學習如何與各個團隊協作，以在 Kubernetes 的新世界中有效地實施安全措施。

合規團隊

企業中的合規團隊負責確保組織的營運和流程符合所採用的合規標準要求。您將瞭解如何在根據 Kubernetes 的平台上實施各種合規要求，以及如何監控持續的合規情況。雖然本文不會詳細介紹合規要求和各種標準，但將提供策略、範例和工具，幫助您滿足合規要求。

維運團隊

維運團隊是由開發人員、工具工程師和維運工程師組成的團隊，負責構建和維護應用程式。他們也被稱為 DevOps 或站點可靠性工程師（SREs）。他們確保應用程式能夠上線並滿足所需的服務水平協定（SLAs）。在本文中，您將瞭解在保護 Kubernetes 叢集和與安全團隊協作中的角色。我們將介紹「左移安全」的概念，即在應用程式開發生命週期的早期就實施安全措施。在 Kubernetes 平台上的可觀察性意味著能夠透過檢視平台的資料來推斷叢集執行的詳細資訊。這是監控分散式應用的現代方法，您將學習如何實施可觀察性及其對安全的重要性。

本文內容

在本文中，您將學習如何在實施 Kubernetes 策略時考慮安全性，從構建應用程式到構建基礎設施、託管應用程式、佈署應用程式到執行應用程式。我們將為每個階段提供安全最佳實踐，並提供範例和工具來幫助您保護 Kubernetes 平台。我們將介紹如何實施稽核、合規和其他企業安全控制措施，如加密。

您還將學習最佳實踐，並透過工具和範例瞭解如何實施可觀察性，並展示其與安全性和故障排除的相關性。這種對 Kubernetes 平台的可見性增強將為您的特定情況提供可行的洞察。

在本文結束時，您將能夠為您的 Kubernetes 叢集實施這些安全和可觀察性的最佳實踐。

本文使用的排版慣例

本文使用以下排版慣例：

  • 斜體：表示新術語、URLs、電子郵件地址、檔案名稱和檔案副檔名。
  • 等寬字型：用於程式清單，以及在段落中參照程式元素，如變數或函式名稱、資料函式庫、資料型別、環境變數、陳述式和關鍵字。
  • 等寬粗體：顯示應該由使用者逐字輸入的命令或其他文字。
  • _等寬斜體_：顯示應該被使用者提供的數值或由上下文決定的數值所替換的文字。

Kubernetes 安全與可觀測性策略

在 Kubernetes 的世界中，安全與可觀測性是兩個緊密相關且至關重要的議題。本章將對如何為 Kubernetes 環境建立一個全面的安全與可觀測性策略進行高層次的概述。後續章節將對這些概念進行更詳細的探討。

Kubernetes 安全的新挑戰

Kubernetes 與傳統的安全方法有著本質上的不同。隨著工作負載（workloads）向雲端遷移，Kubernetes 成為管理這些工作負載最常見的協調器。其宣告式（declarative）特性使得基礎設施細節被抽象化，使用者只需指定想要執行的 workload 及其預期結果。

傳統安全方法的侷限性

在傳統的環境中，安全團隊會建立一個「機器網路」，然後在上面佈署工作負載（應用程式）。這個過程包括分配 IP 地址、更新網路組態以及定義和實施網路存取控制規則。這些步驟確保了安全團隊對應用程式具有很大的控制權，可以輕鬆地上線和保護應用程式。

Kubernetes 中的安全挑戰

然而，在 Kubernetes 環境中，工作負載被構建為容器映像（container images），並使用組態檔案（YAML）佈署到 Kubernetes 叢集（cluster）中。這個過程通常與開發流程緊密整合，大多數開發團隊使用持續整合（CI）和持續交付（CD）來確保軟體交付的速度和可靠性。這使得安全團隊對每次應用程式變更對叢集安全的影響的可見性有限。

佈署工作負載的生命週期

為了了解如何在 Kubernetes 中保護工作負載，瞭解佈署工作負載的各個階段非常重要。

建構安全與可觀測性策略

本章將涵蓋以下幾個關鍵概念，以指導讀者制定安全與可觀測性策略：

  • Kubernetes 安全與傳統安全方法的差異
  • 在 Kubernetes 叢集中佈署應用程式（workloads）的生命週期，以及每個階段的最佳實踐
  • 如何實施可觀測性以幫助提高安全性
  • 廣為人知的安全框架，以及如何在安全策略中使用它們

為什麼 Kubernetes 安全不同於傳統安全方法

Kubernetes 的抽象層使得應用程式團隊無需擔心 workload 的佈署、執行位置或網路等細節。他們只需在 Kubernetes 中設定組態，即可佈署其應用程式。Kubernetes 透過管理 workload 的建立、關閉和重啟來實作這一抽象。在典型的實施中，workload 可以根據其需求被排程到網路中的任何可用資源（物理主機或虛擬機器）上。

Kubernetes 叢集與網路

一組執行 workload 的資源被稱為 Kubernetes 叢集。Kubernetes 監視著 workload（在 Kubernetes 中以 pod 的形式佈署）的狀態，並在需要時採取糾正措施（例如，重啟無回應的節點）。它還管理著 pod 和主機之間通訊所需的所有網路組態。使用者可以透過選擇支援的網路外掛來決定使用的網路技術。

邁向 Kubernetes 安全的新思維

對於安全團隊來說，Kubernetes 代表了一個新的挑戰。他們需要從傳統的「建立機器網路」的方法轉變為適應 Kubernetes 的動態環境。在 Kubernetes 中，workload 被構建為容器映像，並透過組態檔案佈署。這一過程與開發流程緊密整合，使得安全團隊需要找到新的方法來確保叢集的安全。

程式碼範例：Kubernetes 組態檔案

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
      - name: example-container
        image: example/image:latest
        ports:
        - containerPort: 80

內容解密：

  • apiVersion 和 kind 定義了 Kubernetes 資源的版本和型別。
  • metadata 包含了資源的中繼資料，如名稱。
  • spec 定義了資源的預期狀態，如副本數量和容器映像。
  • selector 和 template 定義瞭如何選擇和建立 pod。
  • containers 列出了容器映像和其他組態。
玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。