導入 OPA 在金融業監控 k8s 部署檔的安全性 | Implementing OPA for Secure Kubernetes Configuration in the Financial Industry @2024 Hello World Devs Conference
- 1. 導入 OPA 在金融業監控 k8s 部署檔的安全性 玉山銀行 | 核心組副主任工程師 李啓維
- 2. 2 個人介紹 玉山銀行智能金融處 • 照料部門內 k8s • 解除部署維運的疑難雜症 • 休閒咖啡長板閱讀 技術部落格： https://sean22492249.medium.com/ 個人部落格： https://kiwilee-blog.netlify.app/
- 3. 3 OPA 在金融業監控 k8s 部署檔的安全性 起因 為何要導入部署檔安全 提案規劃 選型 尋找 Solution 導入 Solution 階段性導入
- 4. 4 痛點 - Operations 權限控管：專人變更，專案遽增追著單據修改，肉眼偵錯，我好累 >> 人工作業風險，資安漏洞，行政地獄
- 6. 6 目前的部署設定概念 1. 內部開發 2. 設定檔分散管理 3.Branch gitOps 人工修改 缺乏自動檢核
- 7. 提案 & 規劃 & 收斂 7 減少導入時的移轉成本 減少維運人員的手動變更 審核變更與保留軌跡 OPA 自動化驗證 設定檔分散管理 稽 核 減少人工風 險 好 累 服務不重 啟 集中管理 Policy 加速變更流 程 Open-Closed Principle 提升 Dev 動手做能 力
- 8. 8 導入計畫 加入 Policy 管控部署到 kubernetes 的 Helm chart
- 9. 9 首先是 K8S 內建的 pod 保護 Pod Security Standard - 提供 pod 權限的樣本 - Pod Security Admission - 執行 pod 違反權限 - • 沒有限制 Privileged • 最低限制 • ex. hostPath, hostPort Baseline • 最嚴謹繼承 Baseline 的權 限 • ex. volume type Restricte d Enforce 拒絕部署 Audit 記錄 event Warn 顯示 warning
- 10. 不使用 pod security standard 的原因 Policy 只有模 板 各個專案各自的 Policy 稽核盤點困擾 我們的分散設定檔 不想每個專案都去改 支援例外較低 設定白名單較麻煩 只能應用在 pod 想要加入 ingress 需 求
- 11. 11 What is OPA - Gatekeeper Credit: Open Policy Agent: A Powerful Policy Engine for Cloud-Native Environments | by Anik Barua | Medium OPA (Open Policy Agent) 是一個超級規則檢查員，幫助不同系統管理和執行規則 Gatekeeper 是 OPA 在 k8s 的應用，專門確保所有的 k8s object 在建立或修改之前，都符合規則 規則樣板 規則參數
- 12. 12 Gatekeeper with OPA ( 簡化版 ) 概念 K8S Object 監控變更 Gatekeeper 整合 建置在 k8s 的 Policy Mutation/ Validation source: https://kubernetes.io/blog/2019/08/06/opa-gatekeeper-policy-and-governance-for-kubernetes/ Config CRD Exempting 實體化
- 13. 13 Gatekeeper with OPA ( 簡化版 ) 功能 滿足 監控變更 Gatekeeper 整合 建置在 k8s 的 Policy Mutation/ Validation source: https://kubernetes.io/blog/2019/08/06/opa-gatekeeper-policy-and-governance-for-kubernetes/ Config CRD 集中管理 policy 盤點簡單 不只有 Pod 支援動態調整 保有記錄
- 14. 14 選擇 OPA 帶給我們的優缺點 我們喜歡的 Policy:Rego 語法撰寫困難 ( 新版本可使用 CEL) 使用 OPA Policy Library 範本 需要部署才能觸發 ( 會占用資源 ) 利用 kwok 的虛擬節點模擬部署行為 集中化管理 Policy 可根據 image, namespace, name 來排除 policy 動態調整 policy 的 enforce action 我們困擾的
- 15. 15 開始動作
- 16. 16 Config Repo Trigger PR check Deploy (only schedule) Gatekeepe r check Policies pass or not? 修改 values.yaml 發布 PR PR Approve PR Complete & Merge Azure Automation argo 自助修改部署檔 Config 修正
- 17. 17 透過 ReplicaSet 數量 (desired=ready) 判斷 Validate 是否通 過
- 18. 18 Pipeline – 成功
- 19. 19 Pipeline – 失敗 (helm install)
- 20. 20 Pipeline – 失敗 (Gatekeeper) 從 RS event 可知道被 Gatekeeper 阻擋的原因 有提供手冊給開發者查找並解除 >> 未來會嵌入解決的 Runbook 在 pipeline ，減少頁面跳轉造成的困擾
- 23. 階段性導入 OPA 宣導期 警告期 拒絕期 23 Developer • 巨量的教育訓練😥 • Solution 介紹 • 業務可能的衝擊 • 說服期待的自由 Developer • 使用手冊 • 告知目前有違反的 限期更動 Developer • Policy Deny • Pipeline 啟用 > 使用指標 & 行內 Policy
- 24. 24 Takeaway 找到痛點，反覆評估需求與現況 每間公司有自己的苦 Solution: 盡量滿足 Open-Closed Principle 應保持彈性與適應能力 減少挖傷疤，並挑選可擴充彈性高的 設定邊界：軌跡、審核、自動化 訂好規矩，圈好 Playground ，隨時觀察
- 25. 25 Thanks!
- 26. 26 補足區塊 補足區塊
- 27. 佈署流程介紹 27 Code Git Sync 發 PR Merge Pull Image Pipeline ArgoCD MLaaS K8s Image 存放庫 Continuous integration Continuous Delivery 27 Build Image 整合測試
- 28. 28 實作小細項： • 部署在 fake-node ( 記得設定 taint) ，避免資源浪費 • Fake-node 無法模擬 GPU ， 因此移除 Deployment 的 GPU resources • Helm install 設定 time-out 20 秒即可， 因 fake-node schedule&deploy 可在 10 秒內完成 • 檢查沒有部署在 fake-node 的 pod ，以 warning 顯示 >> 因專案都使用自行開發的 mlaas2chart ，所以可直接 helm install 。 其實也可以 helm template 後，再去做修改。
- 29. 29 目前導入的 BAD BAD • 絕對要避免 pod 被部署到 kwok-node 上面，特別是 有 toleration 的 pod 。 cilium-operator 慘案 • audit log 可抓到資訊，但目前 loki 搭配 grafana 使 用有點苦手 • Rego 語法難寫，之後 k8s 升級可以使用 CEL ，好寫 很多
Editor's Notes
- #4: 不允許進入 k8s ，argocd 只能 read-only 沒有 k8s 的開發環境，對於 pod/container 理解較低 對於服務使用資源的理解不足，會過於寬鬆的定義資源使用 多個環境之間，無法同步，只能透過 azudevops git 同步，或者用 ansible (不愛)
- #5: 不允許進入 k8s ，argocd 只能 read-only 沒有 k8s 的開發環境，對於 pod/container 理解較低 對於服務使用資源的理解不足，會過於寬鬆的定義資源使用 多個環境之間，無法同步，只能透過 azudevops git 同步，或者用 ansible (不愛)
- #6: 目前的架構 有用我們自製的 helm chart 作為各專案的部署 透過調整其中的 values.yaml 滿足各種需求 分散式，都放在專案下面 透過 argocd 去做 gitOps 與專案服務程式相近 目前是各環境放在不同的 branch
- #7: 16.160.167 為什麼我們會想要導入 config secuirty 強化設定檔的安全性 (作業流程零信任，風險紀律零容忍) 原先統一開單，由 k8s 維運人員調整。過於麻煩， 保留軌跡，改動需留下紀錄 (gitOps) 改動需要有自動化驗證 (gatekeeper) 需要有 Approve gate 不影響原始服務
- #8: 不允許進入 k8s ，argocd 只能 read-only 沒有 k8s 的開發環境，對於 pod/container 理解較低 對於服務使用資源的理解不足，會過於寬鬆的定義資源使用 多個環境之間，無法同步，只能透過 azudevops git 同步，或者用 ansible (不愛)
- #9: ❌ Pod security policies PodSecurityPolicy was deprecated in Kubernetes v1.21, and removed from Kubernetes in v1.25. Pod security standards 安全性的標準：Privilege, Baseline, Restricted 還會有不同版本的差別，可以設定成 Baseline:latest 強制使用 Privileged: 沒有限制 Baseline: 在避免已知的特權提升下，提供最低的限制 Restricted: 目前 pod 最佳的權限設定 Pod security admission (k8s v1.25 stable) 違反者的動作：warn, audit, enforce Enforce: 直接拒絕 pod 的部署 audit: 仍然允許部署，但會噴 event 紀錄在 audit log 中 warn: 仍然允許部署，會有 user-facing 的警示通知 先設定 Admission 再設定 template
- #10: 以 pod label 或是 ns 都可以 可以根據不同的 pod security standard 設定對應的 pod security admission 有支援例外，但顆粒度不大 分散式的設定檔，每個都要更新太麻煩 針對 policy 沒辦法集中管理 只能針對 pod 做管控
- #22: 不允許進入 k8s ，argocd 只能 read-only 沒有 k8s 的開發環境，對於 pod/container 理解較低 對於服務使用資源的理解不足，會過於寬鬆的定義資源使用 多個環境之間，無法同步，只能透過 azudevops git 同步，或者用 ansible (不愛)
- #24: 把 0. 加入標題
- #26: Code Scan Sonarqube checkmarx Image Scan trivy Config deploy Gatkeeper Runtime Falco?