Red Hat OpenShift on IBM Cloud 的安全

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

叢集安全威脅概觀

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

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

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

這些元件包括：

Red Hat OpenShift API 伺服器與 etcd

Red Hat OpenShift API 伺服器與 etcd 資料儲存庫，是您 Red Hat OpenShift 主伺服器上運作的最具敏感性的元件。 您想要防止未獲授權存取這些元件，因為它們會設定並儲存在叢集裡執行的所有資源的配置，包括應用程式的部分安全設定。

Red Hat OpenShift 提供安全控制並限制存取，以保護這些元件並降低攻擊風險。

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

預設情況下，Kubernetes 會要求每個請求必須經過數個階段，才會獲准存取 API 伺服器。

鑑別
驗證已註冊使用者或服務帳戶的身分。
授權
限制已驗證使用者與服務帳戶的權限，以確保他們僅能存取並操作您允許其存取及操作的叢集元件。
許可控制
在請求由 Red Hat OpenShift API 伺服器處理之前，對其進行驗證或修改。 Kubernetes 的許多功能都需要入站控制器才能正常運作。

Red Hat OpenShift on IBM Cloud 採取了哪些措施來保障我的 API 伺服器及 etcd 資料儲存庫的安全？

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

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

請檢閱 Red Hat OpenShift API 伺服器和 etcd的下列安全特性。

完全託管且專用的 Red Hat OpenShift 主伺服器

Red Hat OpenShift on IBM Cloud 中的每個叢集均由專用的 Red Hat OpenShift 主節點控制，該主節點由 IBM 在 IBM 所擁有的 IBM Cloud 帳戶中進行管理。 Red Hat OpenShift 主伺服器已設定以下專用元件，這些元件不會與其他 IBM 客戶共用。

  • etcd 資料儲存庫： 儲存叢集中所有 Kubernetes 資源，例如 Services、Deployments 以及 Pods。 Kubernetes ConfigMaps 及 Secrets 是儲存為鍵值組的應用程式資料，因此，Pod 中執行的應用程式可以使用它們。 etcd 中的資料儲存於 Red Hat OpenShift 主伺服器的本機磁碟上，並備份至 IBM Cloud Object Storage。 資料是在傳送至 IBM Cloud Object Storage 期間和靜止時加密。 您可以透過為叢集執行 [啟用 IBM Key Protect 加密功能](/docs/openshift?topic=openshift-encryption) 指令，選擇在 Red Hat OpenShift 主節點的本地磁碟上為 etcd 資料啟用加密功能。 當 etcd 資料傳送至 Pod 時，會透過 TLS 將資料加密，以確保資料保護及完整性。
  • openshift-api： 作為工作節點向 Red Hat OpenShift 主節點發送所有叢集管理請求的主要入口點。 API 伺服器會驗證並處理會變更叢集資源（例如，Pod 或服務）狀況的要求，並將此狀況儲存在 etcd 資料儲存庫中。
  • openshift-controller： 監控新建立的 Pod，並根據容量、效能需求、政策限制、反親和性規範及工作負載需求，決定將其部署至何處。 如果找不到符合需求的工作者節點，則不會在叢集裡部署 Pod。 控制器還會監視叢集資源（例如，抄本集）的狀態。 當資源的狀況變更時，例如，若抄本集中的 Pod 關閉，則控制器管理程式會起始更正動作以達到所需的狀況。
  • cloud-controller-manager： 雲端控制器管理員負責管理雲端供應商專屬的元件，例如 IBM Cloud 負載平衡器。
  • Konnectivity： Red Hat OpenShift on IBM Cloud 專用元件，用於為所有 Red Hat OpenShift 主節點與工作節點之間的通訊提供安全的網路連線。 Konnectivity 伺服器會與 Konnectivity 代理程式協同運作，以安全的方式將主節點與工作節點連接起來。 此連線支援針對您的 Pod 和服務發送的 apiserver proxy 請求，以及針對 kubelet 發送的 oc exec、attach 和 logs 請求。 從工作者節點到主節點的連線會自動使用 TLS 憑證保護。
由 IBM Site Reliability Engineer (SRE) 持續監視

Red Hat OpenShift 主節點（包含所有主節點元件、運算、網路及儲存資源）均由 IBM 的網站可靠性工程師（SRE）進行持續監控。 SRE 會套用最新的安全標準、偵測並重新修補惡意活動，並且努力確保 Red Hat OpenShift on IBM Cloud 的可靠性及可用性。

CIS Kubernetes 主節點基準

為了配置 Red Hat OpenShift on IBM Cloud，IBM 的工程師遵循由 網際網路安全中心（ CIS ） 發布的《 Kubernetes 》主基準中相關的網路安全實務。 叢集主節點及所有工作者節點都會部署符合基準性能測試的映像檔。

透過 TLS 的安全通訊

若要使用 Red Hat OpenShift on IBM Cloud，您必須使用認證向服務進行鑑別。 當您完成身份驗證後，Red Hat OpenShift on IBM Cloud 會產生 TLS 憑證，用以加密與 Red Hat OpenShift API 伺服器及 etcd 資料儲存庫之間的通訊，以確保工作節點與 Red Hat OpenShift 主節點之間具備安全的端對端通訊。 這些憑證絕不會在不同叢集之間，或不同 Red Hat OpenShift 主節點元件之間共用。

與工作者節點的連線功能

雖然 Kubernetes 透過 https 協定來確保主節點與工作節點之間的通訊安全，但預設情況下，工作節點並未提供任何驗證機制。 為了確保此通訊的安全性，當叢集建立時，Red Hat OpenShift on IBM Cloud 會自動在 Red Hat OpenShift 主節點與工作節點之間建立 Konnectivity 連線。

精細存取控制

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

  • 平台存取角色： 決定使用者在 Red Hat OpenShift on IBM Cloud 中可執行的、與叢集及工作節點管理相關的操作。 平台存取角色還會將「basic-users」和「self-provisioners」RBAC 角色指派給使用者。 透過這些 RBAC 角色，您可以在叢集中建立一個 Red Hat OpenShift 專案，並在其中部署應用程式及其他 Kubernetes 資源。 作為專案的建立者，您會自動指派有對該專案的 admin RBAC 角色，因此您可以完全控制要在專案中部署和執行的項目。 然而，這些 RBAC 角色並不會授予存取其他 Red Hat OpenShift 專案的權限。 若要檢視及存取其他 Red Hat OpenShift 專案，您必須在 IAM 中被指派適當的服務存取角色。
  • 服務存取角色： 確定指派給該使用者的「Kubernetes」RBAC 角色，以及該使用者可對 Red Hat OpenShift API 伺服器執行的操作。 雖然透過平台存取角色指派的 basic-users 和 self-provisioners RBAC 角色，可讓您建立和管理自己的 Red Hat OpenShift 專案，但在被指派服務存取角色之前，您無法檢視、存取或操作其他 Red Hat OpenShift 專案。 如需進一步了解指派給使用者的對應 RBAC 角色及其相關權限，請參閱 IAM 服務存取角色。
  • 傳統基礎架構： 可讓您存取傳統基礎架構資源。 標準基礎架構角色所允許的動作範例，包括檢視叢集工作者節點機器的詳細資料，或編輯網路及儲存空間資源。
  • VPC 基礎架構： 可存取 VPC 基礎架構資源。 VPC 基礎架構角色所允許的動作範例，包括建立 VPC、新增子網路、變更浮動 IP 位址，及建立 VPC Block Storage 實例。

如需瞭解有關叢集存取控制的更多資訊，請參閱「指派叢集存取權限」。

許可控制器

許可控制器是針對 Kubernetes 及 Red Hat OpenShift on IBM Cloud 中的特定特性而實作。 使用許可控制器，您可以在叢集裡設定原則，以判定是否允許叢集裡的特定動作。 在該政策中，您可以指定在哪些情況下使用者無法執行某項操作，即使該操作屬於您透過 RBAC 角色指派給該使用者的一般權限範圍內。 因此，在 API 請求由 Red Hat OpenShift API 伺服器處理之前，存取控制器可為您的叢集提供額外的安全防護層。

當您建立叢集時，Red Hat OpenShift on IBM Cloud 系統會自動以特定順序在主節 Red Hat OpenShift 點安裝預設的 Kubernetes 准入控制器，此順序無法由使用者變更。 請參 閱元件參考資訊 中，依叢集版本檢視預設存取控制器的排序順序。

您可以 在叢集裡安裝自己的許可控制器，或選擇選用的許可控制器，例如 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 元件套用最新的安全更新及修補程式。

如需相關資訊，請參閱使用 Red Hat OpenShift on IBM Cloud 的責任。

請定期（例如每月）使用 ibmcloud oc worker update 指令，將更新與安全性修補程式部署至作業系統，並更新工作節點所執行的 Red Hat OpenShift 版本。 當有更新可用時，您在 IBM Cloud 控制台或命令列介面（CLI）中檢視主節點和工作節點的資訊時，系統會通知您，例如使用 ibmcloud oc clusters ls 或 ibmcloud oc workers ls --cluster CLUSTER_NAME 指令時。 IBM 會以包含最新安全修補程式的完整工作者節點映像檔形式，提供工作者節點更新。 若要套用更新，必須使用新的映像檔來重新映像化及重新載入工作者節點。 重新載入工作者節點時，會自動替換 root 使用者的金鑰。

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

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

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

Red Hat OpenShift on IBM Cloud 中的工作節點設定（不含網路安全性）。中的工作節點設定 中的工作節點設定（不含網路安全性）
Red Hat OpenShift on IBM Cloud

CIS-符合規範的影像
每個工作節點均安裝了可執行由「網際網路安全中心」（ CIS ）所發布之基準測試的作業系統。 機器的使用者或擁有者無法將此作業系統變更為另一個作業系統。 若要查看當前的作業系統版本，請執行 oc get nodes -o wide。 IBM 與內部及外部安全顧問團隊合作，解決潛在的安全規範漏洞。 作業系統的安全更新和修補程式是透過 Red Hat OpenShift on IBM Cloud 所提供，並且必須由使用者安裝，才能確保工作者節點的安全。

Red Hat OpenShift on IBM Cloud 使用一個 Linux 核心作為工作節點。 您可以根據 Red Hat OpenShift on IBM Cloud 中的任何 Linux 發行套件，來執行容器。 請向您的容器映像供應商確認，您的容器映像能否在該核心上運行。

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

網路

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

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

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

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

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

從 Red Hat OpenShift 主節點存取工作節點的kubelet，是透過Konnectivity隧道進行安全保護的。 如需相關資訊，請參閱 Red Hat OpenShift on IBM Cloud 架構。

什麼是網路分段？我該如何為 Classic 叢集設定此功能？

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

Red Hat OpenShift on IBM Cloud 提供了 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 oc vlan spanning get --region <region> 指令。

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

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

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

除了這些措施之外，我還能做些什麼來減少 Classic 叢集遭受外部攻擊的攻擊面？

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

專用服務及工作者節點選項
安全特性 說明
限制已公開的應用程式數目 依預設，無法透過公用網際網路呼叫到叢集內執行的應用程式及服務。 您可以選擇要將應用程式公開給大眾使用，還是想要讓應用程式及服務只能在專用網路上聯繫。 當您將應用程式及服務維持為專用狀態時，可以運用內建安全特性，來確保工作者節點與 Pod 之間的安全通訊。 若要將服務和應用程式對外公開至公共網際網路，您可以使用 Red Hat OpenShift 路由，或善用 NLB 及 Ingress ALB 的支援功能，以安全的方式讓您的服務對外公開。 確保僅公開必要的服務，並定期重新檢視已公開應用程式的清單，以確保這些應用程式仍然有效。
使用邊緣節點限制公用網際網路連線功能 每個工作者節點都會配置為接受應用程式 Pod 及關聯的負載平衡器或 Ingress Pod。 您可以將工作節點標記為 邊節點，以強制將負載平衡器 Pod 僅部署至這些工作節點。 此外，您可以 對工作節點設定「受污染」標籤，以確保應用程式 Pod 無法排程至邊緣節點。 使用邊緣節點，您可以將網路工作負載隔離到叢集裡較少數的工作者節點，並將叢集裡的其他工作者節點維持為專用狀態。

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

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

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

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

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

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

若要存取預設 Red Hat OpenShift 元件 (例如 Web 主控台或 OperatorHub )，而不連接至 VPC 的專用網路，您必須將 公用閘道 連接至工作者節點部署至其中的 VPC 子網路。 對於連接有為公用閘道的子網路上的工作者節點，允許其所有流出流量，但仍會封鎖所有流入流量。

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

預設情況下，安全群組會套用至您的 VPC 實例以及 VPC ALB 和 NLB。 如需詳細資訊，請參閱 瞭解安全預設群集 VPC 網路，以及 建立和管理 VPC 安全群組。

何謂網路分段？該如何為 VPC 叢集設定網路分段？

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

Red Hat OpenShift on IBM Cloud 提供 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 需要連接至公用外部端點，則可以將公用閘道連接至這些工作者節點所在的子網路。

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

透過路由安全地公開應用程式

若要允許來自網際網路的傳入網路流量，您可以透過 路由功能將應用程式對外開放。

每個 Red Hat OpenShift 叢集都會自動設定一個 Red Hat OpenShift 路由器，該路由器會被指派一個唯一的網域名稱，並透過 TLS 憑證進行加密保護。 當您透過路由公開應用程式時，系統會從 Red Hat OpenShift 路由器為您的應用程式指派一個 URL。

為應用程式建立路徑時，可以決定是建立安全 (HTTPS) 還是不安全 (HTTP) 路徑。 對於安全路徑，可以決定要在哪裡實作 TLS 終止，例如在路由器或 Pod 上。 如需相關資訊，請參閱使用路徑公開應用程式。

透過 LoadBalancer 和Ingress服務安全地公開應用程式

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

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

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

VPC 叢集：VPC 安全群組會套用至單一虛擬伺服器的網路介面，以在超管理程式層級過濾流量。 您可以將入埠及出埠規則新增至叢集的預設安全群組，以管理 VPC 叢集的入埠及出埠資料流量。 如需詳細資訊，請參閱 瞭解安全預設群集 VPC 網路，以及 建立和管理 VPC 安全群組。

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

該如何透過 LoadBalancer 和 Ingress 服務來執行 TLS 的終止處理？

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

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

持續性儲存空間

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

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

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

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

監視及記載

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

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

若要存取群集元件的日誌，請設定 IBM Cloud LogsIBM Cloud Logs 可存取您的所有日誌，而且您可以彙集日誌，並跨多個群集建立您自己的客製化檢視。

我該如何監控叢集的運作狀態和效能？
您可以從 Red Hat OpenShift on IBM Cloud 主控台或 CLI 監視叢集元件及運算資源（例如 CPU 及記憶體用量），來驗證應用程式、服務及工作者節點的性能、容量及效能。 若要檢視叢集的更深入指標，您可以使用基於開源技術的內建監控功能，例如 Prometheus。 建立叢集時會自動安裝 Prometheus，您可以使用該工具來存取即時叢集和應用程式度量值。 Prometheus 度量值不會持續存在。 若要檢視歷史指標，並比較多個叢集之間的指標，請改用 IBM Cloud Monitoring。

若要設定基於主機的入侵偵測系統 (HIDS) 及安全事件日誌監控 (SELM)，請安裝專為監控您的叢集和容器化應用程式而設計的第三方工具，以偵測入侵或濫用行為，例如 旋轉鎖扣 或 Sysdig「Falco」專案。

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

部署包含可信內容的容器。
部署包含可信內容的容器

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

  2. 容器映像安全強制執行：使用具備自訂政策（custom policies）的准入控制器，以便在部署容器映像前進行驗證。 使用容器映像檔安全強制執行專案 (例如 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。

儲存器執行時期

您的工作節點已安裝 作為 CRI-O 容器運行時介面，該介面受 安全強化 Linux(SELinux) 標籤系統保護。

當您使用 Kubernetes 與容器影像互動（例如建立 Pod）時，kubelet 會透過 UNIX 套接字 crio.sock 與 CRI-O 進行通訊。 UNIX 套接字使用下表中的 SELinux 標籤來強制執行適當的系統存取政策。 這些標籤使使用者儲存器無法存取儲存器執行時期 Socket。

用來保護儲存器執行時期處理程序的 SELinux 標籤。
處理程序 SELinux 標籤
CRI-O system_u:system_r:container_runtime_t:s0
kubelet system_u:system_r:unconfined_service_t:s0
crio.sock system_u:object_r:container_var_run_t:s0
儲存器處理程序，例如 c14 system_u:system_r:container_t:s0:c14

要求流程範例

下圖呈現 kubelet 與 CRI-O之間的要求流程範例。

kubelet 與 CRI-O 之間的請求流程範例。
kubelet 與 CRI-O

映像檔及登錄

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

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

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

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

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

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

可以使用內建容器登錄來自動化從外部來源儲存庫中的原始碼到內部登錄的容器映像檔建置程序。 但是，將映像檔推送到內部登錄時，不會自動掃描映像檔是否有漏洞。 若要設定映像檔掃描，請改為設定登錄名稱空間，然後將映像檔推送到受管理的 IBM Cloud Container Registry。

映像檔及部署的安全
安全特性 說明
在 Docker 安全私有映像庫中 IBM Cloud Container Registry 在由託管與管理的 IBM、具備多租戶、高可用性及可擴展性的私有映像註冊表中建立專屬 Docker映像庫。 透過使用註冊表，您可在叢集使用者間建立、安全儲存及共享 Docker 映像檔。/n 瞭解如何在處理容器映像檔時 保護個人資訊安全。
僅推送具有受信任內容的映像檔 透過在映像檔儲存庫中啟用 內容信任 來確保映像檔的完整性。 使用受信任內容，您可以控制誰能將映像檔簽署為受信任映像檔，並將映像檔推送至特定登錄名稱空間。 當受信任的簽署者將映像推送到註冊表命名空間後，使用者即可拉取該簽署內容，藉此驗證發行者身分及映像的完整性。
自動漏洞掃描 當您使用 IBM Cloud Container Registry 時，可運用由內建 Vulnerability Advisor 的安全掃描功能。 會自動掃描每個推送至您登錄名稱空間的映像檔，以對照已知 CentOS、Debian、Red Hat 及 Ubuntu 問題的資料庫來掃描漏洞。 若發現漏洞，Vulnerability Advisor 提供了相關解決步驟，以確保映像檔的完整性與安全性。
封鎖來自有漏洞映像檔或未授信使用者的部署 建立具有自訂原則的許可控制器，以便您可以在部署它們之前驗證容器映像檔。 透過此 開源 Portieris 專案，您可掌控圖像的部署來源，並確保其符合內容信任要求。 如果某個部署不符合您設定的政策，准入控制器會阻止該部署進入您的叢集。
我有哪些選項可以對正在運行的容器進行漏洞掃描？
您可以在叢集裡安裝協力廠商解決方案，例如 Twistlock 或 StackRox，以掃描執行中的容器，並在偵測到惡意活動時封鎖它們。

容器隔離及安全

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

什麼是「Red Hat OpenShift」專案？我為什麼要使用它？
Red Hat OpenShift 專案是一種將叢集進行虛擬分割的方式，可為您的部署以及希望將工作負載移至該叢集的使用者群組提供隔離機制。 透過專案，可以跨工作者節點以及跨多區域叢集裡的區域組織資源。
每個叢集都會預先設定一組預設的 Red Hat OpenShift 專案，其中包含 Red Hat OpenShift on IBM Cloud 正常運作及管理叢集所需的部署與服務。 如需相關資訊，請參閱服務架構。
叢集管理者自動有權存取這些專案，並可以在叢集裡設定其他專案。 此外，被授與叢集存取權的叢集使用者可以建立自己的專案，並且作為專案的建立者，可以使用管理者許可權來管理該專案。 然而，預設情況下，叢集使用者無法存取其他專案，除非獲得叢集管理員授予存取權限。

對於叢集中的每個專案，請務必設定適當的 RBAC 政策， 以限制對該專案的存取權限、控制部署的內容，並設定適當的 資源配額與限制範圍。

我應該建立單租戶還是多租戶叢集？

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

在單租戶與多租戶叢集之間做出抉擇。
單租戶與多租戶叢集的比較

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

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

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

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

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

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

該如何管理 Pod 的權限？
若要控制專案內或跨專案的 Pod 許可權，Red Hat OpenShift on IBM Cloud 會使用安全環境定義限制 (SCC)。 預設情況下，每個叢集都會設定 Red Hat OpenShift SCCs，並包含一組 IBM-提供的標準合同條款（SCCs），您可以將這些 指派給服務帳戶、Pod、部署或專案，以限制叢集內的權限。 如果您未明確指派 SCC，則 Pod 會使用 restricted SCC。Red Hat OpenShift SCC 比社群 Kubernetes 叢集裡的預設 Pod 安全原則更嚴格。 您可能需要修改在社群版 Kubernetes 叢集中運行的應用程式，以便該應用程式能在 Red Hat OpenShift 上運行。 如需相關資訊，請參閱配置安全環境定義限制。
我還能做些什麼來保護我的容器呢？
限制具有特權的容器數量。 容器會在與其他處理程序隔離的運算主機上，以個別的 Linux 處理程序形式執行。 雖然使用者在容器內部有 root 存取權，但是會限制此使用者在容器以外的許可權，以保護其他 Linux 處理程序、主機檔案系統及主機裝置。 部分應用程式需要存取主機檔案系統或進階許可權，才能正常執行。 您可以使用特許模式來執行容器，以允許容器具有與運算主機上執行之處理程序相同的存取權。
請謹記，特許容器若遭到洩漏，可能會對叢集和基礎運算主機造成重大損壞。 請嘗試限制以特許模式執行的容器數目，並考慮變更應用程式的配置，讓應用程式可以在沒有進階許可權的情況下執行。

如果要封鎖特許容器在叢集裡執行，請考慮設定自訂安全環境定義限制。

將 OS 安全設定套用至 Pod
您可以自訂 預設的安全性上下文限制， 以控制可在容器內執行的使用者 ID 和群組 ID，或是擁有卷宗掛載路徑的使用者 ID 和群組 ID。 設定特定使用者 ID 有助於促進最少專用權模型。 若安全性上下文未指定使用者 Kubernetes，則自動採用容器映像中指定的使用者。 如需相關資訊，請參閱配置安全環境定義限制。
設定容器的 CPU 及記憶體限制
每個容器都需要特定 CPU 及記憶體數量，才能適當地啟動並繼續執行。 您可以為容器或 Pod 定義限制範圍，以限制它們可消耗的 CPU 和記憶體量。 如果未設定 CPU 及記憶體的限制，而且容器忙碌，則容器會使用所有可用的資源。 這種過高的資源消耗可能會影響工作節點上其他資源不足、無法正常啟動或運行的容器，並使您的工作節點面臨遭受拒絕服務攻擊的風險。

儲存個人資訊

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

使用 Kubernetes 密碼儲存個人資訊

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

要集中管理跨叢集的所有機密，並在應用程式執行時進行注入，請嘗試使用 IBM Cloud Secrets Manager.

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

請不要將個人資訊儲存在容器映像檔或登錄名稱空間中。 為了確保妥善的保護與加密，請將登錄檔憑證 Kubernetes imagePullSecrets，而其他個人資訊則應儲存於 機密中。 請記住，如果個人資訊儲存在映像檔的上一層中，則刪除映像檔可能不足以刪除此個人資訊。

Kubernetes 安全性公告

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

某些 CVE 需要針對 Red Hat OpenShift 版本安裝最新的修補程式更新，您可透過 Red Hat OpenShift on IBM Cloud 中的例行 叢集更新流程 進行安裝。 請務必及時套用安全修補程式，以保護叢集不受惡意攻擊。 如需進一步了解安全性修補程式包含的內容，請參閱 Red Hat OpenShift on IBM Cloud 的版本資訊。