配置 Azure Kubernetes 服务 (AKS) 的网络隔离
在 Azure Kubernetes 服务 (AKS) 中管理群集时,通常需要隔离团队和工作负荷。 AKS 可让你灵活地运行多租户群集并隔离资源。 为了最大化 Kubernetes 的投资回报,了解 AKS 多租户和隔离功能至关重要。
设计多租户群集
通过 Kubernetes 在同一群集中以逻辑方式隔离团队和工作负载。 目标是提供最少的特权来覆盖所有团队所需的资源。 Kubernetes 命名空间创建逻辑隔离边界。 其他 Kubernetes 功能以及有关隔离和多租户的注意事项包括以下几个方面:
- 有关 Azure Kubernetes 服务 (AKS) 中的群集隔离的最佳做法
- 设计多租户群集
- 日程安排
- 网络
- 身份验证和授权
- 容器
- 设计多租户群集
- 逻辑隔离群集
- 物理隔离群集
日程安排
“计划”使用资源配额和 Pod 中断预算等基本功能。
更高级的计划程序功能包括:
- 排斥和容许。
- 节点选择器。
- 节点和 Pod 相关性和反相关性。
网络
“网络”使用用于控制传入和传出 Pod 的流量流的网络策略。
身份验证和授权
身份验证和授权使用:
- 基于角色的访问控制 (RBAC)。
- Microsoft Entra 集成。
- Pod 标识。
- Azure Key Vault 中的机密。
容器
容器包括:
- 适用于 AKS 的 Azure Policy 附加产品,用于强制执行 Pod 安全性。
- Pod 安全许可。
- 扫描映像和运行时中的漏洞。
- 使用 App Armor 或 Seccomp(安全计算)来限制容器对基础节点的访问。
逻辑隔离群集
最佳实践指导:使用逻辑隔离分隔团队和项目。 减少要部署的物理 AKS 群集数,以隔离团队或应用程序。
使用逻辑隔离,可将单个 AKS 群集用于多个工作负载、团队或环境。 Kubernetes 命名空间构成了工作负荷和资源的逻辑隔离边界。
群集的逻辑隔离提供的 Pod 密度通常比物理隔离的群集更高,而且群集中闲置的超额计算容量更少。 与 Kubernetes 群集自动缩放程序相结合,可根据需求增加或减少节点数目。 采用这种最佳做法,可以通过只运行所需数目的节点来尽量降低成本。
如果存在恶意多租户使用情况,则 Kubernetes 环境并不完全安全。 在多租户环境中,多个租户在共享基础结构上工作。 如果所有租户都不受信任,则需要额外的计划来防止租户影响其他部分的安全性和服务。
其他安全功能(如用于节点的 Kubernetes RBAC)可有效阻止攻击。 为了在运行恶意多租户工作负载时获得真正的安全性,应只信任虚拟机监控程序。 Kubernetes 的安全域成为整个群集,而不是单个节点。
对于这些类型的恶意多租户工作负荷,应使用物理隔离的群集。
物理隔离群集
最佳实践指导:对于每个独立的团队或应用程序部署,尽量减少使用物理隔离,并改用逻辑隔离。
物理隔离 AKS 群集是群集隔离的常用方法。 在此隔离模型中,将为团队或工作负荷分配其自身的 AKS 群集。 虽然物理隔离看上去是最简单的隔离工作负载或团队的方法,但会增加管理和财务开销。 对于物理隔离群集,必须维护多个群集,并单独提供访问权限和分配权限。 你还需要为每个单独的节点付费。
物理隔离群集的 pod 密度通常较低。 由于每个团队或工作负载具有自身的 AKS 群集,因此往往会为群集过度预配计算资源。 通常会在这些节点上计划少量的 pod。 未声明的节点容量不可由其他团队用于开发中的应用程序或服务。 这些超额的资源会导致物理隔离群集的成本增加。