在上篇文章里，我们分享了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将会帮助您。
原文地址：http://blog.51cto.com/12462495/2347458