你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

有关 Azure Kubernetes 服务 (AKS) 中的群集安全性和升级的最佳做法

在 Azure Kubernetes 服务 (AKS) 中管理群集时,关键是要确保工作负荷和数据的安全性。 在使用逻辑隔离运行多租户群集时,尤其需要保护对资源和工作负荷的访问。 通过应用最新的 Kubernetes 和节点 OS 安全更新来最大程度地降低攻击风险。

本文重点介绍如何保护 AKS 群集。 你将学习如何执行以下操作:

  • 使用 Microsoft Entra ID 和 Kubernetes 基于角色的访问控制 (Kubernetes RBAC) 来保护对 API 服务器的访问。
  • 保护容器对节点资源的访问。
  • 将 AKS 群集升级到最新的 Kubernetes 版本。
  • 使节点保持最新状态并自动应用安全修补程序。

还可以阅读有关容器映像管理Pod 安全性的最佳做法。

启用威胁防护

最佳实践指南

可以启用 Defender for Containers 来帮助保护容器。 Defender for Containers 可以评估群集配置并提供安全建议、运行漏洞扫描,并为 Kubernetes 节点和群集提供实时保护和警报。

保护对 API 服务器和群集节点的访问

最佳实践指南

要保护群集,最重要方法的一种方法是保护对 Kubernetes API 服务器的访问。 要控制对 API 服务器的访问,需要将 Kubernetes RBAC 与 Microsoft Entra ID 集成。 借助这些控制,可以像保护对 Azure 订阅的访问一样保护 AKS。

Kubernetes API 服务器为在群集中执行操作的请求提供单一连接点。 若要保护和审核对 API 服务器的访问,请限制访问权限并尽量提供最低权限级别。 虽然这种方法并不是 Kubernetes 独有的,但它在将 AKS 群集进行逻辑隔离以供多租户使用时特别重要。

Microsoft Entra ID 提供可与 AKS 群集集成的企业级标识管理解决方案。 由于 Kubernetes 不提供标识管理解决方案,因此你可以按粒度限制对 API 服务器的访问。 借助 AKS 中与 Microsoft Entra 集成的群集,可以使用现有用户和组帐户向 API 服务器验证用户身份。

AKS 群集的 Microsoft Entra 集成

使用 Kubernetes RBAC 和 Microsoft Entra ID 集成,你可保护 API 服务器并提供限定范围的资源集(例如单个命名空间)所需的最少权限。 可以向不同的 Microsoft Entra 用户或组授予不同的 Kubernetes 角色。 借助这些细化的权限,可以限制对 API 服务器的访问,并提供已执行操作的清晰审核线索。

推荐的最佳做法是使用组来提供对文件和文件夹的访问,而不是使用个人标识。 例如,使用 Microsoft Entra ID 成员身份(而不是单个用户)将用户绑定到 Kubernetes 角色。 当某个用户的组成员身份发生变化时,该用户对 AKS 群集的访问权限也会相应发生变化。

同时,假设你将单个用户直接绑定到某个角色,并且用户的职责功能发生了变化。 虽然 Microsoft Entra 组成员身份会更新,但他们对 AKS 群集的权限不会更新。 在这种情况下,该用户最终获得的权限将超过其所需要的权限。

有关 Microsoft Entra 集成、Kubernetes RBAC 和 Azure RBAC 的详细信息,请参阅有关 AKS 中身份验证和授权的最佳做法

限制对实例元数据 API 的访问

最佳实践指南

在所有用户命名空间中添加一个网络策略以阻止 Pod 流出到元数据终结点。

注意

若要实现网络策略,请在创建 AKS 群集时包括 --network-policy azure 属性。 使用以下命令创建群集:az aks create -g myResourceGroup -n myManagedCluster --network-plugin azure --network-policy azure --generate-ssh-keys

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-instance-metadata
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.10.0.0/0#example
        except:
        - 169.254.169.254/32

保护容器对资源的访问

最佳实践指南

限制对容器可以执行的操作的访问。 提供最少的权限,并避免使用 root 访问权或特权提升。

与应该向用户或组授予所需最少权限的方式一样,也应将容器限制为只能访问它们所需的操作和进程。 为了尽量减少攻击风险,避免配置需要提升的权限或 root 访问权限的应用程序和容器。

若要更精确地控制容器操作,还可以使用内置 Linux 安全功能,例如 AppArmorseccomp。 有关详细信息,请参阅保护容器对资源的访问

定期更新到最新的 Kubernetes 版本

最佳实践指南

若要及时了解新功能和 bug 修复,请定期升级 AKS 群集中的 Kubernetes 版本。

与更传统的基础结构平台相比,Kubernetes 发布新功能的速度更快。 Kubernetes 更新包括:

  • 新增功能
  • Bug 或安全修补程序

新功能在变得稳定之前通常会经历 alphabeta 状态。 稳定后,将正式发布,并建议用于生产环境。 在 Kubernetes 新功能发布周期内,你可以对 Kubernetes 进行更新,而不会经常遇到中断性变更,也无需调整部署和模板。

AKS 支持三个 Kubernetes 次要版本。 引入新的次要版本补丁后,将停止对最早次要版本和修补程序版本的支持。 系统会定期进行次要 Kubernetes 更新。 若要保持在支持范围内,请确保你具有检查必要升级的管理过程。 有关详细信息,请参阅支持的 Kubernetes 版本 AKS

若要检查可用于群集的版本,请使用 az aks get-upgrades 命令,如以下示例所示:

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table

然后,可以使用 az aks upgrade 命令升级 AKS 群集。 升级过程安全性:

  • 一次在一个节点上进行隔离和排空。
  • 计划剩余节点上的 pod。
  • 部署运行最新 OS 和 Kubernetes 版本的新节点。

重要

在开发测试环境中测试新的次要版本,并使用新的 Kubernetes 版本验证你的工作负载是否正常运行。

Kubernetes 可能会弃用 API(如工作负载所依赖的版本 1.16)。 将新版本投入生产时,请考虑在单独的版本上使用多个节点池,并一次升级一个池,从而循序渐进地在整个群集中滚动更新。 如果运行多个群集,则每次升级一个群集,从而循序渐进地监视影响或更改。

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version KUBERNETES_VERSION

有关 AKS 中的升级的详细信息,请参阅 AKS 中支持的 Kubernetes 版本升级 AKS 群集

处理 Linux 节点更新

每天晚上,AKS 中的 Linux 节点都会通过其发行版更新通道获得安全补丁。 当在 AKS 群集中部署节点时,会​​自动配置此行为。 为了尽量减少对正在运行的工作负荷的中断和潜在影响,AKS 不会在安全修补程序或内核更新需要进行重启时自动重启节点。 有关如何处理节点重启的详细信息,请参阅将安全更新和内核更新应用于 AKS 中的节点

节点映像升级

无人参与的升级将更新应用于 Linux 节点 OS,但用于为群集创建节点的节点映像保持不变。 如果将新的 Linux 节点添加到你的群集,则原始映像将用于创建节点。 这个新节点将在每晚自动检查期间接收所有可用的安全更新和内核更新,但在所有检查和重启完成之前将保持未修补状态。 可以使用节点映像升级来检查和更新群集使用的节点映像。 有关节点映像升级的详细信息,请参阅 Azure Kubernetes 服务 (AKS) 节点映像升级

处理 Windows 服务器节点更新

对于 Windows 服务器节点,定期执行节点映像升级操作,以安全隔离和排空 Pod 并部署更新后的节点。