K8S 安全军规 101：对 CNCF 最佳实践的扩充

在昨天的文章里，我们分享了 CNCF 为广大 Kubernetes 用户建议的9项Kubernetes安全最佳实践，分享了用户使用 Kubernetes 管理集群时的 9 个能进一步确保集群安全的基本操作。

昨天文章中的建议非常好，但不足之处在于它们都过于依赖 GKE 了。对于那些使用谷歌服务的用户来说，GKE 固然是一个很好的解决方案。然而，还有更多的人则是在亚马逊、Azure、阿里云、华为云、DigitalOcean、甚至是他们自己的基础设施上或其他他们任何想在的地方上运行着 Kubernetes 集群，那么此时,GKE 相关的解决方案对他们而言并没有太大帮助。

对于这些用户而言，Rancher 作为一个开源的解决方案，是一个很棒的选择。

Rancher Labs 对待安全问题十分严肃谨慎。Rancher Labs 联合创始人及首席架构师 Darren Shepherd，是 2018 年年底 Kuberntes 被爆出的首个严重安全漏洞（CVE-2018-1002105）的发现者。安全性不应该是事后的想法，也不应该是部署了不安全的集群之后才记得要去做的事。就像你建造房子时，不应该把所有物品都搬进去之后，才开始安装门锁。

在本文中，我将回顾上篇文章中CNCF提出的每个要点，并向您分析 Rancher 和 RKE 能如何在默认设置中满足这些安全建议。

升级到最新版本

这是一个合理的建议，并且不仅适用于 Kubernetes。因为未修补的程序常常是攻击者的切入点。当某个安全漏洞出现、poc 代码公开可用时，Metasploit 之类的工具套件很快就会在其标准套件中包含这些漏洞。此时，任何会从 Internet 复制和粘贴命令的人都可以控制您的系统。

使用 Rancher Kubernetes Engine（RKE）时，无论是单独使用还是和 Rancher 一起使用，您都可以选择要安装的 Kubernetes 版本。Rancher Labs 使用原生上游 Kubernetes，这使公司能够快速响应安全警报，发布修复版本的软件。因为 RKE 是在 Docker 容器中运行 Kubernetes 组件的。运维团队可以对关键基础架构进行零停机升级。

您可以通过 Rancher 的 GitHub 主页、微信公众号、官网等各个渠道接收有关新版本发布的信息。我还强烈建议您在升级之前，先在 staging 环境中测试新版本。如果升级出错，Rancher 也可以轻松回滚到以前的版本。

启用基于角色的访问控制（RBAC）

安装 RKE 后，RBAC 会默认启动。如果您只使用 RKE 或任何其他独立的 Kubernetes 部署，则您需要负责配置帐户、角色和绑定以保护您的集群。

如果您正在使用 Rancher，它不仅会安装安全集群，还会通过 Rancher 服务器，代理与这些集群的所有通信。Rancher 可以插入许多后端身份验证程序，例如 Active Directory、LDAP、SAML、Github 等。当以这种方式连接时，Rancher 使您能够将现有的企业身份验证扩展到 Rancher 的保护伞下的所有 Kubernetes 集群，无论这些集群在哪里运行。

Rancher 在全局、集群和项目级别启用角色，使管理员可以在一个位置定义角色并将其应用于所有集群。这种 RBAC-by-default 和强大的身份验证和授权控制的组合意味着从使用 Rancher 或 RKE 部署集群的那一刻起，集群就是安全的。

使用命名空间建立安全边界

由于 Kubernetes 处理默认命名空间的特殊方式，我不建议您使用它。我建议您为每个应用程序创建一个命名空间，将它们定义为逻辑组。

Rancher 定义了一个名为 Project 的附加抽象层。Project 是命名空间的集合，可以在其上映射角色。用户可能有权访问某一 Project，但他们无法看到任何他们无权访问的 Project 中运行的任何工作负载，也无法与其进行交互。这样一来，其实就是有效地创建了单集群多租户。

使用 Projects，管理员可以更轻松地授予对单个集群中多个命名空间的访问权限。它最大限度地减少了重复配置以及人为错误。

将敏感工作负载彼此分开

这是一个很好的建议，因为它假定了一个问题，“如果工作负载受到损害会发生什么？”。提前采取行动可以减少破坏地范围使攻击者更难以升级权限，但也并不是完全不可能。所以这可能得花费您额外的时间处理。

Kubernetes 允许您设置污点（taints）和容差（torlerations），从而控制可能部署 Pod 的位置。

Rancher 还允许您通过 Kubernetes 标签控制工作负载的调度。除了污点和容差之外，在部署工作负载时，您可以为主机设置 必须、应该 或 可以 具有的标签，这些标签会控制 Pod 的部署位置。 如果您的环境是静态的，您还可以将工作负载安排到特定节点。

安全的云元数据访问

该建议指出，敏感的元数据“有时可能被盗或被滥用”，但未能概述“何时”或“如何”的条件。上篇文章中提到了 Shopify 的赏金细节的泄露， 2018 年 12 月 13 日的北美 KubeCon 上提到了这一事件。虽然上篇文章指出 GKE 具有“元数据隐藏”的功能，但值得注意的是，在最开始泄露凭据的服务，正是 Google Cloud 元数据 API。

此外，没有任何证据显示任何其他云提供商存在相同的漏洞。

此漏洞可能存在的唯一位置是托管的 Kubernetes 服务，例如 GKE。如果您直接或通过 Rancher 将 RKE 部署到裸机或云计算实例上，您将最终得到一个无法通过云提供商的元数据 API 泄露凭据的集群。

如果您正在使用 GKE，我建议您激活此功能以防止任何凭据通过元数据服务泄漏。我还认为云提供商不应该将凭证嵌入到可通过 API 访问的元数据中。即使这样做是为了方便，但这是一种不必要的风险，可能会产生难以想象的后果。

创建和定义集群网络策略

直接部署或由 Rancher 部署的 RKE 集群默认使用 Canal，当然，您也可以选择 Calico 或 Flannel。Canal 和 Calico 都支持网络策略。当使用 Canal 作为网络提供商时，Rancher 部署的集群也支持 Project 网络策略。激活后，工作负载可以与其项目中的其他工作负载通信，而系统项目（包括入口控制器等集群范围的组件）可以与所有项目进行通信。

早期版本的 Rancher 默认启用 Project 网络策略，但这给一些不了解额外安全性的用户造成了混乱。因此，为了给用户提供最佳体验，此功能现在默认情况下已关闭，但如果您想启用，也可以在启动后轻松激活。

运行集群范围的 Pod 安全策略

Pod 安全策略（PSP）控制 Pod 必须具有某些功能和配置才能在集群中运行。例如，您可以阻止特权模式、主机网络或以 root 身份运行容器。通过 Rancher 或 RKE 安装集群时，您可以选择是否要默认启用受限制的 PSP。如果选择启用它，则您的集群将立即对工作负载权限强制实施强制限制。

受限制的和不受限制的 PSP 在 RKE 和 Rancher 中是相同的，因此它们在安装时激活的内容是一样的。Rancher 允许无限数量的额外 PSP 模板，所有这些都可以在全局范围内处理。管理员定义 PSP，然后将它们应用于 Rancher 管理的每个集群。与前面讨论的 RBAC 配置类似，它将安全配置保存在一个位置，并大大简化了策略的配置和应用。

加强节点安全

这不是 Kubernetes 特定的建议，而是一个很好的普适策略。当要与您无法控制的流量进行交互时（例如，在 Kubernetes 中运行的应用程序的用户点击量），应该让其在攻击面较小的节点上运行。此外，禁用和卸载不需要的服务也是必要的。还有，应该通过 SSH 限制 root 访问权限并需要 sudo 密码加密。在 SSH 密钥上使用密码短语，或使用 2FA、U2F 密钥或 Krypton 等服务将密钥绑定到用户拥有的设备。 以上这些是安全系统的基本标准配置示例。

除了受支持的 Docker 版本之外，Rancher 在主机上不需要其他。并且，RKE 只需要 SSH 访问，它将在继续安装 Kubernetes 之前安装 Kubernetes 支持的最新版本的 Docker。

如果您想进一步减少攻击面，可以了解一下 RancherOS，这是一个轻量级 Linux 操作系统，可以将所有进程作为 Docker 容器运行。System Docker 仅运行提供访问所需的最少数量的进程，并在用户空间中为实际工作负载运行 Docker 实例。

启用审核日志（Audit Logging）

Rancher 服务器可在 RKE 集群内部运行，因此除了 Kubernetes 审核日志之外，激活对服务器本身的 API 调用的审核日志也很重要。此日志将显示用户对任何集群执行的所有操作，包括发生的事件、执行操作的人员、执行操作的时间以及执行操作的集群。从有问题的服务器发送这些日志也很重要。Rancher 可以连接到 Splunk、Elasticsearch、Fluentd、Kafka 或任何系统日志端点，您可以从中生成可疑活动的仪表盘和警报。

有关为 Rancher 服务器启用审核日志的信息，请参阅我们的文档。

（https://rancher.com/docs/rancher/v2.x/en/admin-settings/api-audit-log/）

有关为 RKE 集群启用审核日志的信息，请参阅下一节。

保障安全行动正在进行中

真正保护 Kubernetes 集群需要 9 项以上的操作，Rancher 有一份安全强化指南（https://rancher.com/docs/rancher/v2.x/en/faq/security/）和一份自我评估指南（https://releases.rancher.com/documents/security/latest/Rancher_Benchmark_Assessment.pdf），涵盖了 CIS 基准用于保护 Kubernetes 的 100 多种控制。

如果您十分在意安全性，那么 Rancher、RKE 以及 RancherOS 将会帮助您。