浅谈K8s安全 | 长亭百川云

Kubernetes，简称K8s，相信看这篇文章的朋友，应该都不会太陌生，最近正好研究了一下这个东西，根据网上和自己的一些研究，简单对这个东西的安全性以及可能存在的安全问题，进行个总结。

一 K8s 架构

整体的架构如下图所示，

K8s 整体可以分为控制节点（Master）与工作节点（Node)两部分。Master 节点又包括如下组件：apiserver，etcd，scheduler，contorller-manager。各个组件的功能里就不作太多介绍详情可以参考K8s各组件介绍：

二 K8s常见的安全问题

2.1 未授权访问

这是笔者认为最不应该或者最愚蠢的错误类型，包括且不限于因为各种五花八门的弱口令，配置错误导致的apiserver，kubectl，etcd等可以直接访问，或者得通过各种方式拿到到kubeconfig的配置文件，这样的后果便是使得整个K8集群彻底沦陷。

例如kubectl，默认情况下访问是未授权状态：

但如果修改了某个节点的config.yaml配置文件，将匿名认证打开：

再次访问则会出现信息泄露：

甚至可以在对应的宿主机的容器中进行命令执行：

因此需要尽量在日常的应用运维中犯下类似这样的错误。常见的组件对应的端口如下：

2.2 特权容器

这也是运维中可能出现的情况，如下图配置，在运维过程中为了某种原因，把容器配置为特权模式:

这样，万一这个容器失陷，便可以通过挂载宿主机目录，操作宿主机的文件，例如/root/.ssh/authorized_keys, crontab 等等，达到控制宿主机，进行逃逸。

除此之外，容器的一些特殊能力的赋予也需要慎重，例如CAP_SYS_PTRACE，便是拥有着追踪进程的能力，这样有可能通过strace等命令捕获SSH密码：

CAP_SYS_ADMIN，允许执行系统管理任务例如加载或卸载文件系统，基本等同于特权容器，也需要谨慎赋予。

其他容器能力介绍可以使用命令 man capabilities 进行参考。

2.3 挂载宿主机的重要目录

与2.2类似，尽量不要挂载宿主机的重要目录，例如/root ,/etc ,/porc等目录，毕竟这些目录都存有系统的重要信息，如果攻击者进入到容器内，便可能通过操作某些文件，达到容器逃逸的目的。

2.4 容器自身安全

因为容器本身与宿主机共享内核，那么便可以通过内核漏洞进入宿主机的namespace，从而达到逃逸的目的，最典型的应该算脏牛漏洞（CVE-2016-5195）。

2.5 容器内应用安全

容器内的应用本身也存在各种安全问题，例如命令执行，SQL注入，文件上传，rce等等，与传统安全一致，所以这里就不用再进行展开了。当然，如果通过某种漏洞进入到应用pod中，在没有网络隔离的情况下，便可以面向整个K8S集群进行进一步攻击了。

2.6 容器镜像安全

这也比较容易理解，例如使用了有漏洞的镜像，或者使用了被投毒的镜像，或者带有后门的镜像等等类似供应链攻击。

2.7 K8s本身组件的漏洞及第三方组件的漏洞

K8s本身拥有着非常众多的组件，因此非常有可能因为某些组件出现漏洞从而导致整个集群沦陷的可能。

2.8 一些管理平台

除了官方的Dashborad外，还有很多的K8s管理平台，例如Rancher ,KubeCube，KubeSphere 等等，这些平台除了未授权访问，弱口令外，本身也可能存在其他漏洞，一旦出现安全问题，也可能导致整个集群失陷。

2.9 其他问题

例如某些功能，本意是想为运维提供方便，但被发现，可以利用控制集群的情况，类似system函数。

三关于K8s的一些安全实践

个人觉得，K8s使用了这么长时间，只要做到了安全里边的最小授权原则，做好网络控制与准入，做好资源的用量规划，除pod应用与自身组件产生的安全问题外，基本不会出现太多的安全问题。当然，审计与安全工具也十分重要，例如我之前推荐的两款工具Falco—云原生安全守护者，

NeuVector----功能丰富且强大的容器安全开源软件，大到整体集群，小到单个容器，都可以进行监控。

四一点感悟