|
戳蓝字“CSDN云计算”关注我们哦！
除了应对常见云平台和传统数据中心常见的安全威胁，容器云平台还存在一些自己独有的新的安全威胁与挑战。随着容器云的广泛使用，安全方面的问题越来越不容忽视。 下面我会带大家一起看下和传统的云平台相比容器云在安全方面的一些问题。 容器云平台安全价值 1. 全面的安全策略 和传统的云计算平台一样，容器云计算平台也将计算资源进行了集中化的管理，计算资源集中化管理的好处是容器云平台的边界防护更加容易部署。我们可以针对容器云平台的计算资源提供全面的安全策略管理、全面的安全补丁管理，另外也可提供统一的数据管理以及突发事件管理等安全管理措施。由于容器云平台已经提供了我们讲到的这些安全防护，因此容器云平台上的用户不需要组建专业的安全专家团队来对自己的计算资源和数据进行专门的防护。 容器云平台一般会有自己专门的镜像仓库，且一般会周期性的从权威的CVE漏洞资料库中获取最新的一些漏洞信息，定时更新镜像仓库CVE漏洞字典库。然后接下来会主动对包含了此漏洞的镜像进行及时的更新或者下线，另外这个时候一般还会对用户进行漏洞更新的提醒(常见途径有邮件通知、短信通知、站内信通知等)。这样平台上的用户在使用平台上提供的容器镜像时不需要再去考虑一系列的容器镜像安全问题。 2. 用户低安全成本 容器云平台一般都会进行多租户的支持，多个租户共用云平台上的计算资源。这种情况下我们可以在云平台集中化的资源上进行统一的安全配置，统一安全配置可以降低各个用户在安全措施上的平均成本，且平台级别的安全防护一般要比用户部署的安全防护要专业的多，这样的话用户可以以更低的安全成本使用到更好的安全防护。 3. 安全防护按需提供 云平台提供的安全防护一般都会进行等级的划分，较低的安全防护等级一般会免费提供给用户进行使用，比如较低带宽的DdoS防护，对于需要更高防护带宽的用户可以按需进行购买。 除了防护按需购买这种情况之外，容器云平台还可以利用快速、弹性分配资源的优势为过滤、流量整型、加密、认证等提供安全防护措施，另外还可根据用户业务实际的负载情况动态调整计算资源的数量，提高安全措施的处理效率。 网络安全威胁 相比传统的云平台，容器云平台在网络方面一般会有比较大的差异，伴随着这些差异的引入，也引入了一些网络方面的安全问题。比如因为网络隔离模型的变化、资源共享方式的变化而出现的新的安全隐患，针对这两点变化我们分别看下他们带来的安全问题。 1. 网络模型 容器云平台中网络隔离大多使用逻辑隔离代替物理隔离。 物理隔离一般不会直接或者间接的连接公共网络，企业采用物理隔离网络一般是为了保护自己的各种各样的硬件设备和通信链路不被攻击，常见的攻击来自自然灾害、人为破坏等，被保护的硬件实体设备常见的有企业的路由器、工作站和其他的各种网络服务器等。从实际情况来看，一般只有使用了内网和公共网进行的物理隔离才能真正保证内部信息网络不被来自外界的攻击影响，比如来自黑客的攻击。 网络的逻辑隔离一般需要借助逻辑隔离设备来实现，从名称即可看出逻辑隔离器是不同网络间的一种中间件，用于连接不同的网络，常见的网络逻辑设备主要有防火墙、网关等。需要注意的是被隔离的网络之间仍然有物理的数据链路进行联通，被联通的两个网络之间不能直接的进行数据交换。 相比逻辑隔离物理隔离的安全性更高，企业网络多采用物理隔离代替逻辑隔离，以此来保证不同级别的组织或者部门的信息安全。容器云平台网络上采用逻辑隔离，来隔离不同的租户或者项目，一定程度上增加了云平台在网络方面的安全隐患。 2. 资源共享 容器云在网络方面的安全问题，除了上面我们讲到的网络逻辑隔离引入的问题，还有资源共享方面的问题。和传统的云平台一样，容器云平台一般也会有多租户的需求(公有云肯定会有多租户的存在，即使是私有云一般也会有多租户的需求，比如不同的子公司、同公司不同的部门一般都会有多个租户的需求)。 相比传统的云平台，容器云的多租户资源共享引入了更多的风险，在容器云中多个租户共享计算资源，很可能会因为隔离措施不当导致不同租户的逻辑网络被意外打通(国内某知名云厂商曾经发生过类似的问题)，导致用户的资源被其他的用户意外的访问到，这种情况下用户可能会被其他的用户恶意攻击，导致数据泄露等严重的问题。容器云平台中通常借助网络防火墙/IPS来进行虚拟化，这种方式也是很常用的方式但是进入云平台之后，尤其是在用户众多的公有云场景中，网络防火墙这种虚拟化方式就不会暴露出虚拟化能力不足的问题，这个问题会导致已经建立的静态网络分区与隔离模型不能满足容器云中动态资源的共享需求。 主机安全威胁 容器云平台目前基本以Docker 容器和kubernetes 容器编排(kubernetes为主流，当然也有支持多种编排工具的厂商)。了解Docker 的同学应该都知道Docker 容器是通过命名空间(namespace)的方式将文件系统、进程、各种设备、网络等资源进行了隔离。除了对资源的隔离，Docker容器还对容器具有的权限进行了限制，对CPU、内存等资源的使用也进行了相应的限制。对Docker 容器资源的限制、隔离的目的是为了让容器之间互不影响。 容器与容器所在的宿主机共享内核、文件系统、各种硬件等资源。容器可以部署在物理机上，也可以选择部署在虚拟主机上。 由于Docker 容器与宿主机共享内核、文件系统等资源，Docker 本身的隔离性不如虚拟机主机完善，因此如果Docker 自身出现漏洞，可能会波及问题Docker 容器所在的宿主机，由于Docker 容器所在的宿主机上可能存在当前租户的其他容器，也可能存在其他租户的容器，所以问题最终可能会影响到其他的容器，并可能会破坏容器云平台上的宿主机。 除了上面提到的Docker 容器可能会影响宿主机的问题，Docker 在主机层面还面临一些其他的问题，如容器对Hypervisor 的安全威胁、对虚拟机的安全威胁等，下面我们一起看下。 1. Hypervisor 隐患 Hypervisor 基本可以说是当前虚拟化的核心，使用非常广泛。Hypervisor 处在虚拟主机和宿主机之间，可以捕获CPU指令，为访问硬件控制器和各种各种外设设备充当中介。由于Hypervisor 可以协调各种资源的分配，因此它的权限非常之大，Hypervisor 运行在比操作系统特权还高的最高优先级。因此如果因为Docker 容器的漏洞导致Hypervisor 被攻击，则运行在Hypervisor 之上的所有的虚拟主机都会被波及，所有的虚拟主机将无任何的安全保障，基本处于直接的攻击之下。 2. 虚拟机主机隐患 Docker 容器出现安全漏洞时，可能会导致接入和管理虚拟机的密钥被盗。我们知道虚拟机的动态创建、迁移(冷迁、热迁)、都会伴随着虚拟机安全措施的自动创建和自动迁移，如果Docker 容器出现漏洞可能会导致容器中未及时打补丁的服务遭受攻击，比较易被攻击的服务有FTP、SSH等，攻击可能会导致弱密码或者无密码的账号被盗用，如果这个时候主机没有设置防火墙策略，则遭受的攻击可能会更加严重。 应用安全威胁 容器云平台除了在网络层面和主机层面引入了额外的安全问题外，在我们最常接触的应用层面和数据层面也引入了一些安全问题，下面我们先看下应用层面引入的问题。 我们从应用层面谈到容器的时候一般首先需要考虑的是我们的容器中有什么？比如有些时候我们的应用程序和基础设施会有很多的组件组成，这些常用的组件中可能有一些会是开源的软件，比如linux操作系统、各种开源的Web服务器(比如Apache web服务器、Tomcat Web 服务器、Nginx web服务器等)、Red Hat Jboss企业应用平台、各种开源的数据库(比如mysql数据库、postgresql 数据库)等。以上我们列举的只是一部分常用的开源软件，不同的业务场景中可能还会有自己专门需要的一些开源软件，比如node应用中肯定会用到node.js。 上文我们列举的那些常用的软件基本都有自己的容器化版本，且很多软件除了提供了常用的具备基本功能的容器版本外还额外提供了很多做过专门优化的容器化的版本。对于已经提供了容器化版本的软件我们一般没有必要再自己造轮子，一般不需要再重新构建一遍。但是从实际使用来看，并不是每一个容器化的版本都能满足我们的业务需求，比如我们需要一个或者多个额外的软件包，这个包提供了和行业相关的特殊的功能，这种情况下我们需要引入额外的第三方的包，然后进行新镜像的构建，这个时候就会引入新的隐患，即我们可能不清楚这些第三方包的来源，不清楚这些包是否已经经过严格的测试，也不会清楚这些包中是否被植入恶意的代码。 Docker 的容器镜像本质上是一系列的静态文件的集合，也可以说是容器应用运行的时候可见的文件系统。所谓的镜像扫描就是遍历所有的镜像中的文件系统，遍历文件系统时会逐个检查文件系统中的软件包是否有漏洞。这个过程跟我们自己的PC本中的病毒扫描软件在扫描病毒时是一样的，对系统中所有的文件进行扫描分析，并将扫描结果和已知的病毒数据库中的指纹特征进行对比，从而发现病毒的存在。 数据安全威胁 我们知道容器即可被用于有状态的应用，也可被用于无状态的应用。如果我们使用有状态应用的话一般还需要为有状态应用添加额外的存储介质，Docker在存储介质方面容器提供了多种支持，常见的有网络文件系统NFS、AWS弹性块存储EBS、GCE持久化存储、GlusterFS存储、ISCSI存储、分布式存储Ceph以及Cinder 等。 一个存储卷可以通过存储介质支持的方式挂载到目标主机上，不同的存储介质往往具有不同的性能，且不同的持久化卷支持的访问模式往往也是不同的，例如网络文件系统NFS能够支持多路客户端的同时读/写。 容器云中引入这些存储介质在一定程度上方便了我们的数据存储，同时也引入了额外的安全问题，如NFS 可能会引入RPC服务的访问权限问题等。 容器云平台安全防范 上文中我们列举了容器云平台中最常遇到的安全威胁以及安全防护的必要性，根据容器云平台领域面临的这些威胁与挑战，在此我们提供了一些相应的安全解决方案。 1. 计算节点安全 相比其他的部分计算节点安全方面需要做的防护工作较多，具体如下： (1) User NameSpace User NameSpace 方面建议保证容器内的root权限在容器之外设置为非管理员权限，这样即使容器出现问题用户透过容器进入了容器所在的宿主机也不会拿到真正的管理员权限。 (2) 资源控制 利用Cgroups 对容器可以支配的资源配额和度量进行严格的控制，如对CPU、内存的限制等关键资源的限制。 借助资源控制可以防止某个恶意的容器占用过多的宿主机的资源。 (3) 命名空间 建议不要将容器的命名空间和宿主机进程的命名空间进行共享，这样可以降低用户从容器中进入容器所在的宿主机的风险，进而降低同宿主机上其他用户的容器被攻击的风险。 (4) 容器重试次数 容器编排工具，以kubernetes 为例，重启策略一般分为三种：Always(默认策略)、Onfailure和Never。 设置的策略为Always时，当容器发生终止退出时容器会被重启，如果重启后容器再次发生终止退出，则再次重启容器，循环往复。 设置的策略为Onfaliure 时，当容器因为发生异常且退出码不为0时，对异常的容器进行重启。 设置的策略为Never时，不论容器的运行状态如何，都不会对容器进行重启操作。 在实际使用中，很多情况下我们为了保证容器中的进程在遇到异常时可以及时通过重启来恢复应用，会将重启策略设置为always。这个时候如果容器重启后恢复正常还好，如果容器重启后又陷入异常，导致容器反复的重启。为避免这种情况的出现，一般建议通过设置on-fallure 来限制容器的尝试次数。 (5) 限制进程数 容器的正确使用姿势中一般建议一个容器中只跑一个进程，但从笔者实际观察来看，在容器中跑多个进程，将容器当做虚拟机使用的用户不在少数。 容器中允许运行的进程数过多的话会带来fork bomb的风险，即攻击者可能会利用循环在容器中不断的新建进程，导致为容器分配的资源被耗尽，如果这个时候恰好又未限制容器可以使用的资源量或者限制的数值较大的话，可能会导致容器所在宿主机上的资源被耗尽，导致当前宿主机上的其他容器触发迁移。所以在容器云中一般也会建议大家限制下容器中可用的进程数目。 (6) 端口映射 容器中运行着我们的业务进程，为了从容器之外访问到容器中的进程，我们需要对我们应用监听的端口做一次映射，为防止其他人通过容器内的特权端口(1024以下的端口)攻击容器，比如开启22端口会增加容器中系统的账号信息被暴力破解的风险，所以一般建议容器只映射应用监听的端口。 (7) 网络模式 我们知道在docker run运行容器时可通过-net选项指定容器的网络模式，Docker容器支持的网络模式一般包括如下四种： a. Bridge模式 docker run 运行容器时的默认网络模式。此模式会为每一个容器分配网络命名空间、IP等，并且会将宿主机上的Docker容器连接到一个虚拟网桥上。 b. Host模式 和上面讲到的bridge模式不同，如果启动容器时指定host模式，那么这个容器将不会获得一个独立的网络命名空间。此时容器将会和容器所在的宿主机共用同一个网络命名空间，且在此模式下容器不会虚拟出属于自己的虚拟网卡以及IP地址，而是使用宿主机的IP和端口。
c. None模式 None 模式是比较特殊的一种容器网络模式。 当我们执行docker run 命令并借助参数-net指定docker 容器的网络模式为none模式时，新建出来的docker 容器将不会拥有自己的网络命名空间，但也不是不为Docker 容器进行任何的网络设置。严格说来在none模式下Docker 容器将会没有网卡、不会分配IP地址、没有路由等信息，需要我们根据自己的需要为自己的Docker 容器添加网卡信息、IP地址信息、路由信息等网络基础配置。 d. Container模式 Container 模式也是一种比较特殊的模式，从名字也能看出来，这个模式下需要指定新创建的容器和一个已经存在额容器共享同一个网络命名空间，而不是和容器所在的宿主机共享命名空间。 需要注意的是新创建的容器并不会创建自己的网卡，也不会分配IP地址，而是完全和那个已经制定的容器共享一样的IP地址信息、端口范围等。需要注意的是两个容器虽然在网络方面是共享的，但是在网络之外的其他方面都是独立的，比如文件系统、进程列表等仍然是隔离开的。 以上我们简述了一下容器的几种网络模式，通过上面的简介相信大家可以很清楚的看出四种网络模式的区别。这几种网络模式没有优劣之分，每一种都有自己适合的场景，但是在容器云场景中我们一般不建议将网络模式设置为host模式，因为host模式下容器和容器所在的宿主机共享同一个网络命名空间，在容器中可以看到宿主机上的所有的网络设备，且容器中对宿主机上的这些网络设备具有全部的访问权限，因此每个用户在容器中对网络设备进行了修改会立即影响到同宿主机上的其他的容器的网络。为此Docker 官方也提示我们，host模式是不安全的。但是如果是在隔离性比较好的环境中也是可以使用此种模式的，比如容器运行在虚拟机中，且每台虚拟机上的容器都属于同一个租户。 (8) 目录映射 容器使用中我们经常会遇到需要将容器中的数据写到容器所在宿主机上的情况，比如有状态的负载中运行了mysql数据库，由于mysql数据库中的数据很重要，且数据量随着业务的增长会越来越大，这个时候我们一般会将容器中的mysql数据存放到mysql容器所在的宿主机上。 另外一种情况，比如我们有时我们会将宿主机上的一些公共的目录映射到容器中，防止每个容器的镜像中反复配置，比如dns配置文件等。 需要注意的是，一般我们不建议将宿主机上一些比较敏感的目录映射到容器中，比如宿主机上的内核配置文件，网卡配置文件等，防止用户在容器中对宿主机的关键配置进行篡改。 2. 容器镜像安全 据国内知名安全厂商绿盟2018年3月的研究显示，目前Docker Hub上的镜像很多都存在安全漏洞。研究人员拉取了Docker Hub上下载量最大的前10页的镜像，对其做安全测试后发现这些热门的镜像中76%存在安全漏洞，其中有很多是我们经常使用的，比如httpd镜像、nginx镜像、MySQL镜像等，可以说目前正在被企业使用的镜像中很多是存在安全问题的。
镜像安全方面我们一般建议在镜像仓库的客户端开启认证机制，并且对下载的每一个容器镜像都要进行安全检查，比如通过CVE 数据库同步扫描镜像，一旦发现镜像存在漏洞，建议及时通知用户，或者直接中断当前问题镜像的构建，等待用户处理漏洞。 3. 网络安全 网络安全涉及方方面面，细说起来可能会有一本书的内容，由于篇幅原因，在此我们只从网络传输安全这个层面给大家提供几条建议。 (1) 开启认证 镜像仓库registry 一定要开启认证方式，即使是在内网的环境下。如果不开启认证，任何人在容器内部可以随意的拉取、上传镜像，甚至可以随意的篡改其他用户的镜像。 (2) 镜像校验 镜像校验用来保证镜像的完整的di性，以防镜像被意外篡改。Docker 镜像仓库中的每个镜像都会对应一个mainifest文件，里面包含当前镜像的一系列的属性信息，其中就包括镜像的校验信息，可以根据镜像文件内容计算出校验和，然后与镜像配置中ff ID进行比较，如果diff ID 不一致则说明镜像可能已经被篡改，此时可以通过告警机制对用户进行通知。
福利 |
|
|
