你驻足于春色中,于那独一无二的春色之中.
Docker怎么做才能在被别人拿到SHELL后将危害做到最小？
Docker安全的问题有许多的相关文章分析，援引“Docker安全那些事”中提到的，Docker安全具体应该说分为Docker自身安全和Docker镜像安全两种，Docker之前有记录的漏洞分别是1.3和1.6，而现在的版本已经到1.12，到现在为止都没有再爆出漏洞的信息，而且Docker自身的安全往往是和Linux的底层功能息息相关的，这也是我不懂的领域。
还有一个特别的点就是Docker的远程调用API接口存在未授权访问，但其实导致这个问题的是Docker的服务端程序Docker daemon被绑定到了公网的端口上，并且没有增加认证。默认情况下Docker daemon使用的是sock监听，本身只有root和docker用户组才有权限，所以不进行验证。换句话说，如果你不打算通过网络执行Docker命令或者增加证书验证的环节,这种漏洞就可以避免。
我们可以在本地复现一下这个漏洞，首先我们关闭Docker daemon的本地sock，开启远程访问，并绑定端口。
1 | service stop docker |
之后我们访问
1 | curl http://127.0.0.1:9090/containers/json |
我们来获取一些敏感的信息
1 | curl http://127.0.0.1:9090/containers/(id)/logs?stdout=1 |
另外通过Post包我们还可以新建、开启和关闭容器。
相关的参考文件：
https://yq.aliyun.com/articles/48689
https://www.91ri.org/15837.html
我们这里谈到的安全，将从另一个视角来解读，假设我们默认部署好的容器应用存在某种漏洞而被利用，最坏的情况是攻击者完全拿下了容器并且取得了root权限。可以预想到的是，在默认的配置下，拥有root权限的Docker就如同真正的跳板机一样，容器如同使用宿主机作为路由器的主机，不仅能够扫描到宿主机的端口情况，还可以扫描到宿主机所在网段的拓扑。
最初是想在宿主机上做端口转发策略的限制，进而限制容器访问到更大范围的局域网。本以为在宿主机上的端口转发并不会影响宿主机的网络访问功能。使用如下指令：
1 | sysctl net.ipv4.ip_forward |
在宿主机上运行上面的指令可以查看当前的转发策略是否开启，当键值为1时表示开启，此时的容器网络访问是畅行无阻的。
1 | sudo sysctl -w net.ipv4.ip_forward=0 |
使用上面的命令可以临时将这个参数的键值改为0，此时我们发现容器只能访问到同一网段的其它容器而无法访问到宿主机所在的局域网中，与此同时，我们只要保证作为路由器的宿主机上没有运行开启端口的应用，就应该是安全的。可是随后注意到一个问题，关闭容器对外的端口转发后，外界对于容器的访问也一起被禁止了。
这样的话，只能乖乖的在iptables上做文章了。因为不是介绍iptables的文章，就不多对这个Linux下自带的防火墙做过多的介绍。我的想法是使用宿主机的iptables禁止相应的应用容器访问外网（包括宿主机所在的局域网），这样既能实现容器限制，又不会影响外界访问容器。
1 | sudo iptables -I FORWARD -i docker0 -o ens33 -j DROP |
该命令可以从宿主机的层面限制容器对外的访问，这样可以从一定程度上解决通过容器做跳板的问题。这样的场景实际上就像是将容器设置成只有一条单向入口的孤岛，只允许外界对容器进行访问，而不允许使用容器在做进一步的其它网络访问。
除了上述限制的方法外，我们还可以对于容器中的重点文件夹或文件做监控，一旦检测到相应的文件发生变化，可以立即重新生成新的镜像，以应对攻击。
这里的架构思路如下，作为监控程序，它不应该位于目标容器内，所以我们考虑使用我在上一个谈论Docker日志的笔记里提到的挂载的方式，将容器内部重要的文件夹挂载进监控容器内，在监控容器内运行程序监控相应文件的增、删、改等操作，一旦发现不被允许的操作执行，就关闭容器或者重新构建容器。具体文件监控容器方面的学习有机会再在后面贴出。
Docker一旦部署到真实环境中，我们就要对它的安全性做全面的衡量，不过通过上述分析，在排除可能存在0Day的情况下，只要配置得当，Docker的安全性还是有保障的。
由于容器的便携性、易部署性、隔离性，我们可以很方便的在部署容器服务的同时，连带部署一系列的监控、处理容器对于服务容器做维护。