Azure Kubernetes 服务 (AKS) 中应用程序和群集的安全性相关概念
容器安全保护整个端到端管道,从生成到在 Azure Kubernetes 服务 (AKS) 中运行的应用程序工作负载。
安全供应链包括生成环境和注册表。
Kubernetes 包括安全组件,如 Pod 安全标准和机密。 Azure 包括 Active Directory、Microsoft Defender for Containers、Azure Policy、Azure Key Vault、网络安全组和协调群集升级等组件。 AKS 结合这些安全组件,以便:
- 提供完整的身份验证和授权案例。
- 应用 AKS 内置的 Azure Policy 来保护你的应用程序。
- 使用适用于容器的 Microsoft Defender 获取从生成到应用程序的端到端见解。
- 让 AKS 群集一直运行最新的 OS 安全更新和 Kubernetes 版本。
- 为敏感凭据提供安全的 pod 流量和访问。
本文介绍用于保护 AKS 中应用程序的核心概念。
生成安全性
作为供应链的入口点,在将映像生成提升至管道之前,对其进行静态分析非常重要。 这包括漏洞和合规性评估。 并不是因为存在漏洞而导致生成失败,因为那样会破坏开发。 而是要根据开发团队可以采取行动的漏洞看待“供应商状态”以进行细分。 还可以使用“宽限期”,让开发人员有时间修正已识别的问题。
注册表安全性
评估注册表中映像的漏洞状态会检测偏移并捕获并非来自你的生成环境的映像。 使用 Notary V2 将签名附加到映像,以确保部署来自受信任的位置。
群集安全性
在 AKS 中,Kubernetes 主组件是 Microsoft 提供、管理和维护的托管服务的一部分。 每个 AKS 群集都有自己的单租户专用 Kubernetes 主机,以提供 API 服务器、计划程序等。有关详细信息,请参阅 Azure Kubernetes 服务的漏洞管理。
默认情况下,Kubernetes API 服务器使用公共 IP 地址和完全限定域名 (FQDN)。 可以使用经授权的 IP 范围将访问范围限制为 API 服务器终结点。 还可以创建完整的专用群集,以限制 API 服务器对虚拟网络的访问。
可使用 Kubernetes 基于角色的访问控制 (Kubernetes RBAC) 和 Azure RBAC 控制对 API 服务器的访问。 有关详细信息,请参阅 Microsoft Entra 与 AKS 集成。
节点安全性
AKS 节点是由你管理和维护的 Azure 虚拟机 (VM)。
- Linux 节点运行 Ubuntu 或 Azure Linux 的优化版本。
- Windows Server 节点使用
containerd
容器运行时运行已优化的 Windows Server 2022 版本。
创建或纵向扩展了 AKS 群集时,会自动使用最新的 OS 安全更新和配置来部署节点。
注意
正在运行的 AKS 群集:
- Linux 节点池的 Kubernetes 1.19 版本及更高版本使用
containerd
作为其容器运行时。 Windows Server 2019 和 Windows Server 2022 节点池使用containerd
作为其容器运行时。 有关详细信息,请参阅使用containerd
添加 Windows Server 节点池。 - Kubernetes 版本 1.19 及更早版本 - Linux 节点池使用 Docker 作为其容器运行时。
有关 Linux 和 Windows 工作器节点的安全升级过程的详细信息,请参阅安全修补节点。
节点授权
节点授权是一种特殊用途的授权模式,专门授权 kubelet API 请求以防御东-西攻击。 AKS 1.24 + 群集上默认启用节点授权。
节点部署
系统将节点部署到专用虚拟网络子网中,且不分配公共 IP 地址。 为进行故障排除和管理,默认启用 SSH,并只能使用内部 IP 地址进行访问。 禁用 SSH 是在群集和节点池创建期间,或者对于现有群集或节点池,处于预览状态。 有关详细信息,请参阅管理 SSH 访问。
节点存储
为提供存储,节点使用 Azure 托管磁盘。 Azure 托管磁盘是由高性能 SSD 支持的高级磁盘,适用于大多数规模的 VM 节点。 托管磁盘上存储的数据在 Azure 平台内会自动静态加密。 为提高冗余,会在 Azure 数据中心内安全复制 Azure 托管磁盘。
恶意多租户工作负荷
目前,Kubernetes 环境并不安全,因为可能存在恶意多租户使用情况。 其他安全性功能(如 Pod 安全策略或用于节点的 Kubernetes RBAC)可有效阻止攻击。 若要在运行恶意多租户工作负荷时获得真正的安全性,应只信任虚拟机监控程序。 Kubernetes 的安全域成为整个群集,而不是单个节点。
对于这些类型的恶意多租户工作负荷,应使用物理隔离的群集。 有关如何隔离工作负载的详细信息,请参阅 AKS 中的群集隔离最佳做法。
计算隔离
由于合规性或法规要求,某些工作负载可能需要与其他客户工作负载高度隔离。 对于这些工作负荷,Azure 提供:
- 内核隔离容器,用作 AKS 群集中的代理节点。 这些容器完全与特定的硬件类型隔离,并独立于 Azure 主机结构、主机操作系统和虚拟机监控程序。 它们专用于单个客户。 创建 AKS 群集或添加节点池时,请选择其中一个独立 VM 大小作为节点大小。
- 机密容器(预览版),也基于 Kata 机密容器,加密容器内存,并在计算过程中阻止内存中的数据采用明文、可读格式和篡改。 它帮助将容器与其他容器组/Pod 以及 VM 节点 OS 内核隔离开来。 机密容器(预览版)使用基于硬件的内存加密 (SEV-SNP)。
- Pod 沙盒(预览版)在容器应用程序与容器主机的共享内核和计算资源(CPU、内存和网络)之间提供隔离边界。
网络安全性
如需实现本地网络的连接和安全性,可将 AKS 群集部署到现有 Azure 虚拟网络子网。 这些虚拟网络通过 Azure 站点到站点 VPN 或 Express Route 连接回本地网络。 使用专用的内部 IP 地址定义 Kubernetes 入口控制器,以限制服务对内部网络连接的访问。
Azure 网络安全组
为筛选虚拟网络流量流,Azure 使用网络安全组规则。 这些规则定义要允许或拒绝哪些源和目标 IP 范围、端口和协议访问资源。 会创建默认规则以允许 TLS 流量流向 Kubernetes API 服务器。 创建具有负载平衡器、端口映射或入口路由的服务。 AKS 会自动修改流量流的网络安全组。
如果为 AKS 群集提供自己的子网(无论是使用 Azure CNI 还是 Kubenet),请不要修改 AKS 管理的 NIC 级网络安全组。 请改为创建更多子网级网络安全组来修改流量流。 请确保它们不会干扰管理群集所需的流量,比如负载均衡器访问、与控制平面的通信或流出量。
Kubernetes 网络策略
为了限制群集中 Pod 之间的网络流量,AKS 提供了对 Kubernetes 网络策略的支持。 使用网络策略,可以基于命名空间和标签选择器来允许或拒绝群集中的特定网络路径。
应用程序安全性
为了保护在 AKS 上运行的 Pod,请考虑使用 Microsoft Defender for Containers 来检测和限制针对在 Pod 中运行的应用程序的网络攻击。 运行持续扫描以检测应用程序漏洞状态的偏移,并实施“蓝/绿/金丝雀”流程来修补和替换易受攻击的映像。
保护容器对资源的访问
与应该向用户或组授予所需最少权限的方式一样,也应将容器限制为只能访问它们所需的操作和进程。 为了尽量减少攻击风险,避免配置需要提升的权限或 root 访问权限的应用程序和容器。 建议使用内置 Linux 安全功能(如 AppArmor 和 seccomp)作为最佳做法,以 [保护容器对资源的访问][secure-container-access]。
Kubernetes 机密
通过 Kubernetes 机密,将敏感数据注入到 pod,例如访问凭据或密钥。
- 使用 Kubernetes API 创建机密。
- 定义 pod 或部署,并请求特定机密。
- 机密只会提供给具有需要它们的计划 pod 的节点。
- 机密存储在 tmpfs 中,而不是写入磁盘。
- 删除节点上最后一个需要机密的 Pod 后,会从节点的 tmpfs 中删除机密。
- 机密存储在给定的命名空间中,只有同一命名空间中的 Pod 能访问该机密。
使用机密会减少 pod 或服务 YAML 清单中定义的敏感信息。 可以请求存储在 Kubernetes API 服务器中的机密,作为 YAML 清单的一部分。 此方法仅为 pod 提供特定的机密访问权限。
注意
原始机密清单文件包含 base64 格式的机密数据。 有关详细信息,请参阅官方文档。 将这些文件视为敏感信息,切勿将其提交到源代码管理。
Kubernetes 机密存储在分布式键值存储 etcd 中。 AKS 对 etcd 存储进行完全管理,并且数据在 Azure 平台中静态加密。
后续步骤
若要开始为 AKS 群集提供保护,请参阅升级 AKS 群集。
如需相关的最佳做法,请参阅 AKS 中群集安全性和升级的最佳做法和 AKS 中的 Pod 安全的最佳做法。
有关核心 Kubernetes 和 AKS 概念的详细信息,请参阅: