通过

确保您的运营安全

作安全性对于保持对 Kubernetes 群集的控制并响应新兴威胁非常重要。 本文介绍管理访问、强制实施策略、监视活动以及响应事件的最佳做法。 通过实施强大的作控制，可以帮助确保只有经过授权的用户和进程才能对群集和工作负载进行更改。

控制谁可以使用 Azure 控制平面来管理群集

务必控制对 Azure 控制平面（包括订阅和用于通过 Azure Arc 管理边缘群集的资源）的访问。 查看并实现 Azure 访问控制最佳做法，包括多重身份验证和条件访问。 使用 Azure RBAC 控制谁可以对哪些群集执行哪些操作，这与您可能已经用于控制对其他 Azure 云资源访问权限的方式相同。

此外，Microsoft生成的证书用于帮助保护边缘群集与 Azure 控制平面之间的连接。 这些证书存储为 Kubernetes 机密，因此 Kubernetes 机密存储本身必须加密。

使用基于角色的访问控制（RBAC）控制谁可以部署到群集

控制对 Kubernetes 控制平面（API 服务器）本身的访问也很重要，这是可以部署和监视 Kubernetes 工作负载的方式。

若要从工作负载对 API 服务器进行非人访问，请使用 Kubernetes 的内置 RBAC 仅授权需要它的特定服务帐户。 另请参阅 有关发布和保护这些服务帐户的建议。

对于对 API 服务器的人工访问，Kubernetes 没有内置的用户帐户。 因此，我们建议将其与外部用户帐户服务（如 Microsoft Entra ID）集成。 然后，可以创建使用这些标识的授权策略来控制谁可以执行哪些命名空间。 可以使用 Kubernetes 的内置 RBAC 或使用 Azure RBAC 创作这些策略。 如果想要在一个中心位置一致地管理和审核所有用户授权策略，同时涵盖云和边缘资源，建议使用 Azure RBAC。 如果您在 Azure Local 上运行通过 Azure Arc 启用的 AKS，或者 连接自己的群集，则可以轻松使用 Azure RBAC。 然后，用户可以使用其 Entra ID 帐户直接或通过 Azure 代理使用“群集连接”功能访问群集（其 API 服务器）。 我们建议采用“最低特权”方法，以分配每个用户或工作负荷具有所需最低权限的角色。

更普遍地，遵循在分离开发、测试和生产群集方面的标准最佳做法。 考虑使用 GitOps 方法对群集进行生产部署，是否能使管理更加可靠和安全。 如果遵循此方法，则在基础源 Git 存储库和用于定义部署的分支上对更改（拉取请求）实现类似的基于角色的访问控制也很重要。

最后，如果在本地 Azure Arc 上运行由 Azure Arc 启用的 AKS，则还可以下载管理员客户端证书以获取完全管理员访问权限。 通常不需要使用此证书，因此，仅在需要时下载它：例如，诊断无法以任何其他方式调查的问题。 还应谨慎使用此方法，因为它不使用 Entra ID 帐户，也不应用您设置的每用户策略。 此外，必须仔细存储客户端证书，然后在不再需要时将其删除。

参考文献

使用适用于 Kubernetes 的 Azure Policy 部署和运行容器时，遵循安全的容器生命周期

继续在部署阶段遵循Microsoft容器安全供应链框架。 （另请参阅 获取、目录和生成阶段的指南。此框架仅帮助你从自己的受信任注册表（例如 Azure 容器注册表）进行部署。 使用注册表的访问控制机制来确保只有受信任的群集提取可能包含敏感信息的容器。 Azure 容器注册表支持 基于角色的访问控制（RBAC） 和 基于属性的访问控制（ABAC） 以进一步将分配范围分配给特定存储库。

此外，通过 Azure Policy 强制实施容器安全卫生的最佳做法标准。 例如，可以使用 Azure Policy 的内置定义验证所有 Pod 是否符合低代码方法中的 Pod 安全标准。 还可以将 Azure Policy 扩展（扩展 Gatekeeper）部署到 Kubernetes 边缘集群，以大规模进行基于 Pod 的安全策略实施。 建议首先在“审核”模式下应用策略分配。 此模式以每个 Kubernetes 资源、每个策略为粒度提供不合规的结果聚合列表，使你能够首先发现并修正当前运行的部署中存在的问题。 修复了环境中的不合规的冲突后，即可将策略分配更新为“拒绝”模式。 然后，Azure Policy 的丰富安全部署机制会逐步跨资源推出此策略强制实施。 通过在强制模式下应用策略，可以主动防止任何进一步的偏差。

参考文献

检测新出现的威胁，包括监视控制平面的变化

帮助确保你能够检测群集中出现的威胁。

可以将 Defender for Containers 扩展 部署到边缘的 Kubernetes 群集。 此扩展包括收集日志并将其发送到 Defender for Cloud 的 传感器 。 一旦到达那里，可以对其进行异常行为分析，这些行为可能表明攻击或用于可能事件后的取证工作。 请参阅支持矩阵，了解哪些功能在哪些类型的群集上受支持，是作为预览版还是正式发布版。 反过来，Defender for Cloud 可以发送事件进行分析，作为 Microsoft Defender XDR 事件检测和响应解决方案的一部分。

如果您在通过 Azure Arc 启用的 Azure 本地 AKS 上运行，还可以配置将 Kubernetes 审核日志发送到 Azure Monitor（Log Analytics 工作区）。 另请遵循监视工作负载本身的相关建议。 并查看监视群集 的最佳做法 ，其中涵盖了可靠性、成本优化、性能和安全性。

除了监视之外，还希望构建事件响应计划并练习使用它。 此类计划的详细信息在很大程度上取决于整个部署环境，以及你使用的安全作工具：有关详细信息，请参阅本指南。 但至少考虑如何保留群集的状态（保留审核日志、快照可疑状态），以及如何 将其恢复到已知良好状态。

参考文献

使用部署策略实现零停机时间更新

关键安全更新不应损害工作负荷的可靠性和可用性，即使紧急推出也是如此。 选择最有助于维护环境中的高可用性的 Kubernetes 部署策略 。 建议也实现就绪情况探测和运行情况探测，以便 Kubernetes 在维护部署时能够更好地了解工作负载的状态。 结合入口负载均衡器的逐步推出和流量管理策略，可以使用 Kubernetes 来驱动更新，而不会中断应用程序的可用性。

后续步骤