保护 Azure Kubernetes 服务 (AKS) 中的 Pod 的最佳做法Best practices for pod security in Azure Kubernetes Service (AKS)

在 Azure Kubernetes 服务 (AKS) 中开发和运行应用程序时,Pod 的安全性是需要考虑的一个重要方面。As you develop and run applications in Azure Kubernetes Service (AKS), the security of your pods is a key consideration. 设计应用程序时,应以所需权限最少为原则。Your applications should be designed for the principle of least number of privileges required. 客户最看重的是私人数据的安全。Keeping private data secure is top of mind for customers. 你不会希望将数据库连接字符串、密钥或机密和证书等凭据暴露给外部世界,因为攻击者可能利用这些机密进行恶意攻击。You don't want credentials like database connection strings, keys, or secrets and certificates exposed to the outside world where an attacker could take advantage of those secrets for malicious purposes. 请勿将这些凭据添加到代码中,或将其嵌入容器映像中。Don't add them to your code or embed them in your container images. 这样会有暴露的风险,并且会限制凭证的轮换能力,因为轮换时需要重建容器映像。This approach would create a risk for exposure and limit the ability to rotate those credentials as the container images will need to be rebuilt.

这篇有关最佳做法的文章重点介绍如何保护 AKS 中的 Pod。This best practices article focuses on how to secure pods in AKS. 你将学习如何执行以下操作:You learn how to:

  • 使用 Pod 安全性上下文来限制对进程和服务,或权限提升的访问权限Use pod security context to limit access to processes and services or privilege escalation
  • 使用 Pod 托管的标识通过其他 Azure 资源进行身份验证Authenticate with other Azure resources using pod managed identities
  • 从数字保管库(如 Azure Key Vault)请求和检索凭据Request and retrieve credentials from a digital vault such as Azure Key Vault

还可阅读有关群集安全性容器映像管理的最佳做法。You can also read the best practices for cluster security and for container image management.

保护 Pod 对资源的访问权限Secure pod access to resources

最佳做法指南 - 要作为其他用户或组运行,并限制对基础节点进程和服务的访问权限,请定义 Pod 安全性上下文设置。Best practice guidance - To run as a different user or group and limit access to the underlying node processes and services, define pod security context settings. 请分配所需的最少权限。Assign the least number of privileges required.

为使应用程序正常运行,Pod 应作为已定义的用户或组运行,而不是根用户或组。For your applications to run correctly, pods should run as a defined user or group and not as root. 通过 Pod 或容器的 securityContext,可定义 runAsUser 或 fsGroup 等设置,以承担相应权限 。The securityContext for a pod or container lets you define settings such as runAsUser or fsGroup to assume the appropriate permissions. 仅分配所需的用户或组权限,不要使用安全性上下文来承担其他权限。Only assign the required user or group permissions, and don't use the security context as a means to assume additional permissions. runAsUser、特权提升和其他 Linux 功能设置仅在 Linux 节点和 Pod 上可用。The runAsUser , privilege escalation, and other Linux capabilities settings are only available on Linux nodes and pods.

作为非根用户运行时,容器无法绑定到 1024 下的特权端口。When you run as a non-root user, containers cannot bind to the privileged ports under 1024. 此时可使用 Kubernetes 服务掩盖应用程序正在特定端口上运行这一事实。In this scenario, Kubernetes Services can be used to disguise the fact that an app is running on a particular port.

Pod 安全性上下文还可定义用于访问进程和服务的其他功能或权限。A pod security context can also define additional capabilities or permissions for accessing processes and services. 可设置以下常见安全性上下文定义:The following common security context definitions can be set:

  • allowPrivilegeEscalation 定义 Pod 是否可承担根特权。allowPrivilegeEscalation defines if the pod can assume root privileges. 设计应用程序,将此设置始终设为 false。Design your applications so this setting is always set to false.
  • Linux 功能可使 Pod 访问基础节点进程。Linux capabilities let the pod access underlying node processes. 请小心分配这些功能。Take care with assigning these capabilities. 请分配所需的最少权限。Assign the least number of privileges needed. 有关详细信息,请参阅 Linux 功能For more information, see Linux capabilities.
  • SELinux 标签是一个 Linux 内核安全模块,允许你定义服务、进程和文件系统访问权限的访问策略。SELinux labels is a Linux kernel security module that lets you define access policies for services, processes, and filesystem access. 同样,请分配所需的最少权限。Again, assign the least number of privileges needed. 有关详细信息,请参阅 Kubernetes 中的 SELinux 选项For more information, see SELinux options in Kubernetes

以下示例 Pod YAML 清单设置了安全性上下文设置,给出了以下定义:The following example pod YAML manifest sets security context settings to define:

  • Pod 以 ID 为 1000 的用户身份和 ID 为 2000 的部分组运行 Pod runs as user ID 1000 and part of group ID 2000
  • 无法提升特权,无法使用 rootCan't escalate privileges to use root
  • 允许 Linux 功能访问网络接口和主机的实时(硬件)时钟Allows Linux capabilities to access network interfaces and the host's real-time (hardware) clock
apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  containers:
    - name: security-context-demo
      image: dockerhub.azk8s.cn/library/nginx:1.15.5
    securityContext:
      runAsUser: 1000
      fsGroup: 2000
      allowPrivilegeEscalation: false
      capabilities:
        add: ["NET_ADMIN", "SYS_TIME"]

与群集操作员共同确定所需安全性上下文设置。Work with your cluster operator to determine what security context settings you need. 尝试设计应用程序,以尽量减少其他权限并访问 Pod 要求。Try to design your applications to minimize additional permissions and access the pod requires. 群集操作员还可实施其他安全功能来限制使用 AppArmor 和 seccomp(安全计算)进行的访问。There are additional security features to limit access using AppArmor and seccomp (secure computing) that can be implemented by cluster operators. 有关详细信息,请参阅保护容器对资源的访问For more information, see Secure container access to resources.

避免凭据暴露Limit credential exposure

最佳操作指南 - 不要在应用程序代码中定义凭据。Best practice guidance - Don't define credentials in your application code. 使用 Azure 资源的托管标识,让 Pod 请求访问其他资源。Use managed identities for Azure resources to let your pod request access to other resources. 还应使用数字保管库(如 Azure Key Vault)来存储和检索数字密钥和凭据。A digital vault, such as Azure Key Vault, should also be used to store and retrieve digital keys and credentials. Pod 托管标识仅适用于 Linux Pod 和容器映像。Pod managed identities is intended for use with Linux pods and container images only.

要避免凭据在应用程序代码中暴露,请勿使用固定或共享凭据。To limit the risk of credentials being exposed in your application code, avoid the use of fixed or shared credentials. 不应直接在代码中包含凭证或密钥。Credentials or keys shouldn't be included directly in your code. 如果凭据暴露,则需更新并重新部署应用程序。If these credentials are exposed, the application needs to be updated and redeployed. 更好的做法是,为 Pod 提供自己的标识,让它自行进行身份验证,或自动从数字保管库中检索凭据。A better approach is to give pods their own identity and way to authenticate themselves, or automatically retrieve credentials from a digital vault.

以下关联的 AKS 开放源代码项目可让你自动验证 Pod 或从数字保管库请求凭据和密钥:The following associated AKS open source projects let you automatically authenticate pods or request credentials and keys from a digital vault:

Azure 技术支持不为关联的 AKS 开放源代码项目提供支持。Associated AKS open source projects are not supported by Azure technical support. 提供这些项目是为了从我们的社区收集反馈和 bug。They are provided to gather feedback and bugs from our community. 建议不要将这些项目用于生产。These projects are not recommended for production use.

使用 Pod 托管标识Use pod managed identities

Azure 资源的托管标识允许 Pod 根据支持它的 Azure 服务(如存储或 SQL)对自身进行身份验证。A managed identity for Azure resources lets a pod authenticate itself against Azure services that support it, such as Storage or SQL. 已向该 Pod 分配 Azure 标识,允许 Pod 对 Azure Active Directory 进行身份验证并接收数字令牌。The pod is assigned an Azure Identity that lets them authenticate to Azure Active Directory and receive a digital token. 可向其他 Azure 服务展示此数字令牌,以检查该 Pod 是否有权访问该服务并执行所需操作。This digital token can be presented to other Azure services that check if the pod is authorized to access the service and perform the required actions. 采用此方法时,对于数据库连接字符串等,无需使用机密。This approach means that no secrets are required for database connection strings, for example. 下图显示了简化后的 Pod 托管标识工作流:The simplified workflow for pod managed identity is shown in the following diagram:

Azure 中简化后的 Pod 托管标识工作流

使用托管标识,应用程序代码无需包含凭据即可访问 Azure 存储等服务。With a managed identity, your application code doesn't need to include credentials to access a service, such as Azure Storage. 由于每个 Pod 都使用自己的标识进行身份验证,因此可审核并评价访问权限。As each pod authenticates with its own identity, so you can audit and review access. 如果应用程序与其他 Azure 服务连接,请使用托管标识来限制凭据重用,避免凭据暴露。If your application connects with other Azure services, use managed identities to limit credential reuse and risk of exposure.

有关 Pod 标识的详细信息,请参阅配置 AKS 群集以通过应用程序使用 Pod 托管标识For more information about pod identities, see Configure an AKS cluster to use pod managed identities and with your applications

将 Azure Key Vault 与机密存储 CSI 驱动程序配合使用Use Azure Key Vault with Secrets Store CSI Driver

使用 Pod 标识项目,可以通过提供支持的 Azure 服务进行身份验证。Using the pod identity project enables authentication against supporting Azure services. 若你自己的服务或应用程序没有 Azure 资源的托管标识,你仍可使用凭据或密钥进行身份验证。For your own services or applications without managed identities for Azure resources, you can still authenticate using credentials or keys. 可使用数字保管库来存储这些机密内容。A digital vault can be used to store these secret contents.

当应用程序需要凭据时,它们会与数字保管库通信,检索最新的机密内容,然后连接到所需服务。When applications need a credential, they communicate with the digital vault, retrieve the latest secret contents, and then connect to the required service. 此数字保管库可以是 Azure Key Vault。Azure Key Vault can be this digital vault. 下图显示了使用 Pod 托管标识从 Azure Key Vault 检索凭据的简化工作流:The simplified workflow for retrieving a credential from Azure Key Vault using pod managed identities is shown in the following diagram:

使用 Pod 托管标识从 Key Vault 检索凭据的简化工作流

使用 Key Vault,可存储并定期轮换凭据、存储帐户密钥或证书等机密。With Key Vault, you store and regularly rotate secrets such as credentials, storage account keys, or certificates. 可以使用机密存储 CSI 驱动程序的 Azure Key Vault 提供程序将 Azure Key Vault 与 AKS 群集集成。You can integrate Azure Key Vault with an AKS cluster using the Azure Key Vault provider for the Secrets Store CSI Driver. 机密存储 CSI 驱动程序使得 AKS 群集能够以原生方式检索 Key Vault 中的机密内容,并以安全方式仅将其提供给发出请求的 Pod。The Secrets Store CSI driver enables the AKS cluster to natively retrieve secret contents from Key Vault and securely provide them only to the requesting pod. 与群集操作员合作,将机密存储 CSI 驱动程序部署到 AKS 工作器节点。Work with your cluster operator to deploy the Secrets Store CSI Driver onto AKS worker nodes. 可使用 Pod 托管标识来请求访问 Key Vault,并通过机密存储 CSI 驱动程序检索所需的机密内容。You can use a pod managed identity to request access to Key Vault and retrieve the secret contents needed through the Secrets Store CSI Driver.

具有机密存储 CSI 驱动程序的 Azure Key Vault 可用于需要 Kubernetes 1.16 或更高版本的 Linux 节点和 Pod。Azure Key Vault with Secrets Store CSI Driver can be used for Linux nodes and pods which require a Kubernetes version of 1.16 or greater.

后续步骤Next steps

本文重点介绍了如何保护 Pod。This article focused on how to secure your pods. 若要实施其中某些做法,请参阅以下文章:To implement some of these areas, see the following articles: