Kubernetes的五种安全实践
|
Kubernetes还不到6岁，但它已经是每个人最喜欢的容器编排程序了。云和基础设施监测公司Datadog发现Kubernetes主导着容器市场：“大约45%的运行容器的Datadog客户使用Kubernetes。”其他容器编排程序，如Marathon和Docker swarm已经退出。 Kubernetes在公有云上更受欢迎。例如，根据Datadog的统计，“大约80%在Azure中运行容器的Datadog客户现在都在使用Kubernetes”。在亚马逊网络服务(AWS)上，Datadog发现它的受欢迎程度在过去两年翻了一番，达到了45%。 人气越高危险就越大。Windows用户深知，一个程序越受欢迎，就越容易受到攻击。Kubernetes也是如此。如果你在使用它，你必须保护它。 但是这并不容易。 Kubernetes的管理组织Cloud Native Computing Foundation(CNCF)最近对Trail of Bits和Atredis合作伙伴进行安全审计。Bits的报告说，Kubernetes存在许多安全问题，这是因为Kubernetes的配置和部署并不简单，某些组件的默认设置容易让人混肴，同时缺少操作控制以及隐式设计的安全控制。” 由此可见，这真的不容易。 不过，我们必须尝试。这是我们如何保证Kubernetes安全的前五种方法。 1.确保容器本身安全 如果容器损坏，保护Kubernetes并没有任何好处。开源安全公司Snyk在2019年分析了10个最受欢迎的Docker镜像。他们发现所有映像都包含易受攻击的系统库。 正如VMware副总裁兼首席开源官Dirk Hohndel 在2019年开源领袖峰会上所说的那样：“容器打包格式类似于Windows中的.exe和macOS中的.dmg，基本上你可以发布一个包含所有依赖项的完整文件系统。由于您现在将这些依赖项包含在容器中，因此您必须关注这些二进制文件用途，产生方式以及相应的来源。“ 简而言之，您必须先确定容器的内容是可信任的，然后再将其部署给Kubernetes进行管理。否则，您将遇到最常见的计算机问题之一：垃圾回收(GIGO)。因此，您别无选择，只能检查每个生产容器是否存在潜在的安全问题。 是的，很痛苦。从来没有人说过安全是容易的。 2.锁定容器的Linux内核 从本处开始只会越来越困难。除了确保容器是安全的以外，由于所有容器都运行在单个Linux内核上，因此确保该内核尽可能安全是有意义的。而且，推荐使用AppArmor或SELinux进行安全配置，保护内核。 但是，这些复杂的配置限制了用户控制，程序管理，文件访问和系统维护。他们将其作为Linux安全模块来执行，该模块在Linux上强加了强制性访问控制(MAC)体系结构。对于Linux的内置安全模型(除非明确禁止，否则允许一切)，这是一种完全不同的安全方法(除非明确允许，否则限制一切)。 很多系统管理员都无法正确设置两者。更糟糕的是，如果您配置错误，那这就不仅仅是一个重新配置的过程。如果您配置不对，您的Linux系统将被冻结，而您将不得不重新进行调整。或者，您可能认为它的配置是正确的，但是实际上您的容器可能仍然会像以前一样受到攻击。 正确以及安全的配置需要操作人员的大量时间和专业知识。在AppArmor或SELinux保护的内核上运行应用程序可能会遇到困难。大多程序对底层操作系统采取了安全措施。这些受保护的内核不允许这样做。 如果这两种方法中的任何一种被证明是太麻烦了，那么您可以通过阻止内核自动加载内核模块来获得一些保护。例如，由于即使是非特权进程也可以强制加载一些与网络协议相关的内核模块，只需创建一个特定的网络套接字，就可以添加规则来阻止有问题的模块。您可以使用禁止的模块配置文件来执行此操作： /etc/modprobe.d/kubernetes-blacklist.conf 文件中记得加入配置说明，例如： #SCTP在大多数Kubernetes集群中不使用，并且也有漏洞。 不过，最好的方法还是安装AppArmor或SELinux。 3.使用基于角色的访问控制(RBAC) 从Kubernetes1.8开始，您可以使用RBAC来控制用户可以做什么。这一点很重要，因为试图将运行在数十个实例和集群上的用户混为一谈来提供服务是非常恐怖的。使用RBAC，零信任安全方法，用户和组件(如应用程序和节点)只需要获得完成任务所需的权限。 RBAC在应用程序编程接口(API)级别上工作。这样，即使不使用授权者本身，RBAC规则也会锁定用户。RBAC还阻止用户通过编辑角色或角色绑定为自己提供更多特权。 默认情况下，它也会阻止外来者。RBAC策略向控制平面组件、节点和控制器授予作用域权限。但是，这一点很重要，它不向kube-system namespace之外的服务帐户授予任何权限。 为了便于管理Kubernetes，RBAC提供了预定义的角色。这样，开发人员、操作员和集群管理员只需获得他们所需的权限，而不需要任何用不到的权限。 在这个系统中，cluster admin角色相当于Unix和Linux的超级用户。群集管理员可以创建、编辑或删除任何群集资源。不用说，必须小心保护群集管理员角色的访问权限。 4.保守秘密的辛勤工作 Kubernetes Secrets对象包含敏感元素，例如密码，OAuth令牌或ssh密钥。简而言之，它们是Kubernetes集群的钥匙。您必须保护好他们。 Kubernetes会自动创建用于访问API的机密，并修改您的Pod以使用它们。但是，您的secrets(例如Pod访问数据库所需的用户名和密码)则在您的控制和保护之下。 很简单吧?不幸的是，Kubernetes的secrets带有许多内置的安全漏洞。官方所列出的漏洞简直令人恐惧。 在API服务器，secret数据被存储在ETCD，Kubernetes默认使用分布式key-value存储。默认情况下，etcd数据不加密，因此您的secrets也不加密。因此，您必须启用静态加密并限制对admin用户的etcd访问。 许多用户将其机密信息保存在JSON或YAML文件中。在这里，机密数据被编码(未加密)为base64。这意味着如果您共享配置文件或将其提交到代码仓库中，其他人则可以读取您的所有secrets。 一旦应用程序使用了secret，就将不允许该应用程序对其进行记录或将其传输给不受信任的一方。 一个可以创建使用secret的Pod的用户也可以看到这个secret的值。即使API服务器策略不允许该用户读取它，用户也可以运行一个Pod，这会暴露secret。 当前，在任何节点上具有root权限的任何人都可以通过模拟kubelet来从API服务器读取任何secret。这实际上是一个特性。其思想是，通过只与需要它们的节点共享secret，可以将根攻击对单个节点造成的损害限制在一个节点上。 （编辑：应用网_阳江站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
