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
,可以将根攻击对单个节点造成的损害限制在一个节点上。
这种情况很糟糕。你可以随时通过加密secrets
来缓解它。如果可能的话,你也应该把这个secret
与镜像或pod
分开。一种方法是将进程拆分为单独的容器。例如,可以将应用程序分为前端容器和后端容器。后端具有私钥secret
并响应来自前端的签名请求。
除非您既是安全管理员又是Kubernetes
管理员,否则必须使用第三方秘密工具来保护您的secret
。其中包括AWS Secrets Manager
,Google Cloud Platform KMS
和用于公共云的Azure Key Vault
。而且,程序如Hashicorp Vault,
CyberArk/Conjur
, Confidant
和Aqua Security Kubernetes Security for the Enterprise
。
5.保持网络安全
从上面可以看出,允许访问etcd
非常危险。正如Kubernetes
安全企业ControlPlane
的联合创始人Andrew Martin
在Kubernetes
自己的博客中写道:“ 对API
服务器的etcd
的写访问权限等同于在整个集群上获得root
权限,甚至可以很容易的使用读访问权限公平地提升特权。”
因此,Martin
建议:“ etcd
应该配置有peer
和客户端TLS
证书,并部署在专用节点上。为避免私钥被从工作节点窃取和使用,集群也可以通过防火墙连接到API
服务器。
不仅etcd
需要网络保护。由于Kubernetes
完全由API
驱动,因此默认情况下,所有内部集群通信均使用TLS
加密。
但是,这还不够。默认情况下,Kubernetes Pod
接受来自任何来源的流量。在此重复一遍:“任何来源。” Pod
已开放用于网络连接,这并不安全。由您决定网络策略,该策略可以安全地定义Pod如何在群集内以及与外部资源进行通信。
您可以通过添加支持网络策略控制器的网络插件来实现。如果没有这样的控制器,您设置的任何网络策略都不会生效。不幸的是,Kubernetes
默认没有官方默认甚至首选的网络策略控制器。相反,您必须使用第三方插件,如Calico
,Cilium
,Kube-router
,Romana
或Weave Net
。不管怎样,我最喜欢的是Calico
。
我建议您从**“默认拒绝所有**”网络策略开始。这样,仅允许您随后明确允许的与其他网络策略规则的连接。由于网络策略是在namespace
中设置的,因此您需要为每个namespace
设置网络策略。
设置完成后,您可以开始允许适当的网络访问规则。更多可以参考 【Kubernetes Network Policy Recipes】(https://github.com/ahmetb/kubernetes-network-policy-recipes)。
确保Kubernetes的安全是一项重要工作。
正如我在一开始所说的那样,保护Kubernetes
确实不是一件容易的事。到现在为止,我相信您现在是非常同意我这一说法。
Kubernetes
从一开始就被设计为易于部署。不幸的是,这也意味着它在设计上是不安全的。这意味着要增加安全性完全取决于您。幸运的是,增加安全性,则使你的Kubernetes
集群更具有生产价值。
本文只谈到了Kubernetes
安全需要解决的最重要的问题。当然还有很多其他的问题。但是,我真的希望我给了你足够的思路让你明白这工作有多重要。而且,您必须现在就开始保护Kubernetes
集群,否则黑客会毫不犹豫地提醒您,您已经将公司的重要系统暴露在危险之中。
译者:祝祥
原文:https://www.idginsiderpro.com/article/3571466/the-five-best-kubernetes-security-practices.html
了解新钛云服
当IPFS遇见云服务|新钛云服与冰河分布式实验室达成战略协议
新钛云服正式获批工信部ISP/IDC(含互联网资源协作)牌照
新钛云服,打造最专业的Cloud MSP+,做企业业务和云之间的桥梁
新钛云服出品的部分精品技术干货
刚刚,OpenStack 第 19 个版本来了,附28项特性详细解读!
OpenStack与ZStack深度对比:架构、部署、计算存储与网络、运维监控等