容器化后,容器之间共享同一个操作系统内核以及其他组件,在收到攻击之类的情况发生时,更容易通过底层操作系统影响到其他容器。安全问题也是重中之重。
这个问题有没有什么好的办法解决?
不相关应用之间的数据隔离有什么建议和办法?
容器化后,容器之间共享同一个操作系统内核以及其他组件,在收到攻击之类的情况发生时,运行在这个节点上的容器,如果因为宿主机被攻击(甚至宕机),不能正常工作,容器编排引擎如kubernetes,会保证原来定义的副本实例数量,根据调度算法,在合适的其他节点再起新的容器,而且启动速度可以达到秒级启动,传统的宿主机启动则非常慢。而且k8s容器编排引擎还可以根据业务的访问量,进行pod的水平自动扩展(HPA);如果采用传统的宿主机上运行大的单体,一个节点收到攻击,可能影响巨大,而且很难短时间恢复。业务之间可以通过域(namespace)来进行隔离。而且容器本身就已经实现了诸多的隔离功能。目前很多的世界知名企业都开始从传统的单体业务向容器化转型。
收起一般而言,容器本质上是进程的虚拟化(隔离),但操作系统内核是共享的,所以,在这一点上,容器的安全性没有虚拟机好。但是,我们可以通过以下方法增加安全性:
1. SELinux:
2. 精简化容器操作系统:红帽OpenShift采用了RHEL CoreOS,这是一个更加轻量级、更加安全、专门为容器定制的操作系统,从而减少了操作系统端的风险。
3. 容器镜像安全:这个要结合镜像仓库和镜像扫描工具。红帽本身提供了Clair镜像扫描工具和Quay的镜像仓库。同时,红帽官方提供了供免费下载的镜像:universal base image(UBI),这些UBI都是经过检测过比较安全的。
4. 红帽OpenShift默认禁止容器以root用户启动(可以修改),可以防止潜在的漏洞。
对于数据隔离,一般而言,需要采取以下措施:
1. 不相关应用应该放在不同的OpenShift Project(相挡于K8S namespace),OpenShift Project之间采用基于角色的访问机制(RBAC)互相隔离。
2. Project之间可以采用软件定义网络的隔离(不同的VLAN),防止网络之间的访问。
3. OpenShift将来的版本支持不同Project的pod/service分配在公有云或Openstack的VPC网段,进一步增加安全性。
现在K8S在这方面相比OpenShift功能比较欠缺。