Kubernetes 遷移幾乎讓我們的創業公司倒閉。 我們的情況： - 8 台 EC2 實例 - 使用 Ansible 進行部署 - 無聊但有效 - 每月 $1200 的 AWS 賬單 為什麼我們遷移： - 新投資者想要「雲原生」 - 工程師想要 K8s 經驗 - 競爭對手在使用它 - 看起來像是未來的趨勢 6 個月後： - 3 名工程師全職投入 K8s - AWS 賬單達到每月 $4500 - 部署所需時間比之前更長 - 故障增多，而不是減少 - 產品開發停滯不前 我們回滾了： - 轉移到 ECS Fargate - 兩週的遷移 - 回到每月 $1800 - 工程師回到功能開發上 K8s 在擴展方面非常出色。我們並未達到擴展的規模。技術應該解決你實際面臨的問題。

為我們的 API 添加了 gzip 壓縮。響應大小下降了 85%，延遲下降了 60%。 壓縮前： - 平均響應：240 KB - 傳輸時間：400ms - 帶寬成本：$220/月 壓縮後： - 平均響應：36 KB - 傳輸時間：48ms - 帶寬成本：$70/月 添加了壓縮中介軟體 結果： - 加載時間：快了 88% - 帶寬：減少了 68%

一名滲透測試者在 15 分鐘內獲得了我們 Kubernetes 集群的 root 訪問權限。以下是他們利用的漏洞。 攻擊鏈： - 發現暴露的 Kubernetes 儀表板（我們的錯） - 儀表板有只讀服務帳戶（我們以為這是安全的） - 服務帳戶可以列出所有命名空間的秘密 - 在一個秘密中發現 AWS 憑證 - 使用 AWS 憑證訪問 EC2 實例配置文件 - 實例配置文件通過 IAM 擁有完整的 Kubernetes 管理權限 - 使用 kubectl 創建特權 pod - 逃逸到節點 - 獲得整個集群的 root 訪問權限 我們以為做對的事情： - 儀表板是只讀的 - 秘密在靜態時是加密的 - 網絡策略已到位 - 定期進行安全更新 我們錯過的事情： - 儀表板根本不應該暴露 - 服務帳戶需要最小特權原則 - 秘密不應包含 AWS 憑證（應使用 IRSA） - Pod 安全政策未強制執行 - 節點訪問未加固 修復花了 2 週： - 完全移除 Kubernetes 儀表板 - 為所有 pod 的 AWS 訪問實施 IRSA - 應用嚴格的 PSPs/Pod 安全標準 - 審計所有 RBAC 權限 - 定期進行滲透測試 成本：$24K 用於滲透測試 價值：防止了可能造成災難性漏洞的事件