託管Kubernetes的一個挑戰是，它將控制平面交給了雲端供應商，但您仍然要承擔身分風險。
亞馬遜彈性 Kubernetes 服務 (EKS)、Azure Kubernetes 服務 (AKS) 和Google Kubernetes 引擎 (GKE) 等服務徹底改變了應用程式部署方式。但這些雲端服務提供者管理的是控制平面，而不是您的存取風險。
重要性： Kubernetes基於角色的存取控制(RBAC) 和雲端身分與存取管理(IAM) 通常作為獨立的存取層運作。 隨著權限的累積和現有權限在這些層級間的持續存在，安全團隊會逐漸難以掌握身分在叢集和雲端環境中可以存取（或演變）的範圍。
威脅： Unit 42 的研究發現，前沿模型可以快速識別權限過高的帳戶和未管理的令牌，從而實現橫向移動。其針對Kubernetes 的研究表明，一個被盜的、擁有過多權限的服務帳戶身份，可以如何從一個工作負載擴展到叢集甚至更廣泛的雲端環境。
差距：原生 Kubernetes RBAC 依賴靜態角色和角色綁定。當團隊大規模地將雲端 IAM 直接對應到叢集權限時，不可避免地會建立靜態權限。
一方面，開發人員需要透過命令列介面 (CLI) 來調試微服務。另一方面，自動化 CI/CD 管線依賴長期有效的 kubeconfig 憑證來發布程式碼。隨著團隊引入委託 AI 代理來協助維運，攻擊面進一步擴大。對安全負責人而言，問題不僅在於誰可以存取集群，更在於這種身分會演變成什麼樣子，以及它的影響範圍有多廣。
問題不僅在於誰可以存取集群，還在於這種身分會演變成什麼樣子，以及它的影響範圍有多廣。
您可以做什麼：在本部落格中，我們將向您展示組織如何透過擺脫靜態金鑰、base64 編碼的本機金鑰和永久角色，轉向統一的身份安全模型，從而在現代 Kubernetes 環境中強制執行叢集安全。
在託管 Kubernetes 中，任何能夠更改叢集或存取敏感資源的身份都擁有特權。
但傳統的特權存取管理（PAM）是為靜態的人工帳戶和用於儲存傳統伺服器密碼的環境而設計的。託管式 Kubernetes 恰恰凸顯了這種傳統方法在容器化雲端環境中失效的原因。
當每個身分都可以獲得特權時，需要兩種存取模型來減少長期存取權限：零長期權限（ ZSP）和 即時存取 （JIT）。
現代特權存取管理 (PAM) 必須不斷發展，以保護三種在雲端基礎架構中執行特權操作的不同身分類型：
透過將三種身分類型納入現代化的 PAM 框架，安全團隊可以減少營運孤島，並在整個雲端生命週期中強制執行零安全性策略 (ZSP)。
Kubernetes 風險是由實際存取權限決定的，而不是由指派的角色決定的。
確保託管 Kubernetes 的安全首先需要全面了解現有角色和工作負載。不同供應商的特定實作機制有所不同：雲端 IAM 角色（例如透過 aws-auth 對應的 AWS IAM 或 Azure RBAC）現在直接與原生 Kubernetes RBAC 策略並行運行，從而連接了兩種截然不同的存取模型。
Idira® 身分安全平台會自動掃描和映射指派給 Kubernetes 叢集和命名空間的雲端 IAM 角色，協助團隊為發現的角色建立 ZSP 策略，同時消除手動、容易出錯的入職流程。
同時，它還能發現整個基礎架構中的機器身份，暴露靜態 API 金鑰、透過基礎架構即服務和基礎架構即程式碼模板部署的影子金鑰，以及隱藏在管道和容器化環境中的非託管服務帳戶。
叢集存取權限應僅限於工作所需時間。但安全控制措施不應強迫開發人員偏離其正常的工作流程。
透過 Idira，開發人員可以直接在本機終端中使用熟悉的idsec CLI 指令（idsec login 、idsec k8s clusters list 、idsec k8s kubeconfig generate ）進行驗證，以產生短期憑證。
集群存取權限應僅在工作需要時有效。
存取權限的粒度細化到命名空間層級。開發人員不再依賴永久的靜態 Kubernetes角色綁定，而是僅查看和操作已授權的命名空間——例如，在支付系統中查看日誌，同時與分析系統保持隔離。當需要提升存取權限進行維護或緊急故障回應時，團隊會授予即時存取權限，並輔以完整的kubectl exec會話記錄以確保合規性。
確保對叢集的存取安全性只是問題的一半；容器化工作負載也必須對外部雲端服務和資料庫進行身份驗證。
原生Kubernetes Secret本身就存在安全漏洞。它們本質上只是經過 Base64 編碼的字串，而非加密的金鑰庫。這意味著，如果 Pod 遭到入侵，硬編碼的憑證將構成重大風險。
Idira 有助於消除部署管道和工作負載中長期存在的靜態金鑰。諸如 GitHub Actions 或 GitLab 之類的 CI/CD 系統使用短期有效的 OpenID Connect 令牌 (OIDC) 來實現無密鑰部署。對於 Pod 到雲端的身份驗證，工作負載向Idira Secrets Manager提交證書，以取得短期有效的 JWT-SVID，即 JWT 格式的 SPIFFE 可驗證身分文件。 Pod 可以使用其 JWT-SVID 直接存取支援 OIDC 的外部服務；否則，它們可以使用 JWT-SVID 從 Idira Secrets Manager 動態取得外部服務所需的確切憑證。這減少了在 Kubernetes 中儲存靜態金鑰的需求，以及手動管理長期有效憑證的開銷。
在關鍵生產環境宕機期間，SRE 人員無需在不同的存取工具之間切換。借助Idira Secure Cloud Access，工程師可以透過單一的特權工作流程，獲得對叢集 Pod 和後端資料庫的臨時統一存取權限。
透過在 EKS、AKS 和 GKE 之間實現治理標準化，企業無論工作負載運作在何處，都能實現一致的零權限策略。連接器可透過 Helm 或 Argo CD 無縫部署，為託管 Kubernetes 基礎架構帶來全面的可見性、零權限和自動化控制。
結論：雲端服務提供者可能管理控制平面，但您的組織仍然要承擔身分風險。
透過不斷發現存取權限、控制權限以及管理人類、機器和代理身分如何使用存取權限，您可以減少攻擊者可繼承的存取權限和可利用的路徑。
隨著組織機構不斷增加新的叢集、工作負載和人工智慧代理，這項工作仍在繼續。團隊必須定期重新評估權限並完善策略，以防止今天的臨時存取權演變成明天的永久權限。
申請線上演示，了解 Idira 如何消除 AWS EKS 和 Azure AKS 環境中的長期權限。或查看解決方案簡介，以了解如何為開發人員、工作負載和 CI/CD 管道強制執行零安全性策略 (ZSP)。
零常駐權限 (ZSP) 是一種存取模型，其中任何使用者、機器工作負載或 AI 代理程式都不會永久保留管理權限或叢集存取權限。權限以即時 (JIT) 的方式動態授予，僅限於特定命名空間，並在任務完成後自動撤銷。
Kubernetes 原生 Secret 只是儲存在etcd中的 base64 編碼的純文本，並非加密金鑰庫。如果 Pod 或倉庫遭到入侵，攻擊者可以輕鬆解碼靜態原生 Secret，從而獲得對外部雲端資料庫的未授權存取權。
Idira對自主 AI 代理應用與對人類開發人員相同的會話邊界、命名空間範圍和命令審計，確保 AI 操作工作流程嚴格按照短期、最小權限執行。
Kubernetes RBAC 控制叢集內部的權限，而雲端 IAM 則管理跨供應商環境的存取。安全團隊需要跨越這兩層的可見性和一致的控制，才能全面了解身分的權限範圍。
文章來源/IDIRA Blog IDIRA Blog
返回