chundev
日期：2026-06-30 技術棧：Red Hat OpenShift 4.x、ACS 4.9、Quay 3.x、NVIDIA H200 GPU
Air-gapped OpenShift 叢集承載多廠商 AI 工作負載時，「廠商用硬碟帶 image 進來直接跑」的模式會在規模擴大後失控。六層資安治理架構涵蓋 OpenShift 原生能力（RBAC、Namespace、NetworkPolicy）和 Red Hat 安全產品線（ACS、Quay、Compliance Operator），目標是讓 A 級機關通過資安法稽核。核心原則——管不了 container 裡面放什麼，但管得了 container 能碰到什麼。
場景：一個擁有 air-gapped OpenShift 叢集和 NVIDIA H200 GPU 的 A 級機關，各業務單位找不同廠商開發 AI 應用。平台由 B 廠商建置維運，C、D、E 廠商各自開發完後用硬碟把 container image 帶進來，B 廠商的工程師幫忙把 container 跑起來——沒有 image 掃描、沒有准入控制、沒有操作紀錄、沒有任何治理機制。
合規要求：資通安全管理法 A 級 + ISO 27001。A 級是最高等級，對委外管理、稽核軌跡、弱點掃描都有明確的應辦事項。
驅動力不是已經出事，而是預見「現在兩三個廠商還行，以後十幾個就亂了」加上合規壓力。SI 的角色是提前佈局，設計一套治理框架。
廠商 C（開發 AI 應用）
│
│ 硬碟帶 image
▼
B 廠商工程師
│
│ podman load → oc apply
▼
OpenShift GPU Node (H200)
│
│ 沒有掃描 ✕
│ 沒有准入控制 ✕
│ 沒有操作紀錄 ✕
│ 沒有網路隔離 ✕
▼
直接跑起來
四個具體風險：
OpenShift 就是 Kubernetes 的企業發行版，底層 API 完全一樣。
┌─────────────────────────────────────────┐
│ OpenShift API Server │
│ （就是 Kubernetes API + 擴充） │
└──────┬──────────────┬──────────┬────────┘
│ │ │
┌────┴────┐ ┌─────┴────┐ ┌─┴──────────┐
│ kubectl │ │ oc CLI │ │ Web Console │
│（完全能用）│ │（kubectl │ │ （GUI） │
│ │ │ 的超集） │ │ │
└─────────┘ └──────────┘ └─────────────┘
kubectl get pods、kubectl apply -f、kubectl logs 全部照用。oc CLI 包含 kubectl 的所有功能再加上 OpenShift 特有操作（oc login、oc new-project、oc image mirror）。Web Console 可以直接管 RBAC、裝 Operator、開 terminal 進 Pod。
對治理的意義： 不管廠商用哪種工具操作，全部打同一個 API Server。治理機制只要設在 API 層（RBAC + Admission Controller），所有操作方式都會被涵蓋。
這是跟原生 K8s 最大的差異之一。
| 原生 Kubernetes | OpenShift |
|---|---|
| 手動建 ServiceAccount | 建 User 帳號（GUI 或 oc create user） |
| 手動綁 RoleBinding | GUI 上 User Management → RoleBindings 點一點 |
| 手動拼 kubeconfig 發給人 | 對方 oc login 輸入帳密就好 |
| 想看誰有什麼權限要下指令查 | GUI 上 User Management 一目瞭然 |
身分來源可以接：
對治理的意義： 每個廠商工程師有自己的帳號，所有操作自動綁定身分。不再是「不知道是誰在操作」。
OpenShift 把 Namespace 包裝成 “Project”，加了一些額外功能（預設的 LimitRange、ResourceQuota 模板等），但底層就是 Kubernetes Namespace。
以下誤解如果不糾正，會導致治理框架留下盲區。
| 誤解 | 實際情況 | 為什麼會搞混 |
|---|---|---|
| ❌ Namespace 隔開 = 網路也隔開 | ⚠️ 錯！OpenShift 預設 namespace 之間網路是通的。 廠商 C 的 Pod 可以直接連到廠商 D 的 Pod，只要知道 Service name 或 IP。要真的隔開需要額外設 NetworkPolicy | 因為 Namespace 在 RBAC 層面確實是隔離的（看不到對方的資源），直覺會以為網路也隔離了 |
| ❌ Image 掃過沒問題 = 跑起來也沒問題 | ⚠️ Image 掃描只檢查靜態內容（已知 CVE、惡意檔案）。Container 跑起來後的動態行為（異常程序、權限提升、挖礦）需要 runtime 監控才抓得到 | 因為「掃描」聽起來像是全面檢查，但實際上只覆蓋部署前的靜態分析 |
| ❌ Air-gapped = 不會有資安問題 | ⚠️ Air-gapped 降低了外部入侵和資料外洩的風險，但內部威脅完全沒有減少 — 惡意 image、權限濫用、廠商之間互相干擾，全部在內網發生 | 因為 air-gapped 直覺上感覺很安全（「都斷網了還能怎樣」） |
| ❌ 問客戶「你們 OpenShift 是什麼版本」就能知道訂閱層級 | ⚠️ 客戶會回答 “4.16”（軟體版本），不是訂閱層級。訂閱層級是商業合約層面的東西（Container Platform vs Platform Plus），不會顯示在叢集裡 | 因為在其他產品中「版本」通常就代表功能等級 |
| ❌ Namespace 隔離就夠了，不需要其他治理 | ⚠️ Namespace 擋不住：image 裡的漏洞、root 權限逃逸、夾帶惡意程式、資料外帶。需要六層完整治理 | 因為 Namespace 已經做到 RBAC 隔離和資源配額，看起來「已經很安全了」 |
在 OpenShift（使用 OVN-Kubernetes CNI）中，預設所有 Namespace 之間的 Pod 網路是完全互通的。
要做到 Namespace 間的網路隔離，需要手動建立 NetworkPolicy。最基本的 deny-all 範本：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all-ingress
namespace: vendor-c
spec:
podSelector: {}
policyTypes:
- Ingress
ingress: []
這會阻擋所有進入 vendor-c namespace 的流量。然後再用白名單開放需要的連線（例如 Ingress Controller 進來的流量）。
六層的設計邏輯：從外到內、從靜態到動態、從預防到偵測。
┌─────────────────────────────────────────────────┐
│ L1 帳號與權限 誰能進來操作？ │
├─────────────────────────────────────────────────┤
│ L2 廠商隔離 各廠商互相看不到、碰不到 │
├─────────────────────────────────────────────────┤
│ L3 Image 掃描 進來的東西先檢查 │
├─────────────────────────────────────────────────┤
│ L4 准入控制 不合規的東西不准跑 │
├─────────────────────────────────────────────────┤
│ L5 Runtime 監控 跑起來後持續盯 │
├─────────────────────────────────────────────────┤
│ L6 合規稽核 所有事留紀錄、產報告 │
└─────────────────────────────────────────────────┘
做什麼： 每個廠商工程師有自己的帳號，只能操作被授權的 Namespace。
用什麼： OpenShift 原生 RBAC + OAuth 認證系統。免費，所有訂閱層級都有。
實作重點：
view（只看）、edit（可部署）、admin（Namespace 管理者）資安法對應： 委外廠商存取範圍管控、最小權限原則。
做什麼： 每個業務單位一個 Namespace，廠商只是被授權來操作的人。Namespace 間網路隔離。
用什麼： OpenShift 原生功能。免費。
設計決策 — 按業務單位切，不是按廠商切：
| 切法 | 優點 | 缺點 |
|---|---|---|
| 按廠商切 | 簡單直覺 | 廠商會換，Namespace 跟著亂 |
| ✅ 按業務單位切 | 業務單位穩定，廠商只是操作者 | 需要管理廠商的權限指派 |
實作重點：
nvidia.com/gpu resource request 分配做什麼： 所有 container image 必須先進入內部 Quay Registry，自動觸發 Clair 掃描。
用什麼： Red Hat Quay（私有 registry）+ 內建 Clair 掃描引擎。Platform Plus 包含，否則加購。
Quay 的角色：
podman load 後就跑，必須先推進 QuayAir-gapped 部署：
做什麼： 在 Kubernetes API 層攔截部署請求，不合規的 image 直接擋掉，連部署都不讓發生。
用什麼： Red Hat ACS (Advanced Cluster Security) 的 Admission Controller。Platform Plus 包含，否則加購。
這是治理的核心機制。 運作原理是在 OpenShift API Server 註冊為 ValidatingAdmissionWebhook——每當有人嘗試建立 Deployment / Pod / DaemonSet 等工作負載，API Server 會先把請求發給 ACS 檢查，ACS 根據預設的 Policy 決定放行或擋掉。
任何操作方式
│
▼
OpenShift API Server
│
│ → ValidatingAdmissionWebhook → ACS
│ │
│ 合規？ │
│ ✓ 放行 │
│ ✕ 拒絕 │
│ ←────────────────────────────────┘
▼
執行部署（或回傳錯誤）
可以設定的 Policy 範例：
設計原則： 不依賴人的自律，用平台層技術強制。廠商的工程師可能忘記掃描、可能偷懶、可能不知道有漏洞——都不重要，因為 Admission Controller 在 API 層就把關了。
ACS vs Clair 掃描深度比較：
| 掃描項目 | Clair (Quay 內建) | ACS |
|---|---|---|
| 已知 CVE 漏洞 | ✅ | ✅ |
| Image 內含的 Secret / 密碼 | ✕ | ✅ |
| 危險套件偵測（crypto miner 等） | ✕ | ✅ |
| Dockerfile 最佳實踐檢查 | ✕ | ✅ |
| 執行身分（root?）檢查 | ✕ | ✅ |
| 元件清單（SBOM 等級） | 部分 | ✅ |
Quay + Clair 是第一道濾網（已知 CVE），ACS 是第二道（更深入的安全分析 + 准入控制的強制力）。兩者搭配使用，不是二選一。
ACS 的架構組件：
┌─────────────────────────────────────┐
│ Central（管理平面） │
│ ├── API Server + Dashboard │
│ ├── Scanner（image 掃描引擎） │
│ └── Policy Engine │
├─────────────────────────────────────┤
│ Secured Cluster（每個被管理的叢集） │
│ ├── Sensor（收集叢集資訊） │
│ ├── Collector（節點層級資料收集） │
│ └── Admission Controller │
│ （ValidatingAdmissionWebhook） │
└─────────────────────────────────────┘
Central 可以管理多個叢集，但在單叢集的場景下，Central 和 Secured Cluster 組件跑在同一個 OpenShift 叢集上。
做什麼： Container 跑起來之後，持續監控內部行為，偵測異常。
用什麼： ACS 的 Runtime Monitoring 功能。已包含在 ACS 中。
偵測項目：
/etc/shadow）為什麼需要這一層： Image 掃描只能檢查已知的靜態內容。如果一個 image 在部署時是乾淨的，但跑起來後從內部下載了惡意程式（即使在 air-gapped 環境，如果 image 裡預埋了惡意邏輯，也可能在 cluster 內部造成損害），runtime 監控才抓得到。
做什麼： 自動掃描叢集合規狀態、產出報告、監控檔案完整性。
用什麼：
| 工具 | 功能 | 費用 |
|---|---|---|
| Compliance Operator | 自動掃描叢集是否符合 CIS Benchmark、NIST 等標準 | 免費（所有 OCP 訂閱都有） |
| ACS 合規報告 | 跨叢集合規狀態視覺化（CIS、NIST、PCI DSS、HIPAA） | 包含在 ACS 中 |
| File Integrity Operator | 持續監控節點上的檔案是否被竄改（基於 AIDE） | 免費（所有 OCP 訂閱都有） |
資安法 A 級應辦事項 ↔ 治理架構對照：
| 應辦事項 | 具體要求 | 六層架構對應 |
|---|---|---|
| 委外廠商管理 | 管控廠商存取範圍、資格審查 | L1 RBAC（限制操作範圍）+ L2 Namespace 隔離 |
| 弱點掃描 | 定期掃描系統漏洞 | L3 Quay/Clair 自動掃描 + L4 ACS 深度掃描 |
| 資安威脅偵測 | 偵測異常行為 | L5 ACS Runtime 監控 |
| 稽核軌跡 | 所有操作可追溯 | OpenShift Audit Log + ACS 操作紀錄 |
| 資安事件通報 | 發現事件後通報 | ACS 告警機制 + File Integrity Operator |
| 定期稽核 | 產出合規報告 | L6 Compliance Operator（CIS Benchmark） |
| 滲透測試 | 定期執行 | 需另外安排（不在本框架範圍內） |
ISO 27001 對應的控制項：
┌─────────────────────────────────────────────────────────┐
│ 所有 OCP 訂閱都有（免費） │
│ │
│ ├── RBAC / Namespace / NetworkPolicy （平台原生） │
│ ├── Compliance Operator （合規掃描） │
│ └── File Integrity Operator （檔案完整性） │
│ │
├─────────────────────────────────────────────────────────┤
│ Platform Plus 包含（或可單獨加購） │
│ │
│ ├── ACS (Advanced Cluster Security) │
│ │ 原 StackRox，2021 年被 Red Hat 收購 │
│ │ 2022 年開源（StackRox 社群版） │
│ │ 功能：Image 掃描、准入控制、Runtime 監控、合規報告 │
│ │ │
│ ├── Quay （私有 Container Registry + Clair 掃描） │
│ │ │
│ └── RHACM (Advanced Cluster Management) │
│ 多叢集管理，本場景暫不需要 │
│ │
├─────────────────────────────────────────────────────────┤
│ 獨立加購 │
│ │
│ ├── OpenShift AI （模型治理、MLOps，未來擴展用） │
│ └── Trusted Software Supply Chain │
│ （Image 簽章、SBOM、供應鏈安全） │
└─────────────────────────────────────────────────────────┘
| 層級 | 定位 | ACS | Quay |
|---|---|---|---|
| Virtualization Engine | VM 專用，最底層 | ✕ | ✕ |
| Kubernetes Engine | 基礎容器平台 | ✕ | ✕ |
| Container Platform | 最常見，完整開發者工具 | ✕ | ✕ |
| Platform Plus | 最高層 | ✅ 包含 | ✅ 包含 |
層級是累加制 — 買 Platform Plus 就包含以下所有層級的功能。問客戶「你們是 Container Platform 還是 Platform Plus」就能判斷 ACS 和 Quay 是否已包含。
訂閱方式： Red Hat OpenShift 的訂閱通常是 per-core 或 per-socket（依部署方式和合約而定），不公開具體價格，需要聯繫 Red Hat 業務或經銷商報價。
| 產品 | 說明 | 費用 |
|---|---|---|
| GPU Operator | GPU 驅動和 runtime 的自動化管理 | 免費（社群版） |
| GPU Operator Government-Ready | 符合 FedRAMP 等政府安全要求 | 需 NVIDIA AI Enterprise 授權 |
| Confidential Containers + GPU | 硬體層級保護 container 內容 | 較新，目前太前沿 |
| 方案 | 支援窗口 | 適合場景 |
|---|---|---|
| ✅ 全 Red Hat | 全部找 Red Hat 一個窗口 | A 級機關、需要原廠支援保證 |
| Red Hat + Falco (CNCF) | Red Hat + 社群自維護 | 技術能力強的團隊，想要更深的 runtime 偵測 |
| Red Hat + NeuVector (SUSE) | Red Hat + SUSE | 已有 NeuVector 經驗的團隊 |
| 純開源（StackRox 社群版 + Trivy + Falco） | 沒有原廠支援 | 預算有限、技術能力強、非政府機關 |
選擇 Red Hat 全家桶的理由：
Clair 和 ACS 的漏洞掃描依賴漏洞資料庫（CVE 定義）。在有網路的環境自動更新不是問題，但 air-gapped 環境需要手動搬運更新：
clairctl（Clair 離線更新）、ACS 有自己的離線 bundle 機制podman load + oc apply 跳過 Quay，所有掃描機制等於不存在ACS、Quay、Compliance Operator 本身的安裝也需要 container image。在 air-gapped 環境，這些 Operator 的 image 也要先 mirror 進來：
oc-mirror v2（OpenShift 官方的 image mirror 工具）oc-mirror，把需要的 Operator image 打包，再搬進 air-gapped 環境NVIDIA GPU Operator 在 OpenShift 上需要特殊的 Security Context Constraints (SCC)。v25.3+ 已改用 namespace-scoped role 取代 cluster role，但較舊版本可能需要 privileged SCC——這與資安治理的最小權限原則衝突。確認 GPU Operator 版本，必要時升級。
技術上可以一次部署全部，但實際考量：
階段一（1-2 週） 階段二（4-8 週） 階段三（2-4 週）
━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━
L1 RBAC 帳號管理 L3 Quay 部署 + L6 Compliance
每個廠商自己的帳號 統一 Image 入口 Operator 掃描
綁定到對應 Namespace Clair 自動掃描
ACS 合規報告
L2 Namespace 隔離 L4 ACS 准入控制
NetworkPolicy deny-all Policy 設定 File Integrity
ResourceQuota GPU 配額 不合規 Image 擋掉 Operator
L5 ACS Runtime
異常行為監控
─────────────────────────────────────────────────────────────────
費用：免費 費用：Platform Plus 費用：免費
或加購 ACS + Quay （前提是階段二已完成）
效果：門禁 + 隔間 效果：安檢 + 監控 效果：稽核護身符
為什麼這個順序：
每個階段獨立有效 — 不需要等全部做完才有治理效果。
跟技術認知有限的客戶溝通，問對問題比解釋技術更重要。
| 你想知道的 | 不要這樣問 | 應該這樣問 |
|---|---|---|
| 訂閱層級 | ❌「你們 OpenShift 是什麼版本？」（會得到 “4.16”） | ✅「方便讓我看一下你們跟 Red Hat 的訂閱合約嗎？我確認品項名稱，看哪些資安工具已經包含在裡面。」 |
| 訂閱層級（替代問法） | ❌「你們有沒有買 ACS？」（客戶不知道 ACS 是什麼） | ✅「可以幫我問一下 B 廠商，你們裝的 OpenShift 是 Container Platform 還是 Platform Plus？」 |
| 現有 Registry | ❌「你們有 Quay 嗎？」 | ✅「目前廠商的 image 有沒有一個統一存放的地方？」 |
| 技術概念 | 比喻 |
|---|---|
| Namespace | 大樓裡的隔間 |
| RBAC | 門禁卡（不同卡進不同門） |
| Image Scanning | 貨物安檢 |
| Admission Controller | 警衛——安檢不過就不讓進 |
| Runtime Monitoring | 監視器 |
| NetworkPolicy | 隔間之間的防火牆 |
| Compliance Report | 稽核護身符 |
最有力的一句：「Namespace 是隔間，但隔間只能防君子。廠商帶進來的 image 裡面有什麼、跑起來做什麼，需要另外一層機制來管——就像大樓有隔間，但還是需要門禁和監視器。」
| 交付物 | 給誰看 | 作用 |
|---|---|---|
| 一頁式簡報 | 客戶本人 | 快速理解全貌，取得 buy-in |
| 管理辦法 | 稽核 / 上級 | 正式公文，制度依據 |
| 技術規格書 | B 廠商 | 具體怎麼設定 |
| SOP + 表單 | 日常運作 | Image 上架申請流程、廠商權限申請 |
| 合規對照表 | 稽核 | 資安法應辦事項 ↔ 怎麼做到的 |
資安治理的本質不是技術，是信任的制度化。
沒有治理時，系統安全完全依賴「信任廠商不會亂搞」。規模一大就失控——不是因為廠商有惡意，而是因為沒有機制確保每個人都做到該做的事。
六層架構的本質是把「信任」從「相信人會做對的事」轉換為「平台確保只有對的事能被做」。RBAC 確保只有被授權的人能操作、Admission Controller 確保只有合規的 image 能跑、Runtime Monitoring 確保跑起來後有人盯著——每一層都是在用技術機制取代人的自律。
對 SI 而言，這也是商業模式的轉變：不是賣一份報告，而是幫客戶建立一套即使 SI 離開了也能持續運作的治理機制。