IBM Cloud Kubernetes Service 的安全

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

如需依產品版本分析安全指引，請參閱 CIS Kubernetes Benchmark。

叢集安全威脅概觀

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

外部攻擊
獲得叢集、已部署資源、應用程式或個人資訊之存取權的攻擊者。
有漏洞的部署
攻擊者利用已知的漏洞，以取得雲端環境的存取權限並執行惡意軟體。
已洩漏或遺失的資料
敏感資料儲存方式不當，且未進行加密。
內部人員與第三方供應商
若缺乏網路隔離與分段機制，可能會導致合法權限遭濫用。

在過去幾年，雲端安全以及保護系統、基礎架構和資料免受攻擊變得非常重要，因為公司持續將其工作負載移至公用雲端。 叢集由數個元件組成，而且每一個元件都可能讓您的環境面臨惡意攻擊的風險。 若要保護叢集免於這些安全威脅，您必須確定套用最新的 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： 作為工作節點向 Kubernetes 主節點發送所有叢集管理請求的主要入口點。 API 伺服器會驗證並處理會變更叢集資源（例如，Pod 或服務）狀況的要求，並將此狀況儲存在 etcd 資料儲存庫中。
  • kube-scheduler： 根據容量與效能需求、硬體與軟體政策限制、反親和性規範以及工作負載需求，決定將 Pod 部署至何處。 如果找不到符合需求的工作者節點，則不會在叢集裡部署 Pod。
  • kube-controller-manager： 負責監控複本集，並建立相應的 Pod 以達到指定的狀態。
  • Konnectivity： IBM Cloud Kubernetes Service 專用元件，用於為所有 Kubernetes 主節點與工作節點之間的通訊提供安全的網路連線。 Konnectivity 伺服器會與 Konnectivity 代理程式協同運作，以安全的方式將主節點與工作節點連接起來。 此連線支援針對您的 Pod 和服務的 apiserver proxy 請求，以及針對 kubelet 的 kubectl top、exec、attach 和 logs 請求。 從工作者節點到主節點的連線會自動使用 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 協定來確保主節點與工作節點之間的通訊安全，但預設情況下，工作節點並未提供任何驗證機制。 為了確保此通訊的安全性，當叢集建立時，IBM Cloud Kubernetes Service 會自動在 Kubernetes 主節點與工作節點之間建立 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 主節點上安裝預設的 Kubernetes 准入控制器，此順序無法由使用者變更。 在 kube-apiserver 元件參照資訊 中，依叢集版本檢閱預設許可控制器的順序。

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

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

我還能做些什麼來加強 API 伺服器的安全性？

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

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

工作者節點

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

工作節點的擁有者是誰？我是否需要負責確保其安全性？

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

  • 經典叢集：工作節點已部署至您的 IBM Cloud 帳戶中。 工作者節點為您所專用，而且您負責要求及時更新工作者節點，以確保工作者節點 OS 和 IBM Cloud Kubernetes Service 元件套用最新的安全更新及修補程式。
  • VPC 叢集：工作節點會配置至由 IBM 所擁有的 IBM Cloud 帳戶中，以便監控惡意活動並套用安全性更新。 您無法透過 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 使用者的金鑰。

我的工作節點設定看起來如何？

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

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

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 工作節點基準測試中相關的網路安全實務。 您可以檢閱工作者節點對 CIS Kubernetes 基準性能測試 標準的相符性。
運算隔離
工作節點專屬於某個叢集，不會託管其他叢集的工作負載。 建立標準經典叢集時，您可以選擇將工作節點配置為實體機器（裸機），或是配置為在共用或專用實體硬體上運行的虛擬機器。 VPC 叢集裡的工作者節點只能佈建為共用基礎架構上的虛擬機器。
標準裸機的部署選項
如果您建立標準叢集，可以選擇要在裸機實體伺服器（而非虛擬伺服器實例）上佈建工作者節點。 使用裸機機器，您對運算主機可以有更多控制，例如記憶體或 CPU。 此設定可免除虛擬機器 Hypervisor，該 Hypervisor 將實體資源配置給在主機上執行的虛擬機器。 相反地，裸機的全部資源都專屬於該工作程序，因此您無需擔心「吵鬧的鄰居」會與您共享資源或拖慢效能。 裸機伺服器為您所專用，其所有資源都可供叢集使用。
加密磁碟
依預設，每個工作者節點都會佈建兩個本端 SSD、AES 256 位元加密資料分割區。 第一個分割區包含用來啟動工作者節點且未加密的核心映像檔。 第二個分割區會存放容器檔案系統，並使用 LUKS 加密金鑰解除鎖定。 叢集裡的每一個工作者節點都有由 IBM Cloud Kubernetes Service 所管理的專屬唯一 LUKS 加密金鑰。 當您建立叢集或將工作者節點新增至現有叢集時，會安全地取回金鑰，然後在解除鎖定已加密磁碟之後將金鑰捨棄。 加密可能會影響磁碟 I/O 效能。 對於需要高效能磁碟 I/O 的工作負載，請測試已啟用及停用加密的叢集，以協助您決定是否關閉加密。
專家級 AppArmor 原則
每個工作節點均設定有安全與存取政策，這些政策由 AppArmor 在初始化過程中載入至工作節點的「設定檔」所強制執行。 AppArmor 使用者或電腦擁有者均無法變更這些設定檔。
已停用 SSH
依預設，工作者節點上已停用 SSH 存取，以保護叢集免於惡意攻擊。 停用 SSH 存取時，會透過 Kubernetes API 伺服器強制存取叢集。 在叢集裡執行要求之前，Kubernetes API 伺服器需要針對鑑別、授權及許可控制模組中所設定的原則來檢查每個要求。
如果您擁有一個標準叢集，且希望在工作節點上安裝更多功能，您可以選擇使用 IBM Cloud Kubernetes Service 所提供的附加元件，或是使用 Kubernetes 中的守護程序集（daemon sets），以在每個工作節點上執行您所需的所有功能。 對於任何必須執行的單次操作，請使用「Kubernetes」工作。

網路

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

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

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

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

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

從 Kubernetes 主節點存取工作節點的kubelet，是透過Konnectivity隧道進行安全傳輸的。 如需相關資訊，請參閱 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 跨域功能是否已啟用，請使用 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 位址的網路資料流量。
使用邊緣節點限制公用網際網路連線功能 若未建立啟用閘道的叢集，每個工作節點都會被設定為接受應用程式 Pod 及其相關的負載平衡器或入口 Pod。 您可以將工作者節點標示為邊緣節點，強制只將負載平衡器及 Ingress Pod 部署至這些工作者節點。 此外，您可以 對工作節點設定「受污染」標籤，以確保應用程式 Pod 無法排程至邊緣節點。 使用邊緣節點，您可以將網路工作負載隔離到叢集裡較少數的工作者節點，並將叢集裡的其他工作者節點維持為專用狀態。

如果我想將我的叢集連接到本地資料中心，該怎麼辦？

若要將工 作人員節點和應用程式連接到內部資料中心，您可以設定 Virtual Router Appliance 或 Fortigate Security Appliance。

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

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

預設情況下，我的 VPC 叢集允許哪些網路流量？

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

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

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

預設情況下，安全群組會套用至您的 VPC 實例以及 VPC ALB 和 NLB。 如需詳細資訊，請參閱 瞭解安全預設群集 VPC 網路，以及 建立和管理 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 時，系統會為該 VPC 建立一個格式為 allow-all-network-acl-<VPC_ID> 的預設存取控制清單 (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 叢集的工作者節點存在於服務帳戶中，且未列在 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)，請安裝專為監控您的叢集和容器化應用程式而設計的第三方工具，以偵測入侵或濫用行為，例如 旋轉鎖扣 或 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 Compliance Manager:當您啟用 IBM Cloud Compliance Manager 時，您可以檢視有關可疑傳入和傳出網路流量的報告。 如需更多資訊，請參閱 IBM Cloud Compliance Manager 的文件。

  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) 來控制您的租戶可在叢集中部署哪些資源。
  • 網路政策： 由於您的工作節點連接到同一個私有網路，因此必須確保已實施嚴格的網路政策，以防止 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
您可以將 [securityContext章節](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/){: external} 新增至您的 Pod，以控制可在容器內執行的使用者 ID 和群組 ID，或是控制擁有卷宗掛載路徑的使用者 ID 和群組 ID。 設定特定使用者 ID 有助於促進最少專用權模型。 如果安全環境定義未指定使用者，則 Kubernetes 會自動使用容器映像檔中指定的使用者。
若您想使用 securityContext 來設定 runAsUser 使用者 ID 或 fsGroup 群組 ID，請在建立持久性儲存空間時，考慮使用區塊儲存。 NFS 儲存系統不支援 fsGroup，且 ` `runAsUser 必須在容器層級設定，而非 Pod 層級。
設定容器的 CPU 及記憶體限制
每個容器都需要特定 CPU 及記憶體數量，才能適當地啟動並繼續執行。 您可以為容器或 Pod 設定「Kubernetes」資源請求與資源限制，以限制它們可消耗的 CPU 和記憶體用量。 如果未設定 CPU 及記憶體的限制，而且容器忙碌，則容器會使用所有可用的資源。 這種過高的資源消耗可能會影響工作節點上其他資源不足、無法正常啟動或運作的容器，並使您的工作節點面臨遭受拒絕服務攻擊的風險。
強制執行原則驅動的鑑別
您可以將 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 的版本資訊。