容器监管：保持 Linux 容器的安全和稳定
容器 Docker Anchore
![](/data/attachment/album/201701/25/124735zc661syy3eeweqa6.jpg)


Linux 容器正在改变 IT 从业者的工作方式。相比于庞大、沉重的虚拟机，一些组织发现把他们的应用部署在容器中更有效，可以提供更快的速度，更加密集，提升他们操作的敏捷性。


从安全的角度看，容器带来了一些优势，但是也面临着它们自己的一些安全挑战。和传统的基础设施一样，为了避免安全缺陷，确保运行在一个容器内的组件和系统库的定期更新是至关重要的。但是你如何知道什么东西运行在你的容器内？为了帮助你应对这些的安全挑战，一个名为 [Anchore](https://anchore.com)的初创公司正在开发一个[同名的开源项目](https://github.com/anchore/anchore)，它用来帮助展示 Linux 容器中的内容。


为了了解更多关于 Anchore，我找到了 Anchore 的市场和产品的发言人 Andrew Cathrow，来了解更多关于这个开源项目背后的公司。


### 简而言之 Anchore 是什么? 它如何工作?


Anchore 的目标是提供一套工具，允许开发人员、运营团队、安全团队在容器的整个开发周期中保持对“监管链（Chain of Custody）”的全程可见，并提供生产部署所需的可见性、可预测性和控制性。Anchore 的引擎通过插件可以进行分析（通过提取镜像数据和元数据）、查询（允许对容器进行分析）、以及策略评估（这里的策略指可以被指定的管理的图像）。


虽然市场上有很多扫描工具，但是大部分不开源。我们认为安全合规的产品应该是开源的，否则你怎么才能信任他们。


Anchore 除了开源以外，还有两大优势，使它可以区别于市场中的商业产品。


首先，我们看的不止是操作系统的镜像。如今的扫描工具专注于操作系统的软件包，比如“你的 RPM 或 DEB 包中有CVE（安全漏洞）么？”这虽然是很重要的，你不希望你的镜像中有不安全的包，但是操作系统包只是镜像的基础。其他的层次都需要进行验证，包括配置文件、语言模块、中间件等等。你可以用的全是最新的软件包，但是可能一个配置文件配置出现错误，不安全就出现在里面。第二个不同就是允许用户添加自己的数据、查询或策略来扩展这个引擎。


### 什么推动了容器的校验和分析工具的需求出现？这个工具可以解决运营面临的什么问题呢？


企业使用 Docker 首要关注的就是安全，特别是他们正在部署的容器的分配和合规性。在生产环境中，从公共镜像库拉取一个镜像，运行它，并在几秒钟部署，是非常简单的，甚至不知道下面可能发生什么。终端用户在部署应用时，必须信任他们所部署的是安全、高效和易于维护的。


容器是不透明的，它们是一个包含应用程序的可部署的“黑盒”。虽然非常容易把这些镜像看作“打包的应用程序”，但是它们包括了系统的镜像和多达数百个包和成千上万个文件。如同所有在物理服务器、虚拟机或者云上的操作系统一样，镜像也需要维护。镜像或许包含了未补丁的安全缺陷、带有 bug 和错误配置的过期软件。


要对您的容器部署有信心，你需要知道底层是什么，并基于容器镜像的内容来做出决定。


### 如今容器的创新基本上都是开源的，你认为是为什么呢？是什么促使了它们开源呢？


在过去的 20 年中，各个组织已经经历了开源带来的优势，节省成本，减少锁定，提高了安全性和更快的创新。容器，特别是 Docker，都是非常好的例子。Docker 公司的团队不能在专有系统上创建一个新的软件部署模式，他们不能要求在修改专有系统的代码，而是与行业领导者比如谷歌、IBM、英特尔、红帽合作，朝着一个共同的目标。开源和 Linux 总是开启创新和激励产业困境。在过去，实现一个大的想法需要一个大的团队和很多资源。在开源世界，一个有着很大的创意的小公司可以工作在一个更大的社区中，通过知识共享的力量来协作，提供真正的企业创新。


为了深入的说明开源的使用，Anchroe 团队最近刚从多伦多的 LinuxCon 回来，在哪里，令人难以相信的是，微软作为钻石级的赞助商，展示了他们用在 Linux 上的产品投入的增长。Linus Toravlds 曾说过，“如果微软为 Linux 开发应用就意味着我赢了”。我要把这句话改为“开源赢了”。


### 容器领域的通用标准的创建还需要时间，在容器的几乎所有部分，仍有许多挑战。在这个领域，创业公司有哪些挑战？


这里有个很重要的点，就是没有开放的标准和开源，我们不可能看到快速推动容器的采用和改变行业格局的创新。开放容器倡议（OCI）由 Linux 和容器行业的行业领导者组成，正在为运行环境和镜像格式创造标准，这将使我们能够看到更多的创新。Anchore 很自豪能成为 OCI 的新成员，我们期待帮助形成标准。


### 你将如何围绕 Anchor 项目建立一个开源社区？


Anchore 团队来自 Ansible、Eucalyptus Systems 和 Red Hat 的领导团队，在开源社区中拥有丰富的工作经验。从一开始，Anchore 就准备创建一个强大的开源社区，我们正在应用我们在开源世界中学到的经验和教训。第一课，当然，发布要尽早尽快。我们在 6 月开源我们的检测和分析引擎，远远早于我们的商用产品，以便了确保开源项目能够独立运行，使更多的直接用户能够使用它，而无需购买 Anchore 的商用产品。通过支持、服务和增强型的数据源，有很多机会给商用产品创造更多价值，但是如果开源引擎本身没有用，我们将看不到活跃的社区。


我们将 Anchore 模块化，允许添加分析、报告和策略插件，而不需要更改核心的引擎。我们希望保证任何人都可以创建插件，所以我们选择了 Python 作为项目的基本语言，因为 Python 被开发者和系统管理员广泛应用。但是，即使你不熟悉 Python，你仍然可以使用任何你喜欢的语言或者脚本环境创建插件。如果你可以创建一个 Bash 脚本，那么你也可以创建一个 Anchore 插件。我们的目标是最大化的吸引社区的参与。虽然我们鼓励用户将贡献回馈给社区，但是我们也为这个项目构建并进行了授权，来确保可以独立创建和维护私有的插件和模块。


### 容器的用途不止是在服务器上更大密度的部署应用程序或者技术层面更快的速度，而且还有不同工具的组合，这些工具提供了一种不同的方式来拉近开发者和操作者共同工作。作为在这个领域工作的公司，你们希望提供一个什么样的消息来让开发者和运营产生共鸣？


随着越来越多的运行环境、编排、监控和集成产品，容器的生态系统正在快速发展。所以，我们的架构中的第一个考虑因素不是限定 Anchore 的部署和使用。我们需要确保我们可以适应任何 CI/CD 工作流，无论是私有部署还是云端部署。一个经常问到我们的问题是，Anchore 是否将提供一个包含了镜像扫描和分析的容器仓库。虽然这将大大简化我们的工作，但是这会迫使用户进入特定的部署架构，并限制了用户部署他们自己最好的组件的能力。我们已经确保 Anchore 可以和所有领先的仓库、运行环境平台、 CI/CD 平台和编排工具配合使用。


一些开发者掌握了运营技能，并转换为 DevOps 角色，我们看到系统管理员/运营团队也在更多的了解开发，转换成 DevOps 角色。我们也看到了具有混合能力的团队。我们设计了可供开发运营和安全团队使用的 Anchore ，以便他们共同定义规则和策略来评估开发周期中的任何一个环节。另外一个例子是插件/模块的架构，使任何人都可以在他们喜欢的环境中轻松创建一个模块 —— 无论是以 Python、Go、Perl、C 甚至是一个 Bash 脚本。




---


via: <https://opensource.com/business/16/10/interview-andy-cathrow-anchore>


作者：[Jason Baker](https://opensource.com/users/jason-baker) 译者：[Bestony](https://github.co/Bestony) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
Linux containers are helping to change the way that IT operates. In place of large, monolithic virtual machines, organizations are finding effective ways to deploy their applications inside Linux containers, providing for faster speeds, greater density, and increased agility in their operations.

While containers can bring a number of advantages from a security perspective, they come with their own set of security challenges as well. Just as with traditional infrastructure, it is critical to ensure that the system libraries and components running within a container are regularly updated in order to avoid vulnerabilities. But how do you know what is running inside of your containers? To help manage the full set of security challenges facing container technologies, a startup named [Anchore](https://anchore.com/) is developing an [open source](https://github.com/anchore/anchore)[ project](https://github.com/anchore/anchore) of the same name to bring visibility inside of Linux containers.

To learn more about Anchore, I caught up with Andrew Cathrow, Anchore's vice president of products and marketing, to learn more about the open source project and the company behind it.

### In a nutshell, what is Anchore? How does the toolset work?

Anchore's goal is to provide a toolset that allows developers, operations, and security teams to maintain full visibility of the 'chain of custody' as containers move through the development lifecycle, while providing the visibility, predictability, and control needed for production deployment. The Anchore engine is comprised of pluggable modules that can perform analysis (extraction of data and metadata from an image), queries (allowing reporting against the container), and policy evaluation (where policies can be specified that govern the deployment of images).

While there are a number of scanning tools on the market, most are not open source. We believe that security and compliance products should be open source, otherwise, how could you trust them?

Anchore, in addition to being open source, has two other major differentiators that set it apart from the commercial offerings in the market.

First, we look beyond the operating system image. Scanning tools today concentrate on operating system packages, e.g. "Do you have any CVEs (security vulnerabilities) in your RPMs or DEB packages?" While that is certainly important, you don't want vulnerable packages in your image, the operating system packages are just the foundation on which the rest of the image is built. All layers need to be validated, including configuration files, language modules, middleware, etc. You can have all the latest packages, but with even one configuration file wrong, insecurity sets in. A second differentiator is the ability to extend the engine by adding users' own data, queries or policies.

### What is driving the need for an inspection and analytics tool for containers? What problems are operators facing that this helps to solve?

A primary concern for enterprises adopting Docker today is security, in particular, the governance and compliance of the containers they are deploying. It's almost too easy to pull an application image from a public registry, run it, and within seconds deploy an application in production without even knowing what's under the covers. End users must have confidence that when they deploy applications they will be secure, performant and easily maintained.

Containers are opaque in that they are deployable ‘black boxes' that contain applications. While it's easy to treat these images as "just packaged applications," they include operating system images with up to hundreds of packages and thousands of files. As with all operating systems on physical servers, virtual machines, or in the cloud, images need to be maintained. The images may contain unpatched security vulnerabilities, outdated software that contains bugs, or may be misconfigured.

To have confidence in your container deployments you need to know what's under the covers to analyze and make decisions based on the contents of your container images.

### The innovation around containers today is almost entirely happening in open source. Why do you think that is? What's driving the desire for openness?

Over the past 20 years organizations have experienced the advantages open source brings to cost savings, reduced lock-in, improved security and faster innovation. Containers, and Docker specifically, are great examples. The team at Docker Inc. would not have been able to create this innovative new software deployment paradigm on top of a proprietary system. They would not have been able to make the required modifications to the code in a proprietary system, nor be able to work cooperatively with industry leaders such as Google, IBM, Intel, and Red Hat—all working toward a common goal. Open source and Linux have always enabled innovation and positive industry disruption. In the past, delivering a big idea required a big team and lots of resources. In the open source world, a small company with big ideas can work in the wider community and benefit from *shared intellectual horsepower* to collaboratively deliver real enterprise IT innovation.

To illustrate the deep adoption of open source, the Anchore team recently returned from LinuxCon in Toronto, where it was incredible to see Microsoft as a diamond level sponsor presenting a growing portfolio of their products that work with or on Linux! Linus Torvalds once said, "If Microsoft ever does applications for Linux it means I've won." I'd amend that statement to read "Open has won."

### The days of common standards in the container space are still very young, and there are still many competing visions for nearly every part of the stack. What challenges does that create for a startup in this space?

It is important to remember that without open standards and open source we wouldn't have seen the innovation that is driving rapid container adoption and changing the industry landscape. The Open Container Initiative (OCI), comprised of industry leaders from the Linux and Container industries, is doing great work setting standards for both the runtime and image formats that will allow us to see even more innovation. Anchore is proud to be a new member of the OCI and we look forward to helping form the standards.

### How are you working to build an open source community around the Anchore project?

The Anchore team has a rich history of building and working within open source communities, with leaders from Ansible, Eucalyptus Systems, and Red Hat. From the start, Anchore began building a strong open source community and we are applying lessons learned in the open source world. The first lesson, of course, is to release early and often. We open sourced our inspection and analysis engine back in June, far in advance of our commercial offering, to ensure that the open source project can stand on its own with features that make it useful to many end-users without having to purchase Anchore's commercial offering. There will always be opportunities to add more value with support, services, and enhanced data feeds with a commercial offering, but if the open source engine is not useful in itself then we will not see an active community.

We built Anchore to be modular to allow analysis, reporting and policy plugins to be added without requiring changes to the core engine. We want to ensure that anyone can create plugins, so we chose Python as the base language for the project because it is widely used by developers and sysadmins alike. But even if you are not well versed in Python you can still create plugins using whatever language or scripting environment you prefer. If you can create a bash script then you can create an Anchore plugin. Our goal is to enable the broadest possible community to attract participation. While we encourage our users to pass these contributions back to the community we've architected and licensed the project to ensure that private plugins/modules can be created and maintained independently.

### The promise of containers is not just greater application density on servers or greater speed on the technical side, but a combination of different tools that together provide a different way of approaching the way developers and operators work together. As a company working in this space, how are you providing a message that resonates with both developers and operators?

The container ecosystem is evolving rapidly with a growing number of runtime, orchestration, monitoring and integration products. So the first consideration we had to factor into our architecture was to not be prescriptive about Anchore deployment and usage, we need to ensure that we can fit into any CI/CD pipeline whether it's on-premise or deployed in the cloud. A common question we are asked is if Anchore will provide a container registry that includes image scanning and analysis. While this would simplify our work considerably, it would force customers into specific deployment architectures and limit customers' ability to deploy their own best-of-breed stack. We've made sure that Anchore works with all leading registries, runtime platforms, CI/CD platforms and orchestration tools.

## Comments are closed.