Kubernetes，简称K8s，相信看过本文的同学应该不会太陌生。 我最近才研究这个东西。 根据网上和自己的一些研究，简单的了解了这个东西的安全性以及可能出现的安全问题。 做个总结。
K8s架构
整体结构如下图所示，
K8s整体上可以分为两部分：控制节点（Master）和工作节点（Node）。 Master节点还包括以下组件：apiserver、etcd、scheduler、contorller-manager。 各个组件的功能就不过多介绍了。 详细可以参考K8s各组件的介绍：
cn/docs/concepts/overview/components/
两个K8常见的安全问题
2.1 未经授权的访问
这是笔者认为最不恰当或者最荒唐的一类错误，包括但不限于各种弱口令和配置错误导致的apiserver、kubectl、etcd可以直接访问，或者通过各种形式获取kubeconfig的配置文件，这样做的后果就是导致整个K8集群彻底崩溃。
例如kubectl，默认访问是未授权的：
但如果修改了某个节点的config.yaml配置文件，就会启用匿名认证：
重新访问会导致信息泄露：
甚至可以在对应宿主机的容器中执行命令：
因此，在日常的应用运维中，要尽量少犯这样的错误。 常用组件对应的端口如下：
K8S组件
默认端口
kube-api服务器
6443
库贝莱特
10250
等
2379, 2380
kube代理
10256
kube 控制器管理器
10252
kube 调度程序
10251
2.2 特权容器
这也是运维过程中可能出现的情况，如下图所示。 在运维过程中，由于某种原因，容器被配置为特权模式：
这样php 集群，如果容器入侵，可以通过挂载主机目录、操作主机的文件（如/root/.ssh/authorized_keys、crontab等）来控制主机并逃脱。
另外，容器的一些特殊能力也需要谨慎。 例如，CAP_SYS_PTRACE具有跟踪进程的能力，因此可以通过strace等命令捕获SSH密码：
CAP_SYS_ADMIN，允许加载或卸载文件系统等系统管理任务，基本上相当于一个特权容器，需要仔细分配。
其他容器能力介绍可以使用命令man Capability进行参考。
2.3 挂载主机重要目录
与2.2类似，尽量不要挂载主机的重要目录，如/root、/etc、/porc等，毕竟这些目录包含着系统的重要信息。 如果攻击者踏入容器，他可能通过操作单个文件来达到容器逃逸的目的。
2.4 容器本身安全
由于容器本身与宿主机共享内核，因此可以通过内核漏洞进入宿主机的命名空间，从而达到逃逸的目的。 最典型的应该是脏牛漏洞（CVE-2016-5195）。
2.5 容器中的应用安全
容器中的应用程序本身也存在各种安全问题，比如命令执行、SQL注入、文件上传、rce等，这些与传统安全一致，这里无需展开。 当然，如果通过某个漏洞进入应用程序pod，就可以在没有网络隔离的情况下对整个K8S集群进行进一步的攻击。
2.6 容器镜像安全
这也比较容易理解，比如使用有漏洞的镜像，或者使用有毒的镜像，或者带有侧门的镜像等等，类似于供应链攻击。
2.7 K8s自身组件的漏洞和第三方组件的漏洞
K8s本身组件数量极其庞大，特别有可能因为个别组件的漏洞而导致整个集群瘫痪。
2.8 一些管理平台
除了官方的Dashboard之外，还有很多K8s管理平台，比如Rancher、KubeCube、KubeSphere等，这些平台不仅存在未授权访问和弱密码的问题，还可能存在其他漏洞。 一旦出现安全问题，还可能引发整个集群的攻击。
2.9 其他问题
例如，有些功能本意是为了方便运维，但发现它们能够控制集群php 集群，类似于系统功能。
3 关于K8s的一些安全实践
在我看来，K8s用了这么久，只要做到安全上的最小授权原则，做好网络控制和访问，做好资源用量规划，除了以下带来的安全问题pod应用程序及其自身的组件，基本上不会出现太多的安全问题。 当然审计和安全工具也很重要，比如我之前推荐的两个工具，
大到整个集群，小到单个容器，都可以监控。
四点感受
本文参考腾讯安全2021年3月发表的《红蓝对抗中的云原生漏洞挖掘及其记录利用》（om/index.php/blog/msg/183），对K8s的研究为3和比我早半年。 这篇文章至今仍在我的收藏中。 从一开始的完全不懂，到现在能看懂，也很遗憾自己在K8s上有了一点进步，终于可以为这篇文章集画个圈了。
