保护平台是改善 Kubernetes 环境的整体安全性的基础。 本文重点介绍如何配置 Kubernetes 群集、其基础作系统和硬件基础结构，以更安全地运行。 利用内置功能和遵循最佳做法，可以帮助确保平台能够更灵活地应对威胁，并为工作负载和作提供更强大的基础。
随时了解最新的安全修补程序
建议在发布最新安全补丁时，升级您的群集和节点的操作系统。 因此，这意味着确保你的群集与发布修补程序的受支持的 Kubernetes 版本保持同步非常重要。 同样，使用受支持的 OS 版本使节点保持最新状态也很重要。
如果通过已启用 Arc 的 Kubernetes 连接自己的群集，请遵循供应商的指导使其保持最新状态，并为已启用 Arc 的 Kubernetes 代理 配置自动升级 ，以维护群集与 Azure 的连接。
还可以将 扩展 部署到群集：此安全手册的其他部分建议其中许多扩展，以便获得它们可带来的安全优势。 如果是这样，请为这些扩展配置自动升级。
参考文献
保护 Kubernetes 控制平面组件之间的通信
如果在 Azure 本地 Azure Arc 上运行 AKS，则传输层安全性（TLS）用于帮助保护控制平面组件（例如 API 服务器和 etcd）之间的所有跨节点通信。 TLS 证书会定期轮换。
如果通过已启用 Arc 的 Kubernetes 连接自己的群集，则确定节点之间的流量是否受到类似的保护。 按照供应商的指导，评估是否需要执行任何步骤来启用此保护（例如创建和更新证书）。
参考文献
- NIST 应用程序容器安全指南 - 第 4.3.5 节
- NSA Kubernetes 强化指南 - “加密”
- Kubernetes 安全性 - OWASP 备忘单系列 - “限制对 etcd 的访问”
保护对节点的直接访问
一般情况下，我们不建议直接访问群集的节点。 最好通过 API 服务器管理群集，Role-Based 访问控制（RBAC）可帮助控制哪些用户可以执行哪些作。 请参阅我们关于本主题 的进一步指南 。
因此，应默认禁用对工作节点的 SSH 访问。 但是，如果此访问权限确实是必需的，并且你在本地 Azure Arc 上运行 AKS，那么请务必仔细管理它。 创建群集时安全地存储 SSH 密钥，并将 SSH 访问限制为仅预期网络地址。 除了这种有限的例外之外，不应该有其他方法能够访问控制平面节点以及在其上运行的 Kubernetes 基础架构组件，例如 kube-scheduler、etcd、kubelet。
最后，由于边缘群集通常驻留在不安全的位置，因此请考虑适当的物理保护（锁定访问、防篡改措施等）。