Azure Kubernetes Services (AKS) 中的 Pod 安全性最佳做法
當您在 Azure Kubernetes Service (AKS) 中開發和執行應用程式時，Pod 安全性是主要考量。 應用程式應設計為供需要最少量權限的主體使用。 保持私人資料安全是客戶最關切之事。 您不希望向外界公開資料庫連接字串、金鑰或祕密及憑證等認證，讓攻擊者將這些祕密用於惡意用途。 請不要將它們新增至程式碼，或內嵌於容器映像中。 因為需要重建容器映像，採用這種方法會暴露在風險下，並限制輪替這些認證的能力。
此最佳做法文章著重於如何保護AKS 中的 Pod。 您將學習如何：
- 使用 Pod 資訊安全內容，限制存取處理序與服務或提升權限
- 使用 Microsoft Entra 工作負載識別碼，向其他 Azure 資源進行驗證
- 向數位保存庫要求和擷取認證 (例如 Azure Key Vault)
保護資源的 Pos 存取
最佳做法指引 - 若要以不同使用者或群組來執行，並限制基礎節點處理序與服務的存取，請定義 Pod 資訊安全內容設定。 指派所需的最少量權限。
Pod 的執行身分應為定義的使用者或群組，而非「根」，您的應用程式才能正確執行。 Pod 或容器的 securityContext 可讓您定義如 runAsUser 或 fsGroup 的設定，取得適當的權限。 僅指派所需的使用者或群組的權限，並不使用資訊安全內容作為取得其他權限的方式。 runAsUser、權限提升和其他 Linux 功能設定僅適用於 Linux 節點和 Pod。
當您的執行身分為非根使用者時，容器無法繫結至具特殊權限的連接埠 1024。 在此案例中，Kubernetes 服務可用來偽裝應用程式在特定連接埠上執行的事實。
Pod 資訊安全內容也可以定義存取處理序和服務的其他功能或權限。 您可以設定下列常見資訊安全內容定義：
- allowPrivilegeEscalation 定義 Pod 能否取得「根」權限。 設計應用程式時，此設定一律設為 false。
- Linux 功能可讓 Pod 存取基礎節點處理序。 請謹慎地指派這些功能。 指派所需的最少量權限。 如需詳細資訊，請參閱 Linux 功能。
- SELinux 標籤是 Linux 核心安全模組，可讓您定義服務、處理序及檔案系統存取的存取原則。 請再次指派所需的最少量權限。 如需詳細資訊，請參閱 Kubernetes 中的 SELinux 選項
下列範例 Pod YAML 資訊清單會設定資訊安全內容來定義：
- Pod 的執行身分為使用者識別碼 1000 與群組識別碼 2000 的一部分
- 無法提升權限以使用
root - 允許 Linux 功能存取網路介面和主機的系統 (硬體) 時鐘
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
fsGroup: 2000
containers:
- name: security-context-demo
image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
securityContext:
runAsUser: 1000
allowPrivilegeEscalation: false
capabilities:
add: ["NET_ADMIN", "SYS_TIME"]
和叢集操作員一起決定您需要哪些資訊安全內容設定。 嘗試設計應用程式，以將 Pod 需要的其他權限和存取權降至最少。 使用叢集操作員可實作的 AppArmor 與 seccomp (安全運算)，還有其他安全性功能可限制存取。 如需詳細資訊，請參閱保護容器對資源的存取。
限制認證公開程度
最佳做法指引 - 不在應用程式程式碼中定義認證。 使用 Azure 資源的受控身分識別，可讓 Pod 要求存取其他資源。 如 Azure Key Vault 的數位保存庫也應可用來儲存和擷取數位金鑰與認證。 Pod 受控識別僅適用於搭配 Linux Pod 和容器映像使用。
若要限制在應用程式程式碼中公開認證的風險，請避免使用固定或共用認證。 認證或金鑰不應直接包含在程式碼中。 如果公開這些認證，就需要更新和重新部署應用程式。 較好的方法是提供 Pod 自己的身分識別和自我驗證方式，或從數位保存庫自動擷取認證。
使用 Microsoft Entra 工作負載識別碼
工作負載身分識別是 Pod 上執行的應用程式所使用的身分識別，可針對支援此身分識別的其他 Azure 服務 (例如儲存體或 SQL) 進行自行驗證。 其會與 Kubernetes 原生功能整合，以與外部身分識別提供者同盟。 在此安全性模型中，AKS 叢集會作為權杖簽發者，Microsoft Entra 識別碼會使用 OpenID Connect 來探索公開簽署金鑰，並在交換服務帳戶權杖作為 Microsoft Entra 權杖之前驗證服務帳戶權杖的真確性。 您的工作負載可以使用 Azure SDK 或 Microsoft 驗證程式庫 (MSAL)，以使用 Azure 身分識別用戶端程式庫來交換投影到其磁碟區的服務帳戶權杖以作為 Microsoft Entra 權杖。
如需工作負載身分識別的詳細資訊，請參閱設定 AKS 叢集以搭配應用程式使用 Microsoft Entra 工作負載識別碼
搭配使用 Azure Key Vault 與祕密存放區 CSI 驅動程式
使用 Microsoft Entra 工作負載識別碼可針對支援的 Azure 服務進行驗證。 如果您自己的服務或應用程式沒有 Azure 資源受控身分識別，則仍可使用認證或金鑰來進行驗證。 數位保存庫可用來儲存這些祕密內容。
當應用程式需要認證時會與數位保存庫通訊、擷取最新的祕密內容，然後連線到所需的服務。 這個數位保存庫可以是 Azure Key Vault。 下圖顯示使用 Pod 受控身分識別從 Azure Key Vault 擷取認證的簡化工作流程：
有了 Key Vault，您就可以儲存並定期輪替使用祕密，例如認證、儲存體帳戶金鑰或憑證。 您可使用祕密存放區 CSI 驅動程式的 Azure Key Vault 提供者來整合 Azure Key Vault 與 AKS 叢集。 祕密存放區 CSI 驅動程式可讓 AKS 叢集從 Key Vault 原生擷取祕密內容，並只會將其安全地提供給提出要求的 Pod。 請與叢集操作員合作，以將祕密存放區 CSI 驅動程式部署至 AKS 背景工作節點。 您可以使用 Microsoft Entra 工作負載識別碼向 Key Vault 要求存取權，並透過祕密存放區 CSI 驅動程式擷取所需的祕密內容。
下一步
本文著重在如何保護您的 Pod。 若要實作這些部分的一些內容，請參閱下列文章：
