云安全—docker Deamon攻击面
0x00 前言
本篇文章主要是讲docker Deamon的原理以及docker Deamon攻击面相关的内容，属于抛砖引玉系列，如有不妥之处还请斧正。
0x01 docker Deamon
还是先来看一下docker Deamon的一些相关知识，依旧是采用问答的方式来进行。为了文章的整体完整度，所以会加一些基本内容介绍
- 什么是docker Deamon
- docker Deamon是否可以远程调用
1.什么是docker Deamon
Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux或Windows操作系统的机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。
docker Deamon实际上就是docker的守护进程，作为docker的核心来处理docker命令行发起的一些命令。
2.docker Deamon是否可以远程调用
我们都明确，docker是一个CS架构的，平时我们操作的都是他的客户端，但是由于常规情况下，他是CS一体的，但是会存在一种情况就是CS并非一体，而是分离部署的，客户端和服务端不在同一台服务器上，那么就会涉及到docker Deamon的远程调用的问题。
默认情况下，dockerd在unix套接字上监听本地docker client连接。配置远程连接有加密（基于TLS）和不加密两种方式，都可以通过systemd或者daemon.json完成
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// -H tcp://127.0.0.1:2375
远程调用docker Deamon有两种方式，一种是非安全模式，一种是安全模式，在非安全模式下，任何客户端都可以直接连接服务端，操作服务端的内容，还有一种就是安全的SSL的方式，通过证书的方式来进行远程的访问，当然推荐的肯定是安全模式会好很多。
默认情况下，docker Deamon端口是2375
0x02 docker Deamon的攻击面
实际上docker Deamon这个攻击面不仅仅出现在云环境下，就算是只有docker部署的集群的情况下也是会出现这个问题的，只不过因为k8s包含了docker这个部分，所以才会有这个问题，但是在最新版的k8s中已经弃用了docker
1.不安全端口2375
环境搭建
修改文件docker.service
vim /lib/systemd/system/docker.service
新增配置-H tcp://0.0.0.0:2375
首先reload一下 systemctl daemon-reload，然后重启docker，systemctl restart docker
访问一下http://192.168.247.156:2375/version，出现如下内容，环境配置成功
如果此端口暴露的话，那么就可以通过docker执行任意docker命令，比如查看一下启动的docker
docker -H 192.168.247.156:2375 ps
或者查看信息：docker -H 192.168.247.156:2375 info
其他操作和本地使用docker没有任何差别
2.证书遗失
既然控制是可以通过证书控制的，那么攻击者如果拿到了证书，自然也可以通过此方式来获取到docker Deamon的相关权限了。
下面是docker的连接方式
docker --tlsverify \ --tlscacert=ca.pem \ --tlscert=cert.pem \ --tlskey=key.pem \ -H=$HOST:2376 version
连接后继续docker相关操作即可。
候选的攻击方式多种多样，可以轻松的获取到目标服务器的权限。
补充知识
docker 优势
Docker 的优势包括：
-
简化开发流程：Docker 提供了一个轻量级的容器化解决方案，使得应用程序的开发和部署过程更加简单、快捷和可靠。
-
更容易迁移和部署：Docker 容器可以在不同的操作系统和云平台上运行，使得应用程序的迁移和部署变得更加容易。
-
节省资源：Docker 容器共享内核和系统资源，使得系统资源的利用率更高。
-
更安全：Docker 容器提供了隔离和安全性，使得应用程序在容器内运行时更加安全。
-
更具可扩展性：Docker 容器可以通过扩展集群规模来提高应用程序的可用性和可伸缩性。
-
开源社区支持：Docker 是一个非常活跃的开源社区，提供了丰富的资源和支持，使得开发者可以更加便捷地使用它。
k8s的优势
Kubernetes（简称K8s）是一个流行的开源容器编排平台，它的优势包括：
-
自动化容器管理：Kubernetes通过自动化容器部署、伸缩、故障恢复等操作，简化了应用程序的部署和管理过程，减少了手动操作的出错率。
-
跨平台支持：Kubernetes支持多种容器运行时，如Docker和rkt，也支持多个云供应商，如AWS，Azure等，从而使应用程序的部署更加灵活和可移植。
-
可靠性和弹性：Kubernetes提供了多点故障恢复和自我修复机制，如果一个容器失败，Kubernetes会自动重启或创建替代的容器，从而确保应用程序的高可用性。
-
自定义扩展：Kubernetes提供了许多API和插件，应用程序可以根据需要进行自定义扩展，以满足特定的需求。
-
社区支持：Kubernetes具有广泛的社区支持，可以获得社区成员的建议和帮助，从而提高了应用程序的生产力和质量。
k8s 和docker
Kubernetes (k8s) 并没有放弃 Docker，而是放弃了 Docker 作为其默认的容器运行时（CRI）。这是因为在 Kubernetes 的早期版本中，Docker 是唯一可用的容器运行时，因此 Kubernetes 使用了 Docker 的 API 作为其 CRI。然而，随着时间的推移，其他容器运行时，如CRI-O、containerd 和 frakti 等，逐渐成为了 Kubernetes 生态系统的一部分，并且这些容器运行时与 Kubernetes 更紧密地集成。此外，Docker 提供的特性在 Kubernetes 中也不是必需的，并且 Kubernetes 用户需要的特性可以通过其他容器运行时实现。因此，Kubernetes 并没有放弃 Docker，而是通过支持多个容器运行时来提供更好的灵活性和选择性。