centos|云原生时代裸奔的容器正引入多重安全风险客户端|Linux|ETC|操作系统

容器彻底改变了开发流程，成为 DevOps 模式的基石，但容器带来的复杂安全风险并不总是显而易见的，若不减轻这些风险，企业将很容易受到攻击。
在本文中，我们将介绍容器如何促进敏捷开发，并且带来了哪些独特的安全风险，以及企业可以做些什么来保护容器化的工作负载，超越 DevOps 以实现 DevSecOps 。
【centos|云原生时代裸奔的容器正引入多重安全风险】
为什么容器会迅速流行起来？容器在很多方面都是虚拟化技术的演进，目标是加速开发过程，创建更敏捷的从开发到测试和实施的路线，这种方法比使用成熟的虚拟机更轻量级。
由于应用程序存在兼容性问题——应用程序需要某些特定版本的库，这可能会与其他应用程序的需求产生冲突。而容器可以解决这个问题，并且恰好与开发过程和驱动这些过程的管理基础设施很好地联系起来。
容器通过将虚拟化提升到一个更高的级别来完成他们的工作。虚拟化抽象了硬件层，而容器抽象了操作系统层，实质上是虚拟化了操作系统的角色。其工作原理是将应用程序打包到“容器”中，这些“容器”包含了使应用程序工作所需的所有库，同时保持应用程序互不干扰，就好像每个应用程序都认为自己拥有专属的操作系统。
从功能上讲，容器非常简单，只是一个文本文件，其中描述概述了哪些组件应包含在实例中。容器的这种简单性和更轻量级的特性使得在整个开发生命周期中使用自动化编排工具进行部署变得更加容易。
显而易见，容器可以提高开发效率，就像一把打开 DevOps 的钥匙。据Gartner 预测，到 2023 年， 70% 的企业将运行容器化的工作负载。
容器引入了哪些安全风险？容器简化了开发过程，但也给带来了复杂的安全威胁。当我们将整个操作环境紧密打包到一个容器中并将其广泛分发，攻击面随之增加并为不同的攻击向量打开大门。与容器一起打包的任何易受攻击的库都会将这些漏洞或弱点传播到无数的工作负载中。
首当其冲的是“供应链攻击” ，攻击者不是通过破坏应用程序，而是通过修改应用程序附带的包或组件来发动攻击，造成连锁反应。因此，研发团队需要评估他们正在开发的应用程序以及作为容器配置的依赖项引入的每个库。
容器安全的风险还涉及启用容器的工具，比如，我们不应该允许系统管理员以 root 身份运行 Docker 容器。从 Docker 到 Kubernetes 等编排工具，都需要被监控和保护。同样地，还需要密切保护容器注册表，以确保它们不会受到损害。
容器安全的核心是内核安全还有一些与容器相关的安全风险不如其他风险那么明显。每个容器都需要访问内核，毕竟容器只是一种高级的进程隔离。但是我们很容易忽略一个事实，所有容器都依赖于同一个内核，容器内的应用程序彼此隔离并不重要。
容器中的应用程序看到的内核与主机运行所依赖的内核是相同的，这带来的风险在于，如果支持容器的主机上的内核容易受到攻击，则可以通过从容器内的应用程序发起攻击来利用此漏洞。
因此，内核由主机上的所有容器共享的事实意味着必须快速修补有缺陷的内核，否则所有容器都会很快受到漏洞的影响。
企业应该怎么化解容器安全风险？让主机的内核保持最新是确保容器操作安全可靠的重要一步。不仅需要修补内核，还必须将修补程序应用到又容器拉入的库中。但是，正如我们所知，持续修补说起来容易做起来难。这可能就是为什么有研究发现，所分析的容器中有 75% 包含严重或高危漏洞。
例如，这些漏洞可能导致突围攻击，攻击者依靠容器内有缺陷的库就能够在容器外执行代码。通过破坏一个容器，攻击者最终可以达到他们的预期目标，无论是主机系统还是另一个容器中的应用程序。
在容器环境中，维护安全的库是一个非常令人头疼的问题，需要持续跟踪新的漏洞，以及哪些已经被修补，哪些又还没有。这个过程很费力，并且要求企业具备相当专业的技能。
安全419观察到，国内从事云原生安全、主机安全、软件开发安全领域的部分安全厂商在积极关注容器安全问题，并提供相关产品及服务帮助企业化解风险。
青藤云安全推出青藤蜂巢·云原生安全平台，能够集成到云原生复杂多变的环境中，如Kubernetes、PaaS云平台、OpenShift、Jenkins、Harbor、JFrog等，覆盖容器全生命周期，提出容器安全“五个保护” ，保护容器主机的安全、保护容器网络流量安全、保护容器中应用的安全、保护容器管理技术堆栈、保护构建管道的完整性能，实现容器安全预测、防御、检测和响应的安全闭环。

centos|云原生时代 裸奔的容器正引入多重安全风险

centos|云原生时代裸奔的容器正引入多重安全风险