IBM Cloud Docs
IBM Cloud Kubernetes Service 的安全

IBM Cloud Kubernetes Service 的安全

您可以在 IBM Cloud® Kubernetes Service 中使用內建安全特性，以進行風險分析及安全保護。 這些特性可協助您保護叢集基礎架構及網路通訊、隔離運算資源，以及確保基礎架構元件和容器部署的安全規範。

如需依產品版本的安全準則分析，請參閱 CIS Kubernetes 基準性能測試。

叢集安全威脅概觀

為了保護叢集免於受損，您必須瞭解叢集的潛在安全威脅，以及可以做些什麼來減少漏洞曝露。

外部攻擊
獲得叢集、已部署資源、應用程式或個人資訊之存取權的攻擊者。
有漏洞的部署
已知的漏洞會被利用來存取雲端環境並執行惡意軟體。
已洩漏或遺失的資料
敏感資料的不正確儲存和加密遺失。
內部人員和第三方廠商
網路隔離和分割的缺失會導致合法權限被濫用。

在過去幾年，雲端安全以及保護系統、基礎架構和資料免受攻擊變得非常重要，因為公司持續將其工作負載移至公用雲端。 叢集由數個元件組成，而且每一個元件都可能讓您的環境面臨惡意攻擊的風險。 若要保護叢集免於這些安全威脅，您必須確定套用最新的 IBM Cloud Kubernetes Service，以及所有叢集元件中的 Kubernetes 安全特性和更新。

這些元件包括：

Kubernetes API 伺服器及 etcd

Kubernetes API 伺服器及 etcd 資料儲存庫是在 Kubernetes 主節點中執行的最機密元件。 您想要防止未獲授權存取這些元件，因為它們會設定並儲存在叢集裡執行的所有資源的配置，包括應用程式的部分安全設定。

Kubernetes 提供安全控制並限制存取，以保護這些元件並降低網路攻擊的風險。

如何授權存取我的 API 伺服器？

在預設情況下，Kubernetes 要求每個請求在存取 API 伺服器之前都要經過幾個階段。

鑑別
驗證註冊使用者或服務帳戶的身分。
授權
限制已驗證使用者和服務帳戶的權限，確保他們只能存取和操作您希望他們存取和操作的群集元件。
許可控制
在 Kubernetes API 伺服器處理之前，驗證或變更要求。 許多 Kubernetes 功能需要入場控制器才能正常運作。

IBM Cloud Kubernetes Service 會如何保護我的 API 伺服器和 etcd 資料儲存空間？

下圖顯示預設的叢集安全設定，用於處理 Kubernetes 主節點與工作者節點之間的鑑別、授權、許可控制及安全連線功能。

說明存取 API 伺服器時的安全階段。
存取 API 伺服器時的安全階段

檢閱 Kubernetes API 伺服器及 etcd的下列安全特性。

完全受管理及專用的 Kubernetes 主節點

IBM Cloud Kubernetes Service 中的每個叢集，都是 IBM 透過 IBM 擁有之 IBM Cloud 帳戶所管理的專用 Kubernetes 主節點而予以控制。 Kubernetes 主節點已設定下列未與其他 IBM 客戶共用的專用元件。

  • etcd 資料儲存： 儲存群集的所有 資源，例如，，和。Kubernetes Services Deployments Pods Kubernetes ConfigMaps 及 Secrets 是儲存為鍵值組的應用程式資料，因此，Pod 中執行的應用程式可以使用它們。 etcd 中的資料會儲存在 Kubernetes 主節點的本端磁碟上，且會備份至 IBM Cloud Object Storage。 資料是在傳送至 IBM Cloud Object Storage 期間和靜止時加密。 您可以選擇在 Kubernetes 主節點的本端磁碟上針對 etcd 資料啟用加密，方法是針對叢集啟用 IBM Key Protect 加密。 當 etcd 資料傳送至 Pod 時，會透過 TLS 將資料加密，以確保資料保護及完整性。
  • kube-apiserver： 作為從 Worker 節點到 Kubernetes master 的所有群集管理請求的主要入口點。 API 伺服器會驗證並處理會變更叢集資源（例如，Pod 或服務）狀況的要求，並將此狀況儲存在 etcd 資料儲存庫中。
  • kube-scheduler： 考慮容量和效能需求、軟硬體政策限制、反親和規格以及工作負載需求，決定部署 Pod 的位置。 如果找不到符合需求的工作者節點，則不會在叢集裡部署 Pod。
  • kube-controller-manager： 負責監控複製集，並建立對應的 Pod 以達到指定的狀態。
  • Konnectivity: IBM Cloud Kubernetes Service 特有的元件，可為所有 Kubernetes 主站點與工作站點之間的通訊提供安全的網路連線。 Konnectivity 伺服器與 Konnectivity 代理合作，以安全地連結主機與工作節點。 此連線支援 apiserver proxy 對您的 Pod 和服務的請求，以及 kubectl top, exec, attach 和 logs 對 kubelet 的請求。 從工作者節點到主節點的連線會自動使用 TLS 憑證保護。
由 IBM Site Reliability Engineer (SRE) 持續監視

IBM Site Reliability Engineer (SRE) 會持續監視 Kubernetes 主節點（包括所有主節點元件、運算、網路及儲存空間資源）。 SRE 會套用最新的安全標準、偵測並重新修補惡意活動，並且努力確保 IBM Cloud Kubernetes Service 的可靠性及可用性。

CIS Kubernetes 主節點基準

要設定 IBM Cloud Kubernetes Service，IBM 工程師會遵循 網際網路安全中心(CIS ) 發佈的 Kubernetes 主基準中的相關網路安全實務。 叢集主節點及所有工作者節點都會部署符合基準性能測試的映像檔。

透過 TLS 的安全通訊

若要使用 IBM Cloud Kubernetes Service，您必須使用認證向服務進行鑑別。 您通過鑑別時，IBM Cloud Kubernetes Service 會產生 TLS 憑證，以加密往返於 Kubernetes API 伺服器及 etcd 資料儲存庫的通訊，確保工作者節點與 Kubernetes 主節點之間的安全端對端通訊。 這些憑證絕不會在叢集或 Kubernetes 主節點元件之間共用。

與工作者節點的連線功能

雖然 Kubernetes 透過使用 https 通訊協定來確保 master 節點與 Worker 節點之間的通訊安全，但預設情況下 Worker 節點不提供驗證。 為了確保這項通訊的安全性，IBM Cloud Kubernetes Service 會在建立群集時，自動在 Kubernetes master 與工作節點之間建立 Konnectivity 連線。

精細存取控制

身為帳戶管理者，您可以使用 IBM Cloud Identity and Access Management (IAM) 授與其他使用者 IBM Cloud Kubernetes Service的存取權。IBM Cloud IAM 提供對 IBM Cloud 平台、IBM Cloud Kubernetes Service及帳戶中所有資源的安全鑑別。 設定適當的使用者角色和權限，是限制誰可以存取您的資源，以及限制使用者在濫用合法權限時可能造成的損害的關鍵。 您可以從下列預先定義的使用者角色中進行選取，這些角色決定使用者可以執行的動作集：

  • 平台存取角色： 決定使用者可以在 IBM Cloud Kubernetes Service 執行的群集和工作站管理相關動作。
  • 服務存取角色： 確定指定給使用者的 Kubernetes RBAC 角色，以及使用者可以針對 Kubernetes API 伺服器執行的動作。 透過 RBAC 角色，使用者可以建立 Kubernetes 資源，例如應用程式部署、命名空間或配置表。 有關指派給使用者的相應 RBAC 角色及相關權限的詳細資訊，請參閱 IAM 服務存取 角色。
  • 經典基礎結構： 可存取您的傳統基礎結構資源。 標準基礎架構角色所允許的動作範例，包括檢視叢集工作者節點機器的詳細資料，或編輯網路及儲存空間資源。
  • VPC 基礎結構： 允許存取 VPC 基礎結構資源。 VPC 基礎架構角色所允許的動作範例，包括建立 VPC、新增子網路、變更浮動 IP 位址，及建立 VPC Block Storage 實例。

如需群集存取控制的詳細資訊，請參閱 指派群集存取權限。

透過服務帳戶記號存取 Pod

對於執行 Kubernetes 1.21 以及更新版本的叢集，Pod 用來與 Kubernetes API 伺服器通訊的服務帳戶記號會受到時間限制、自動重新整理、以特定使用者對象 (Pod) 為範圍，並在刪除 Pod 之後失效。 若要繼續與 API 伺服器通訊，您必須設計應用程式以定期 (例如每分鐘) 讀取重新整理的記號值。 如需相關資訊，請參閱 連結服務帳戶記號。

許可控制器

許可控制器是針對 Kubernetes 及 IBM Cloud Kubernetes Service 中的特定特性而實作。 使用許可控制器，您可以在叢集裡設定原則，以判定是否允許叢集裡的特定動作。 在政策中，您可以指定使用者不能執行某個動作的條件，即使這個動作是您使用 RBAC 角色指派給使用者的一般權限的一部分。 因此，在 Kubernetes API 伺服器處理 API 要求之前，許可控制器可以提供叢集的額外安全層。

當您建立群集時，IBM Cloud Kubernetes Service 會自動在 Kubernetes master 中以特定順序安裝預設的 Kubernetes 接納控制器，使用者無法變更順序。 在 kube-apiserver 元件參照資訊 中，依叢集版本檢閱預設許可控制器的順序。

您可以 在叢集裡安裝自己的許可控制器，或選擇選用的許可控制器，例如 Portieris。 使用 Portieris，您可以從未簽署的映像檔封鎖容器部署。

如果您手動安裝了入場控制器，但不想再使用它們，請務必完全移除它們。 如果未完全移除許可控制器，它們可能會封鎖您要在叢集上執行的所有動作。

我還能做些什麼來保護我的 API 伺服器？

您可以透過多種方式限制與群集主機的網路連接

  • 僅啟用私有雲服務端點：僅經典 OpenShift 叢集需要使用公共服務端點。 可以對所有 VPC 叢集停用它。 只要您的帳戶已 啟用 VRF 和服務端點，也可以停用傳統 Kubernetes 群集。 這可以保護您的叢集主機免受公共網路上的攻擊。
  • 啟用基於上下文的限制：您可以使用基於情境的限制 (CBR) 來保護群集私有和公用服務端點的網路存取。 僅允許源自 CBR 規則中的子網路的對叢集主機的授權請求。 有關詳細信息，請參閱 使用基於上下文的限制。

工作者節點

工作者節點承載了構成您應用程式的部署及服務。 當您在公用雲端中管理工作負載時，請確保您的應用程式受到保護，免於遭到未獲授權的使用者或軟體存取、變更或監視。

誰擁有 Worker 節點，我是否有責任保護它的安全？

工作者節點的所有權取決於您建立的叢集類型，以及您選擇的基礎架構提供者。

  • 傳統叢集：工作節點配置到您的 IBM Cloud 帳戶。 工作者節點為您所專用，而且您負責要求及時更新工作者節點，以確保工作者節點 OS 和 IBM Cloud Kubernetes Service 元件套用最新的安全更新及修補程式。
  • VPC 群集：將工作節點配置到 IBM Cloud 帳戶，該帳戶由 IBM 擁有，以便監控惡意活動和套用安全性更新。 您無法使用 VPC 面板存取工作站節點。 不過，可以使用 IBM Cloud Kubernetes Service 主控台、CLI 或 API 管理工作者節點。 構成工作者節點的虛擬機器為您所專用，而且您負責要求及時更新，以確保工作者節點 OS 和 IBM Cloud Kubernetes Service 元件套用最新的安全更新及修補程式。

如需相關資訊，請參閱使用 IBM Cloud Kubernetes Service 的責任。

定期（例如，每月）使用 ibmcloud ks worker update 指令將更新和安全修補程式部署到作業系統，並更新工作者節點執行的 Kubernetes 版本。 更新可用時，當您在 IBM Cloud 主控台或 CLI（例如使用 ibmcloud ks clusters ls 或 ibmcloud ks workers ls --cluster <cluster_name> 指令）檢視主節點和工作節點的資訊時，就會收到通知。 IBM 會以包含最新安全修補程式的完整工作者節點映像檔形式，提供工作者節點更新。 若要套用更新，必須使用新的映像檔來重新映像化及重新載入工作者節點。 重新載入工作者節點時，會自動替換 root 使用者的金鑰。

我的 Worker 節點設定如何？

下圖顯示針對每個工作者節點所設定的元件，用於保護工作者節點免於惡意攻擊。

此映像檔不包含可確保進出工作者節點之端對端通訊安全的元件。 如需相關資訊，請參閱網路安全。

IBM Cloud Kubernetes Service 中的工作者節點設定，不包括網路安全。
IBM Cloud Kubernetes Service中的工作節點設定（不包括網路安全

CIS-符合規範的影像
每個工作節點都設定了一套作業系統，以執行由網際網路安全中心 ( CIS ) 所發佈的基準。 機器的使用者或擁有者無法將此作業系統變更為另一個作業系統。 若要檢視目前的作業系統版本，請執行 kubectl get nodes -o wide。 IBM 與內部及外部安全顧問團隊合作，解決潛在的安全規範漏洞。 作業系統的安全更新和修補程式是透過 IBM Cloud Kubernetes Service 所提供，並且必須由使用者安裝，才能確保工作者節點的安全。

IBM Cloud Kubernetes Service 工作節點使用 核心。Linux 您可以根據 IBM Cloud Kubernetes Service 中的任何 Linux 發行套件，來執行容器。 請向您的容器影像供應商確認您的容器影像是否可以在核心上執行。

由 Site Reliability Engineer (SRE) 持續監視
IBM Site Reliability Engineer (SRE) 會持續監視工作者節點上所安裝的映像檔，以偵測漏洞及安全規範問題。 為了解決漏洞，SRE 會建立工作者節點的安全修補程式及修正套件。 請務必在這些修補程式可用時套用它們，以確保您的工作節點和在其上執行的應用程式有一個安全的環境。
CIS Kubernetes 工作者節點基準
要設定 IBM Cloud Kubernetes Service，IBM 工程師會遵循 網際網路安全中心(CIS ) 發佈的 Kubernetes Worker 節點基準中的相關網路安全實務。 您可以檢閱工作者節點對 CIS Kubernetes 基準性能測試 標準的相符性。
運算隔離
工作節點專用於一個群集，不會承載其他群集的工作負載。 當您建立標準的傳統群集時，您可以選擇將工 作人員節點配置為實體機器 (裸機)，或配置為在共用或專用實體硬體上執行的虛擬機器。 VPC 叢集裡的工作者節點只能佈建為共用基礎架構上的虛擬機器。
標準裸機的部署選項
如果您建立標準叢集，可以選擇要在裸機實體伺服器（而非虛擬伺服器實例）上佈建工作者節點。 使用裸機機器，您對運算主機可以有更多控制，例如記憶體或 CPU。 此設定可免除虛擬機器 Hypervisor，該 Hypervisor 將實體資源配置給在主機上執行的虛擬機器。 相反，裸機的所有資源都專門用於工作人員，因此您不需要擔心「吵鬧的鄰居」會分享資源或降低效能。 裸機伺服器為您所專用，其所有資源都可供叢集使用。
加密磁碟
依預設，每個工作者節點都會佈建兩個本端 SSD、AES 256 位元加密資料分割區。 第一個分割區包含用來啟動工作者節點且未加密的核心映像檔。 第二個分割區會存放容器檔案系統，並使用 LUKS 加密金鑰解除鎖定。 叢集裡的每一個工作者節點都有由 IBM Cloud Kubernetes Service 所管理的專屬唯一 LUKS 加密金鑰。 當您建立叢集或將工作者節點新增至現有叢集時，會安全地取回金鑰，然後在解除鎖定已加密磁碟之後將金鑰捨棄。 加密可能會影響磁碟 I/O 效能。 對於需要高效能磁碟 I/O 的工作負載，請測試已啟用及停用加密的叢集，以協助您決定是否關閉加密。
專家級 AppArmor 原則
每個 Worker 節點都設定了安全和存取政策，這些政策是由 AppArmor 設定檔強制執行。 AppArmor 使用者或機器擁有者無法變更設定檔。
已停用 SSH
依預設，工作者節點上已停用 SSH 存取，以保護叢集免於惡意攻擊。 停用 SSH 存取時，會透過 Kubernetes API 伺服器強制存取叢集。 在叢集裡執行要求之前，Kubernetes API 伺服器需要針對鑑別、授權及許可控制模組中所設定的原則來檢查每個要求。
如果您有一個標準的群集，而且想要在 Worker 節點上安裝更多的功能，您可以選擇 IBM Cloud Kubernetes Service 提供的附加元件，或是使用 Kubernetes daemon 套件來安裝您想要在每個 Worker 節點上執行的所有功能。 對於任何必須執行的一次性動作，請使用 Kubernetes 作業。

網路

保護公司網路的標準方式是設定防火牆，並封鎖流向您應用程式的任何不想要的網路資料流量。 雖然這仍然正確，但研究顯示，許多惡意攻擊都來自誤用其受指派許可權的內部人員或授權使用者。

標準叢集的網路區隔和隱私權

為了保護您的網路，並限制使用者在獲得網路存取權時可能造成的損壞範圍，您必須確定儘可能隔離工作負載，並且限制以公用方式公開的應用程式及工作者節點數目。

我的 Classic 群集預設允許哪些網路流量？

所有容器都受到預先定義的 Calico 網路原則設定所保護，這些設定是在建立叢集期間配置於每個工作者節點上。 依預設，所有工作者節點都允許所有出埠網路資料流量。 除了下列例外情況之外，入埠網路資料流量會遭到封鎖：

從 Kubernetes master 到 Worker 節點的 kubelet 的存取是透過 Konnectivity tunnel 來保護的。 如需相關資訊，請參閱 IBM Cloud Kubernetes Service 架構。

什麼是網路分割，以及如何為 Classic 群集設定網路分割？

網路區隔說明了用於將網路劃分為多個子網路的方法。 您可以應用程式及相關資料分組在一起，以供組織中的特定群組存取。 在一個子網路中執行的應用程式無法看到或存取另一個子網路中的應用程式。 網路區隔還會限制提供給內部人員或協力廠商軟體的存取權，並且可以限制惡意活動的範圍。

IBM Cloud Kubernetes Service 提供了 IBM Cloud VLAN，用於確保工作者節點的高品質網路效能和網路隔離。 VLAN 會將一組工作者節點和 Pod 視為連接到相同實體佈線那樣進行配置。 VLAN 為您的 IBM Cloud 帳戶所專用，不會在 IBM 客戶之間共用。 在標準叢集裡，如果您的叢集具有多個 VLAN、相同 VLAN 上有多個子網路，或者是您具有多區域的標準叢集，則必須為您的 IBM Cloud 基礎架構帳戶啟用虛擬路由器功能 (VRF)，讓工作者節點可以在專用網路上彼此通訊。 若要啟用 VRF，請參閱 啟用 VRF。 若要檢查是否已啟用 VRF，請使用 ibmcloud account show 指令。 如果您無法或不想啟用 VRF，請啟用 VLAN Spanning。 若要執行此動作，您需要「網路」>「管理網路 VLAN 跨接基礎架構」權限，或者您可以要求帳戶擁有者啟用此權限。 若要檢查 VLAN spanning 是否已經啟用，請使用 ibmcloud ks vlan spanning get --region <region> 指令。

當您啟用帳戶的 VRF 或 VLAN Spanning 時，即會移除叢集的網路區隔。

請檢閱下表，以查看在啟用帳戶的 VRF 或 VLAN Spanning 時如何達成網路區隔的選項。

網路區隔選項
安全特性 說明
使用 Calico 設定自訂網路原則 您可以使用內建 Calico 介面，針對工作者節點設定自訂 Calico 網路原則。 例如，您可以允許或封鎖特定網路介面、特定 Pod 或服務的網路資料流量。 若要設定自訂網路政策，您必須 安裝 calicoctl CLI。
IBM Cloud 網路防火牆的支援 IBM Cloud Kubernetes Service 與所有 IBM Cloud 防火牆供應項目相容。 例如，您可以使用自訂網路原則來設定防火牆，以提供標準叢集的專用網路安全，以及偵測及重新修補網路侵入。 例如，您可能選擇設定 Virtual Router Appliance 作為防火牆，並且封鎖不想要的資料流量。 當您設定防火牆時，也必須開啟必要埠及 IP 位址（針對每一個地區），讓主節點與工作者節點可以進行通訊。

我還能做些什麼來降低 Classic 群集的外部攻擊面？

您公開的應用程式或工作者節點越多，防止外部惡意攻擊所必須採取的步驟就越多。 請檢閱下表，以找出如何將應用程式及工作者節點維持專用狀態的選項。

專用服務及工作者節點選項
安全特性 說明
限制已公開的應用程式數目 依預設，無法透過公用網際網路呼叫到叢集內執行的應用程式及服務。 您可以選擇要將應用程式公開給大眾使用，還是想要讓應用程式及服務只能在專用網路上聯繫。 當您將應用程式及服務維持為專用狀態時，可以運用內建安全特性，來確保工作者節點與 Pod 之間的安全通訊。 若要將服務及應用程式公開給公用網際網路使用，您可以運用 NLB 及 Ingress ALB 支援，安全地將服務設為可公開使用。 確保僅公開必要的服務，並定期重新檢視已公開應用程式的清單，以確保這些應用程式仍然有效。
將工作者節點維持為專用狀態 當您建立叢集時，每個叢集都會自動連接至專用 VLAN。 專用 VLAN 會判定指派給工作者節點的專用 IP 位址。 您可以選擇只將工作者節點連接至專用 VLAN，來將它們維持為專用狀態。 請記住，若要從本機與 Kubernetes 主機通訊，以及讓 IBM Cloud Kubernetes Service 連線至不支援私有雲端服務端點的 IBM Cloud 服務，您必須設定 特定 URL 和 IP 位址 的公用連線。 如果您要連線的 IBM Cloud 服務有私有雲服務端點，且您的帳戶已啟用 VRF，則來往這些服務的網路流量會自動透過私有網路路由，無需使用公共網路連線。 若要針對只連接至專用 VLAN 的叢集設定公用連線功能，您可以在工作者節點的前面配置防火牆（例如 Virtual Router Appliance），並啟用流入這些 URL 及 IP 位址的網路資料流量。
使用邊緣節點限制公用網際網路連線功能 如果您沒有建立啟用閘道的群集，每個 Worker 節點都會設定為接受應用程式 Pod 和相關的負載平衡器或入口 Pod。 您可以將工作者節點標示為邊緣節點，強制只將負載平衡器及 Ingress Pod 部署至這些工作者節點。 此外，您可以 汙染工作節點，使應用程式 Pod 無法排程到邊緣節點。 使用邊緣節點，您可以將網路工作負載隔離到叢集裡較少數的工作者節點，並將叢集裡的其他工作者節點維持為專用狀態。

如果我要將叢集連線至內部部署的資料中心，該怎麼辦？

若要將工作者節點及應用程式連接至內部部署資料中心，您可以配置具有 strongSwan 服務、Virtual Router Appliance 或 Fortigate Security Appliance 的 VPN IPSec 端點。

VPC 叢集的網路區隔和隱私權

為了保護您的網路，並限制使用者在獲得網路存取權時可能造成的損壞範圍，您必須確定儘可能隔離工作負載，並且限制以公用方式公開的應用程式及工作者節點數目。

我的 VPC 群集預設允許哪些網路流量？

依預設，工作者節點僅連接至專用網路上的 VPC 子網路，且沒有公用網路介面。 您的工作站節點的所有公共入口都被封鎖。 僅當工作者節點連接至具有公用閘道的 VPC 子網路時，才容許來自工作者節點的公用 Egress。

如果工作者節點必須存取叢集外部的公用端點，則可以將公用閘道連接到工作者節點部署到的 VPC 子網路。 例如，您的 VPC 群集可自動連線至其他 支援私有雲服務端點的 IBM Cloud 服務，例如 IBM Cloud Container Registry。 但是，如果您需要存取只支援公共雲端服務端點的 IBM Cloud 服務，您可以將公共閘道附加到子網路，讓您的 Pod 可以透過公共網路傳送請求。 對於連接有為公用閘道的子網路上的工作者節點，允許其所有流出流量，但仍會封鎖所有流入流量。

如果在叢集裡部署必須從網際網路接收資料流量要求的應用程式，則可以建立 VPC 負載平衡器來公開應用程式。 若要容許流入應用程式的網路資料流量，必須為要接收的流入網路資料流量配置 VPC 負載平衡器。

依預設，安全群組會套用至 VPC 實例及 VPC ALB。 如需相關資訊，請參閱 使用 VPC 安全群組控制資料流量。

什麼是網路分割，以及如何為 VPC 群集設定網路分割？

網路區隔說明了用於將網路劃分為多個子網路的方法。 您可以應用程式及相關資料分組在一起，以供組織中的特定群組存取。 在一個子網路中執行的應用程式無法看到或存取另一個子網路中的應用程式。 網路區隔還會限制提供給內部人員或協力廠商軟體的存取權，並且可以限制惡意活動的範圍。

IBM Cloud Kubernetes Service 提供 子網路，可確保工作節點的優質網路效能和網路隔離。IBM Cloud VPC VPC 子網路包含指定的專用 IP 位址範圍（CIDR 區塊），並將一群組工作者節點和 Pod 視為連接到相同實體連線那樣進行配置。 VPC 子網路專用於您的 IBM Cloud 帳戶，而不是在 IBM 客戶之間共用。

VPC 子網路提供了一個頻道，用於連線功能叢集內的工作者節點。 任何連接至相同 VPC 中任何專用子網路的系統都可以與工作者節點進行通訊。 例如，一個 VPC 中的所有子網路都可以透過專用第 3 層遞送與內建 VPC 路由器進行通訊。 如果您的群集不需要溝通，您可以在獨立的 VPC 中建立群集，以達到最佳的網路分割效果。 如果您有多個叢集必須相互通訊，則可以在相同 VPC 中建立這些叢集。 雖然 VPC 中的子網路可以由該 VPC 中的多個叢集共用，但透過將不同的子網路用於 VPC 中的各個叢集，可以實現更好的網路區隔。

若要在帳戶的 VPC 子網路之間實現進一步的專用網路區隔，可以使用 VPC 存取控制清單 (ACL) 來設定自訂網路原則。 當您建立 VPC 時，會以 allow-all-network-acl-<VPC_ID> 的格式為 VPC 建立預設 ACL。 依預設，您在 VPC 中建立的任何子網路都會連接至這個 ACL。 ACL 包含入埠規則和出埠規則，可允許子網路上的工作者節點與相同 VPC 中的子網路上任何系統之間的所有資料流量。 如果要指定允許流至 VPC 子網路上工作者節點的專用網路資料流量，則可以為 VPC 中的每個子網路建立自訂 ACL。 例如，可以建立一組 ACL 規則來封鎖叢集的大多數入埠和出埠專用網路資料流量，同時容許叢集正常運作所需的通訊。

我還能做些什麼來降低 VPC 群集的外部攻擊面？

您公開的應用程式或工作者節點越多，防止外部惡意攻擊所必須採取的步驟就越多。 請檢閱下表，以找出如何將應用程式及工作者節點維持專用狀態的選項。

VPC 網路安全選項
安全特性 說明
限制已公開的應用程式數目 依預設，無法透過公用網際網路呼叫到叢集內執行的應用程式及服務。 您可以選擇要將應用程式公開給大眾使用，還是想要讓應用程式及服務只能在專用網路上聯繫。 當您將應用程式及服務維持為專用狀態時，可以運用內建安全特性，來確保工作者節點與 Pod 之間的安全通訊。 若要將服務和應用程式公開到公用網際網路，可以利用 VPC 負載平衡器和 Ingress ALB 支援來安全地使服務公用可用。 確保僅公開必要的服務，並定期重新檢視已公開應用程式的清單，以確保這些應用程式仍然有效。
將公用網路流量限制至流出到使用公用閘道的一個子網路 如果工作者節點上的 pod 需要連接至公用外部端點，則可以將公用閘道連接至這些工作者節點所在的子網路。 您可以將公用閘道只連接至叢集裡的一個子網路，以便在叢集裡隔離此網路資料流量。 然後，您可以 設定親和性規則，將需要存取外部端點的應用程式 Pod 部署到僅附有公用閘道的子網路。

根據要將工作者節點連接至的網路，可以選擇 VPN 解決方案。

使用 LoadBalancer 和 Ingress 服務安全地揭露應用程式

您可以使用網路負載平衡器 (NLB) 及 Ingress 應用程式負載平衡器 (ALB) 網路服務，將您的應用程式連接至公用網際網路或外部專用網路。 請檢閱 NLB 及 ALB 的下列選用設定，您可以使用這些設定來符合後端應用程式安全需求，或在資料流量流經叢集時將資料流量加密。

我可以使用安全群組來管理群集的網路流量嗎？

標準叢集：IBM Cloud 安全群組會套用至單一虛擬伺服器的網路介面，以過濾 Hypervisor 層次的資料流量。 如果要管理每個工作者節點的資料流量，可以使用安全群組。 建立安全群組時，必須容許 VRRP 通訊協定，IBM Cloud Kubernetes Service 使用此通訊協定來管理 NLB IP 位址。 若要在所有工作節點上統一管理群集的流量，請使用 Calico 和 Kubernetes 策略。

VPC 群組：VPC 安全群組套用至單一虛擬伺服器的網路介面，以在管理程序層級過濾流量。 您可以將入埠及出埠規則新增至叢集的預設安全群組，以管理 VPC 叢集的入埠及出埠資料流量。 如需安全群組 (包括預設值) 的相關資訊，請參閱 使用 VPC 安全群組控制資料流量。

因為 VPC 叢集的工作者節點存在於服務帳戶中，且未列在 VPC 基礎架構儀表板中，所以您無法建立安全群組並將其套用至工作者節點實例。 您只能修改為您建立的現有安全群組。

如何確保叢集內來源 IP 的安全？

在 2.0 版 NLB 中，依預設會保留用戶端要求的來源 IP 位址。 不過，在 1.0 版 NLB 及所有 Ingress ALB 中，不會保留用戶端要求的來源 IP 位址。 將應用程式的用戶端要求傳送至叢集時，會將該要求遞送至 NLB 1.0 或 ALB 的 Pod。 如果沒有應用程式 Pod 存在於與負載平衡器服務 Pod 相同的工作者節點上，則 NLB 或 ALB 會將要求轉遞至不同工作者節點上的應用程式 Pod。 套件的來源 IP 位址會變更為應用程式 Pod 執行所在之工作者節點的公用 IP 位址。

舉例來說，當應用程式伺服器必須套用安全及存取控制原則時，保留用戶端的 IP 是很有用的。 若要保留用戶端要求的原始來源 IP 位址，您可以針對 1.0 版 NLB 或 Ingress ALB 啟用來源 IP 保留。

如何使用 LoadBalancer 和 Ingress 服務進行 TLS 終止？

Ingress 服務會在資料傳輸流程的兩個點提供 TLS 終止：

  • 抵達時解密套件：預設情況下，Ingress ALB 負載平衡 HTTP 網路流量到您群集中的應用程式。 若要同時對送入的 HTTPS 連線進行負載平衡，您可以配置 ALB 來解密網路資料流量，並將解密的要求轉遞至叢集裡公開的應用程式。 如果您使用 IBM 提供的 Ingress 子網域，則可以使用 IBM 提供的 TLS 憑證。 如果您使用自訂網域，則可以使用自己的 TLS 憑證來管理 TLS 終止。
  • 將套件轉遞至上游應用程式之前進行重新加密：在將資料流量轉遞至應用程式之前，ALB 會將 HTTPS 要求解密。 如果您的應用程式需要 HTTPS，並且需要在將資料流量轉遞至這些上游應用程式之前先予以加密，則可以使用 ssl-services 註釋。 如果您的上游應用程式可以處理 TLS，則您可以選擇提供單向或交互鑑別 TLS 密碼中包含的憑證。

為了確保服務與服務之間通訊的安全性，您可以使用 Istio 的相互 TLS 認證。 Istio 是一種開放程式碼服務，它提供方法讓開發人員連接、保護、管理及監視雲端編排平台（例如 Kubernetes）上的微服務網路（也稱為服務網格）。

持續性儲存空間

請檢閱支援的選項，以加密及保護 IBM Cloud 中持續性儲存空間上的資料。

依預設，所有 IBM Cloud 儲存空間解決方案會使用 IBM 管理的加密金鑰，自動將您的靜止資料加密，且不會有額外的成本。 如需相關資訊，請參閱下列鏈結。

視您選擇的儲存空間類型而定，您可以使用 IBM Key Protect 設定額外的加密，以在傳輸中保護您的資料，以及使用您自己的加密金鑰在靜止時保護資料。

您也可以使用 IBM Cloud 資料庫服務（例如 IBM Cloudant NoSQL DB），將資料持續保存在叢集之外的受管理資料庫中。 利用雲端資料庫服務所儲存的資料，可以跨越叢集、區域及地區進行存取。 如需安全相關資訊，請參閱資料庫服務特定的 IBM Cloud 文件。

監視及記載

偵測叢集裡惡意攻擊的關鍵，在於適當監視及記載度量值以及叢集裡發生的所有事件。 監視及記載也可協助您瞭解應用程式的叢集容量及資源可用性，因此您可以據此規劃來保護應用程式免於發生運作中斷時間。

IBM 是否監控我的群集？
IBM 會持續監視每個叢集主節點，以控制及重新修補處理程序層次「阻斷服務 (DOS)」攻擊。IBM Cloud Kubernetes Service 會自動掃描每個部署主節點的節點，以找出在 Kubernetes 及 OS 特定安全修正程式中找到的漏洞。 如果找到漏洞，IBM Cloud Kubernetes Service 會自動套用修正程式，並代表使用者來解決漏洞以確保主節點保護。
記載哪些資訊?
預設情況下，IBM Cloud Kubernetes Service 會自動收集下列群集元件的日誌：
  • 容器：寫入至 STDOUT 或 STDERR 的日誌。
  • 應用程式：寫入至應用程式內特定路徑的日誌。
  • 工作者節點：來自 Ubuntu 作業系統並傳送至 /var/log/syslog 及 /var/log/auth.log 的日誌。
  • Kubernetes API 伺服器：會針對審核原因而記載傳送至 Kubernetes API 伺服器的每個叢集相關動作，包括時間、使用者及受影響資源。 如需詳細資訊，請參閱 Kubernetes 稽核記錄。 您可以使用 IBM Cloud Logs 來存取這些日誌。
  • Ingress：管理入埠網路資料流量之 Ingress 應用程式負載平衡器 (ALB) 的日誌。
  • Kubernetes 系統元件：來自 kubelet、kube-proxy 以及在 kube-system 名稱空間中執行之其他元件的日誌。

若要存取群集元件日誌，您可以選擇將日誌轉寄到 IBM Cloud Logs }}、外部伺服器或第三方日誌解決方案。 如需相關資訊，請參閱選擇記載解決方案。

如何監控群集的健康狀況和效能？
您可以從 IBM Cloud Kubernetes Service 主控台或 CLI 監視叢集元件及運算資源（例如 CPU 及記憶體用量），來驗證應用程式、服務及工作者節點的性能、容量及效能。 若要檢視標準叢集或應用程式的更深入度量值，您可以在叢集裡配置監視代理程式，以將度量值傳送至 IBM Cloud Monitoring。 您也可以安裝第三方監控解決方案，例如 Prometheus，或使用 Kubernetes 面板中提供的指標。 如需相關資訊，請參閱選擇監視解決方案。

若要設定主機入侵偵測系統 (HIDS) 和安全事件日誌監控 (SELM)，請安裝專門用於監控您的群集和容器化應用程式以偵測入侵或濫用的第三方工具，例如 Twistlock 或 Sysdig Falco 專案。

如何稽核群集中發生的事件？
您可以在 IBM Cloud Logs 叢集裡設定 IBM Cloud Kubernetes Service。 如需詳細資訊，請檢視 Learn more about IBM Cloud Logs 文件。
在我的群集中啟用信任的選項有哪些？
依預設，IBM Cloud Kubernetes Service 提供叢集元件的許多特性，讓您可以在高度安全的環境中部署容器化應用程式。 擴大叢集裡的信任層次，以便更確保在叢集內發生的事情是您預期會發生的情況。 您可以使用各種方式在叢集裡實作信任，如下圖所示。

部署具有授信內容的儲存器。
部署具有可信任內容的容器

  1. 映像檔的內容信任：在 IBM Cloud Container Registry 中啟用內容信任，以確保映像檔的完整性。 使用受信任的內容，您可以控制誰可以將映像檔簽署為受信任映像檔。 在受信任簽章者將映像檔推送至您的登錄之後，使用者可以取回已簽署的內容，以便他們能驗證映像檔的來源。 如需相關資訊，請參閱簽署受信任內容的映像檔。

  2. 容器影像安全強制執行：使用具有自訂政策的存取控制器，以便您可以在部署容器影像前驗證它們。 使用容器映像檔安全強制執行專案 (例如 Portieris)，您可以控制映像檔的部署來源，並確保它們符合 內容信任 需求。 如果部署不符合您所設定的原則，則安全強制執行會阻止他人修改您的叢集。

  3. Image Vulnerability Scanner：依預設，Vulnerability Advisor 會掃描 IBM Cloud Container Registry 中儲存的映像檔，以尋找可能的安全漏洞。 如需相關資訊，請參閱使用 Vulnerability Advisor 管理映像檔安全。

  4. IBM Cloud Security and Compliance Center: 當您啟用 IBM Cloud Security and Compliance Center時，您可以檢視可疑送入及送出網路資料流量的相關報告。 如需相關資訊，請參閱 何謂 IBM Cloud Security and Compliance Center?。

  5. IBM Cloud® Secrets Manager: 您可以將 Ingress 和 Kubernetes 密碼儲存在 IBM Cloud® Secrets Manager中。 當您將 Secrets Manager 整合至叢集時，請設定已上傳所有 Ingress 子網域密碼的預設 Secrets Manager 實例。 如需相關資訊，請參閱 在 Kubernetes Service 叢集裡設定 Secrets Manager。

映像檔及登錄

每個部署都是根據映像檔，而映像檔中存放如何加速執行應用程式之容器的指示。 這些指示包含容器內部的作業系統，以及您要安裝的額外軟體。 為了保護應用程式，您必須保護映像檔並建立檢查以確保映像檔完整性。

我應該使用公共註冊表還是私人註冊表來儲存我的影像？
公用登錄（例如 Docker Hub）可用來開始使用 Docker 映像檔及 Kubernetes，以在叢集裡建立第一個容器化應用程式。 但是，如果是企業應用程式，請避免使用您不知道或不信任的登錄來保護叢集免於接觸惡意映像檔。 將映像檔保留在專用登錄中（例如 IBM Cloud Container Registry 中提供的專用登錄），並且務必控制對登錄和可推送之映像檔內容的存取。
為什麼檢查影像是否有漏洞很重要？
研究顯示，大部分的惡意攻擊會運用已知的軟體漏洞，和薄弱的系統配置。 當您從映像檔部署容器時，容器會隨著您在映像檔中所描述的 OS 及額外二進位檔而加速。 就像保護虛擬或實體機器一樣，您必須刪除容器內所使用 OS 及二進位檔的已知漏洞，讓未獲授權的使用者無法存取應用程式。

若要保護應用程式，請考慮處理下列領域：

  1. 自動化建立程序並限制權限：自動化從您的原始碼建立容器映像的程序，以消除原始碼的變異和瑕疵。 將建置處理程序整合到 CI/CD 管線，即可確保會掃描您的映像檔，並且只有在映像檔通過您指定的安全檢查時，才會進行建置。 若要避免開發人員將緊急修復程式套用至機密映像檔，請限制組織中有權存取建置處理程序的人員數目。

  2. 在部署到生產之前掃描影像： 確保在部署容器之前掃描每個影像。 例如，如果您使用 IBM Cloud Container Registry，則將映像檔推送至名稱空間時，會自動掃描所有映像檔中的漏洞。 如果發現漏洞，請考慮刪除漏洞，或封鎖這些映像檔的部署。 請尋找組織中負責監視及移除漏洞的人員或團隊。 取決於組織結構，此人員可能是安全、作業或部署團隊的一員。 啟用 內容信任，以便映像檔必須先由信任的簽章者核准，然後才能推送至儲存器登錄。 然後，安裝開放程式碼 Portieris 專案 許可控制器，以封鎖來自未簽署映像檔的容器部署。

  3. 定期掃描執行中的容器：. 即使您已從映像檔中部署通過漏洞檢查的容器，但一段時間之後，容器中所執行的作業系統或二進位檔還是會有漏洞。 若要保護您的應用程式，您必須確定定期掃描執行中的容器，以便偵測並重新修補漏洞。 視應用程式而定，為了增加額外的安全性，您可以建立一個工作，在偵測到易受攻击的容器後，將其移除。

映像檔及部署的安全
安全特性 說明
IBM Cloud Container Registry中的安全 Docker 專用映像檔儲存庫 在 IBM所管理的多方承租戶、高可用性及可調式專用映像檔登錄中設定您自己的 Docker 映像檔儲存庫。 透過使用登錄，您可以在叢集使用者之間建置、安全地儲存及共用 Docker 映像檔。/n 進一步瞭解使用容器映像檔時 保護個人資訊安全。
僅推送具有受信任內容的映像檔 透過在映像檔儲存庫中啟用 內容信任 來確保映像檔的完整性。 使用受信任內容，您可以控制誰能將映像檔簽署為受信任映像檔，並將映像檔推送至特定登錄名稱空間。 在可信賴的簽章者將影像推送至註冊名稱空間後，使用者可以讀取已簽章的內容，以驗證影像的發行者和完整性
自動漏洞掃描 當您使用 IBM Cloud Container Registry時，您可以利用 Vulnerability Advisor 所提供的內建安全掃描。 會自動掃描每個推送至您登錄名稱空間的映像檔，以對照已知 CentOS、Debian、Red Hat 及 Ubuntu 問題的資料庫來掃描漏洞。 如果發現漏洞，Vulnerability Advisor 會提供如何解決的指示，以確保影像的完整性與安全性
封鎖來自有漏洞映像檔或未授信使用者的部署 建立具有自訂原則的許可控制器，以便您可以在部署它們之前驗證容器映像檔。 使用 開放程式碼 Portieris 專案，您可以控制映像檔的部署來源，並確保它們符合內容信任需求。 如果部署不符合您設定的政策，接納控制器會阻止群集中的部署
我有哪些選項可以掃描執行中的容器是否有漏洞？
您可以在叢集裡安裝協力廠商解決方案，例如 Twistlock 或 StackRox，以掃描執行中的容器，並在偵測到惡意活動時封鎖它們。

容器隔離及安全

當您在叢集裡執行多個應用程式時，您要確定工作負載執行時會彼此隔離，且您要限制叢集內的 Pod 許可權，以避免吵雜的鄰居或阻斷式服務攻擊。

什麼是 Kubernetes 命名空間，為什麼要使用它？
Kubernetes 名稱空間這種方式使用虛擬方式分割叢集，並隔離部署以及要將其工作負載移至叢集的使用者群組。 使用名稱空間，您可以跨工作者節點來組織資源，也可以跨多區域叢集裡的區域來組織資源。
每個叢集都已設定一組預設 Kubernetes 名稱空間，其中包含 IBM Cloud Kubernetes Service 所需的部署及服務，以便適當地執行及管理叢集。 如需相關資訊，請參閱服務架構。
叢集管理者自動便可存取這些名稱空間，並且可以在叢集裡設定其他名稱空間。

對於群集中的每個命名空間，請務必設定適當的 RBAC 政策，以限制此命名空間的存取權限、控制部署的內容，以及設定適當的 資源配額和 限制範圍。

我應該設定單一租戶還是多租戶群集？

在單一承租戶叢集裡，您會針對必須在叢集裡執行工作負載的每一群人建立一個叢集。 通常，這個團隊會負責管理叢集，以及適當地配置與保護其安全。 多方承租戶叢集會使用多個名稱空間來隔離承租戶及其工作負載。

決定單一租戶或多租戶叢集。
單一租戶與多租戶集群

決定要使用單一承租戶叢集還是多方承租戶叢集，取決於必須在叢集裡執行工作負載的團隊數目、其服務需求、服務大小以及您要為工作負載達成的隔離層次。

如果您有很多具有複雜服務的團隊，並且每個團隊都必須控制叢集的生命週期，則單一承租戶叢集可能是適合您的選項。 這包括自行決定叢集更新時間或是可部署哪些資源到叢集的自由。 您也可以配置單一承租戶叢集以允許使用特許 Pod，而不會使其他承租戶面臨洩漏風險。 請謹記，管理叢集需要深入的 Kubernetes 及基礎架構知識，才能確保部署的叢集容量及安全。

多方承租戶叢集使用 Kubernetes 名稱空間來隔離承租戶，並且通常是由不屬於其中某個承租戶的不同團隊來進行管理。 如果您有多個團隊必須在一個叢集裡執行多個小型工作負載，並且建立在多個區域之間具高可用性的單一承租戶叢集不會帶來您想要的成本效益，則多方承租戶叢集可能是適合您的選項。 雖然多方承租戶叢集通常只需要較少的人員即可管理叢集，但這種叢集可能無法提供您需要的隔離層次，並且在下列方面增加更多複雜性：

  • **存取權：**當您設定多個名稱空間時，必須為每一個名稱空間配置適當的 RBAC 原則，以確保資源隔離。 RBAC 原則十分複雜，而且需要深入的 Kubernetes 知識。
  • **特許 Pod：**如果多方承租戶叢集裡有一個承租戶需要執行特許 Pod，則此 Pod 可能會存取叢集裡的其他名稱空間或損壞共用的運算主機。 控制特許 Pod 是一項複雜的作業，需要大量心力和深入的技術專門知識。 使用 Pod 安全政策 (PSP) 來控制租戶可以在群集中部署哪些資源。
  • 網路政策： 由於您的 Worker 節點連接至相同的私有網路，因此您必須確保有嚴格的網路政策，以防止 Pod 存取其他命名空間中的 Pod。
  • 計算資源限制： 為了確保每個團隊都有必要的資源在群集中部署服務和執行應用程式，您必須為每個命名空間設定 資源配額。 資源配額決定部署限制，例如您可以部署的 Kubernetes 資源數量，以及這些資源可以消耗的 CPU 和記憶體數量。 設定配額之後，使用者必須在其部署中包含資源要求和限制。
  • **共用的叢集資源：**如果您在某一個叢集裡執行多個承租戶，則會跨承租戶共用部分叢集資源，例如 Ingress 應用程式負載平衡器 (ALB) 或可用的可攜式 IP 位址。 如果較小的服務必須與叢集裡的大型服務競爭，它們使用共用的資源時可能會很困難。
  • **更新：**您一次只能執行一個 Kubernetes API 版本。 在叢集裡執行的所有應用程式都必須符合現行 Kubernetes API 版本，且不論擁有應用程式的團隊為何。 當您想要更新叢集時，必須確保所有團隊都準備好切換至新的 Kubernetes API 版本，並且相對應地更新應用程式。 這也表示個別團隊對他們要執行的 Kubernetes API 版本控制權較低。
  • **叢集設定的變更：**如果您想要變更叢集設定，或將工作負載重新排定到新的工作者節點，您必須跨承租戶來推展這項變更。 這項推展需要的核對及測試會高於單一承租戶叢集。
  • **通訊處理程序：**當您管理多個承租戶時，請考慮設定通訊處理程序，讓承租戶知道當叢集發生問題時或他們的服務需要更多資源時，該何去何從。 這個通訊處理程序也包括通知承租戶有關叢集設定的所有變更或計劃的更新項目。

雖然單一承租戶叢集和多方承租戶叢集的成本大致相同，但單一承租戶叢集提供的隔離層次高於多方承租戶叢集裡名稱空間的隔離層次。 若要更妥善地隔離工作負載，請使用單一承租戶叢集。

Kubernetes 網路原則 會保護 Pod 免受內部網路資料流量的影響。 例如，如果大部分或所有 Pod 都不需要存取特定 Pod 或服務，且您想要確保 Pod 依預設無法存取那些 Pod 或服務，則您可以建立 Kubernetes 網路原則來封鎖那些 Pod 或服務的進入資料流量。 Kubernetes 網路原則也可以透過控制不同名稱空間中的 Pod 和服務如何進行通訊，來協助您在名稱空間之間施行工作負載隔離。

如何控制 Pod 權限？
預設情況下，每個群集都會啟用 Kubernetes pod 安全政策准入控制器，您可以使用它來定義 pod 在命名空間中部署時必須符合的要求。 使用 Pod 安全原則，您可以控制特許容器、根名稱空間、主機網路及埠、磁區類型、主機檔案系統和 Linux 許可權（例如唯讀或群組 ID）等等的使用。
我還能做些什麼來保護我的貨櫃？
限制特權容器的數量。 容器會在與其他處理程序隔離的運算主機上，以個別的 Linux 處理程序形式執行。 雖然使用者在容器內部有 root 存取權，但是會限制此使用者在容器以外的許可權，以保護其他 Linux 處理程序、主機檔案系統及主機裝置。 部分應用程式需要存取主機檔案系統或進階許可權，才能正常執行。 您可以使用特許模式來執行容器，以允許容器具有與運算主機上執行之處理程序相同的存取權。
請謹記，特許容器若遭到洩漏，可能會對叢集和基礎運算主機造成重大損壞。 請嘗試限制以特許模式執行的容器數目，並考慮變更應用程式的配置，讓應用程式可以在沒有進階許可權的情況下執行。

如果您想阻止有特權的容器在群集中執行，請考慮設定自訂 Pod 安全政策。

將 OS 安全設定套用至 Pod
您可以在 Pod 中加入 securityContext 部分，以控制可以在容器內執行的使用者 ID 和群組 ID，或擁有磁碟區掛載路徑的使用者 ID 和群組 ID。 設定特定使用者 ID 有助於促進最少專用權模型。 如果安全環境定義未指定使用者，則 Kubernetes 會自動使用容器映像檔中指定的使用者。
如果要使用 securityContext 設定 runAsUser 使用者 ID 或 fsGroup 群組 ID，請考慮在 建立持久性儲存 時使用區塊儲存。 NFS 儲存不支援，而且 必須在容器層級而非 pod 層級設定。fsGroup runAsUser
設定容器的 CPU 及記憶體限制
每個容器都需要特定 CPU 及記憶體數量，才能適當地啟動並繼續執行。 您可以為您的容器或 Pod 定義 Kubernetes 資源請求和資源限制，以限制它們可以消耗的 CPU 和記憶體。 如果未設定 CPU 及記憶體的限制，而且容器忙碌，則容器會使用所有可用的資源。 這種高資源消耗可能會影響 Worker 節點上其他沒有足夠資源正常啟動或執行的容器，並使您的 Worker 節點面臨拒絕服務攻擊的風險。
強制執行原則驅動的鑑別
您可以將 Ingress 註釋新增至部署，以控制對服務與 API 的存取權。 藉由使用 App ID 和宣告式安全，可以確保使用者鑑別和記號驗證。

儲存個人資訊

您負責確保 Kubernetes 資源及容器映像檔中的個人資訊安全。 個人資訊包括您的姓名、地址、電話號碼、電子郵件位址，或者可識別、聯絡或找到您、您的客戶或其他人的其他資訊。

使用 Kubernetes 密碼儲存個人資訊

請將個人資訊僅儲存在設計來存放個人資訊的 Kubernetes 資源中。 例如，請勿在 Kubernetes 命名空間、部署、服務或配置映射的名稱中使用您的姓名。 如需適當的保護及加密，請改為將個人資訊儲存在 secret 中。

如需在應用程式執行時期跨叢集及注入項目集中管理您的所有密碼，請嘗試 IBM Cloud Secrets Manager。

使用 Kubernetes imagePullSecret 儲存映像檔登錄認證

請不要將個人資訊儲存在容器映像檔或登錄名稱空間中。 為了適當的保護和加密，請將註冊憑證儲存在 Kubernetes imagePullSecrets 而其他個人資訊則存放在 秘密中。 請記住，如果個人資訊儲存在映像檔的上一層中，則刪除映像檔可能不足以刪除此個人資訊。

若要設定密鑰的加密，請參閱 使用金鑰管理服務(KMS)提供者加密 Kubernetes 密鑰。

Kubernetes 安全性公告

如果在 Kubernetes 中找到漏洞，則 Kubernetes 會在安全性公告中發行 CVE，以通知使用者並且說明使用者為補救漏洞必須採取的動作。 影響 IBM Cloud Kubernetes Service 使用者或 IBM Cloud 平台的 Kubernetes 安全性公告則會在 IBM Cloud 安全性公告中發佈。

部分 CVE 需要 Kubernetes 版本的最新修補程式更新，您可以在 IBM Cloud Kubernetes Service 中的一般叢集更新處理程序過程中安裝。 請務必及時套用安全修補程式，以保護叢集不受惡意攻擊。 有關安全修補程式所包含內容的詳細資訊，請參閱 Kubernetes 版本資訊。