有关 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 服务器的访问，并提供已执行操作的清晰审核线索。

在 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

在 AKS 标准版中，请确保所选的网络模型和策略引擎支持此策略路径。

保护容器对资源的访问

最佳实践指南

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

正如你应仅向用户或组授予所需的最低权限一样，你也应将容器限制为仅执行必要的操作和进程。 为了尽量减少攻击风险，避免配置需要提升的权限或 root 访问权限的应用程序和容器。

使用用户命名空间，可以改进主机隔离，并在发生容器中断时限制横向移动。 无论 Pod 是否以 root 身份运行，这些改进都非常重要。

若要更精确地控制容器操作，还可以使用内置 Linux 安全功能，例如 AppArmor 和 seccomp。

即使 AKS 自动提供强化的默认值，工作负荷级安全控制仍保留应用程序和平台团队的责任。

有关详细信息，请参阅保护容器对资源的访问。

定期更新到最新的 Kubernetes 版本

最佳实践指南

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

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

  • 新增功能
  • 错误修复或安全修复

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

AKS 支持三个 Kubernetes 次要版本。 引入新的次要版本补丁后，将停止对最早次要版本和修补程序版本的支持。 系统会定期进行次要 Kubernetes 更新。 若要继续获得支持，请确保已建立治理流程，以检查是否需要进行必要的升级。 有关详细信息，请参阅支持的 Kubernetes 版本 AKS。

在 AKS 标准版中，运维人员可以更直接地选择和管控升级策略及发布时间安排。

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

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

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

  • 每次只对一个节点执行隔离和排空。
  • 将 pod 调度到剩余节点上。
  • 部署运行最新 OS 和 Kubernetes 版本的新节点。

重要

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

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

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

处理 Linux 节点更新

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

在 AKS 标准版中，操作员通常使用显式操作控制来定义修补程序和重新启动治理。

节点镜像升级

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

处理 Windows 服务器节点更新

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

相关内容

有关 AKS 和保护 AKS 群集的详细信息，请参阅以下文章：

  • Last updated on