@CEBBCAT 发现回复不能用 markdown 真的崩溃 2333

感受 Docker 安全工具的魅力



本文是一个十分全面的 Docker 安全工具清单。通过这份清单，我们可以清楚地发现，保证 Docker 的安全需要多种工具的共同合作。因为每个工具都有其优势以及所专注的领域。有针对容器堆栈的内核、镜像仓库、网络、编排工具以及 CaaS 平台的每一层提供解决方案。最棒的是，大部分工具或者至少是大部分容器工作负载中的常用工具都非常适合彼此集成。

充分了解每个安全工具的功能及其特性之后，您可以为企业级生产工作负载打造固若金汤的容器安全环境。这一直是 Docker 的承诺，而容器安全工具把这一承诺变成了现实。

容器专用安全工具



Twistlock

这是一个端到端的容器安全平台。它利用机器学习来自动分析应用程序。

Aqua Security

一个端到端的容器平台，提供了易于扩展的成熟 API。

Anchore

该工具可以扫描容器镜像并为容器平台强制运行安全策略。同时它用 Jenkins 整合了 CI/CD 的工作流程。

NeuVector

该工具通过执行服务策略来保护容器运行安全。并且能够基于自动化白名单自动开始或停止容器运行。

Deepfence

该工具是 CI / CD 集成安全工具，可防止已知的攻击。

StackRox

该容器安全工具可以利用机器学习提供“自适应威胁保护”

Tenable

这是一个可以扫描容器镜像的托管安全解决方案，它甚至可以允许企业在它们的环境内执行安全策略。

Cavirin

这是一个持续的安全评估工具，可以根据 CIS 基准测试漏洞。

CaaS 平台的安全性



AWS ECS

在 AWS ECS 中，容器是运行在虚拟机内的，这就为容器提供了第一层安全保护。同时 ECS 也添加了 AWS 的安全功能，如 IAM、安全组以及网络 ACLs 等。

Azure 容器服务

Azure 容器服务有自己的容器镜像仓库来扫描镜像，同时还可充分利用 Azure 的默认安全功能，如 IAM。

GKE

GKE 采纳了 Kubernetes 的安全功能并且添加了一些自己谷歌云的安全功能，如 IAM 和 RBAC。

安全基准测试工具


Docker Bench

这是一个根据互联网安全中心（ CIS ）创建的基准清单，来检查生产环境中的容器的安全状况的脚本。

Inspec

这是一个由 Chef 构建的测试框架，它将合规性和安全性视为代码。此外，它可以扫描镜像并拥有自己的一个 Docker Bench 版本。

网络安全工具



Project Calico

通过提供基于策略的安全保障来保护容器网络，并确保服务只能访问其所需要的服务和资源。

Weave

该工具为容器网络强制实施基于策略的安全保障，并且为每个容器而非整个环境提供防火墙。

Canal

集成了 Project Calico 的安全功能和 Flannel 的连接功能，为容器提供了全面的网络解决方案。

编排安全工具


Docker Swarm Secrets Management

用安全的方式来使用 Docker Swarm 存储密码、token 以及其他机密数据。

Kubernetes Security Context

保证在 Kubernetes 集群中容器和 pod 的安全，并提供访问控制及 SELinux 和 AppArmor 等 Linux 内核安全模块。

镜像扫描工具


Docker Hub 安全扫描

该工具根据常见漏洞和暴露列表（ CVEs ）扫描从 Docker Hub 下载的镜像。

Docker Content Trust

该工具可以根据作者验证从第三方文件库下载的镜像，作者可是个人或组织。

Quay Security Scanner

该工具由 CoreOS Clair 提供支持。这是 Quay Docker 安全扫描版本，它可以扫描容器镜像漏洞。

AWS ECR

作为 AWS ECS 的一部分，ECR 在 S3 中静态加密图像，并通过 HTTPS 传输。它使用 AWS IAM 控制对镜像仓库的访问。

**内核安全工具**


**命名空间（ Namespaces ）**

命名空间隔离了相邻的进程，并且限制了容器所能看到的内容，因此可以防止攻击的蔓延。

**cgroups **

该工具限制了容器使用的资源，限制容器可以使用的内容，从而防止受感染的容器占用所有的资源。

**SeLinux**

该工具为内核提供访问控制。它强制执行“强制访问控制（ MAC ）”，依据策略控制了容器访问内核的方式。

**AppArmor**

该工具可以启用进程访问控制，可设置强制执行策略，亦可设置为仅在违反策略时发出报告。

**Seccomp**

该工具允许进程以“安全”状态与内核进行交互，“安全”状态下仅可执行数量有限的一些命令。如果超出命令，那么进程将被终止。

结语

我们正在一步步更快地向微服务架构的世界迈进，与此同时，越来越多的开源项目涌现，以期为那些真正想要做到“云原生”的组织及个人服务。CNCF 有大量优秀却未必广为人知的项目，本文只涵盖了其中一部分，建议您也可以多了解其他的项目，为未来储备。

RKT


最后一个值得关注的项目是 rkt （也称为 Rocket ），一个容器运行时。尽管 Docker 的 containerd 运行时可能是以推广容器概念的容器为目的的运行时，但是 Docker 仍然是编排生态系统中常用的运行时，因此我们相信 RKT 在后期会变得越来越受欢迎。

两者之间的差异也是显而易见的。虽然 Docker 已经选择了在集群中打包，并由一个守护进程和通过 REST API 与保护进程通信的可执行程序组成，但是 rkt 要简单得多。它由一个简单的命令行工具组成，当给定一个镜像、一个规范格式和一个镜像发现机制时，rkt 就能运行一个容器。

使用 RKT，用户可以在配置容器运行时时避免像 systemd 这样的问题。此外，rkt 不仅可以运行 App Container format 中的镜像，还可以运行标准的 Docker 镜像。

GPRC



到目前为止，我们已经知道了如何部署、调度和了解云中的微服务。但是他们之间的交流方式是什么呢?

让我们来看看“远程程序调用（ RPC ）”。

远程程序调用的概念已经存在了一段时间了，它指的是一种模式，在这种模式中，函数被称为远程调用，通常在系统中使用，而不是基于 RESTful 服务的 CRUD 模型。

但是，gRPC 指的是谷歌实现的远程程序调用，它利用了 http/2 和协议缓冲区。与基于 jsf 的 RPC 相比，gRPC 已经被证明在数量级上更快，这使得它成为大型分布式平台的优秀选择。事实上，etcd （来自 CoreOS 的流行键值存储）和谷歌自己的 BigTable 都是 gRPC ！

OPENTRACING



值得关注的第三个项目是分布式跟踪。随着单体应用程序被分解为各种更小的服务，自然会有越来越多的数据在服务中传输，从前端传输到后端，从一个服务传输到另一个服务。但是，当一个具有各种依赖关系的公共应用程序突然出现延迟时，会发生什么情况呢？这就是分布式跟踪的由来。其核心在于，跟踪是通过不同的请求调用、线程和流程来传播元数据，并最终基于此元数据构建一个图表。

OpenTracing 是一种跟踪标准，它是为响应分布式跟踪领域长期存在的问题而创建的——即，当一个公司的堆栈可能由大量第三方软件、操作系统和自定义应用程序组成的时候，如何协调跟踪？

OpenTracing，一种标准化的跟踪程式，就是这一难题的解决方案。该项目为跨越（即定时操作）管理和进程间传播，提供了的设备 API 的标准化服务。因此，用户可以轻松地切换到跟踪库或集中式跟踪系统（如 Zipkin、Dapper 等），无须复杂的配置，免去了很多麻烦。

FLUENTD



度量只是微服务应用程序可见性难题的一个方面。集中化的日志则是另一个。

随着应用程序的数量和公司规模的增长（尤其是越来越多的服务被容器化），在一个地方收集、分析和查询结构化日志是非常重要的。

这就是 Fluentd 的初衷。Fluentd 是一个日志收集器（类似于 logstorage ），通过它可以对日志进行过滤、净化和路由到各种目的地。与其他日志收集器一样，Fluentd 可以与各种核心和第三方输入及输出插件（如 Elasticsearch 插件、S3 插件等）一起使用。

Fluentd 还具有一定的内存存储和可靠性。从多个主机到 Fluentd、接着到 Elasticsearch 集群的 rsyslog 文件的日志路径极其简洁，这一简单的例子也充分证明了使用 Fluentd 的益处所在。

LINKERD



第一个是 Linkerd，一个基于微服务的原生云应用程序的开源“服务网格（ service mesh ）”项目。

Linkerd 背后的想法是：微服务固然很好，但是只有当你有一个好方法来连接它们、形成完整的应用程序时，微服务的好处才能够体现。如若不然，你的微服务应用程序就会变成一个笨重的移动部件，它们彼此也不能很好地结合在一起。

Linkerd 是一个开源项目，旨在通过提供开发人员所说的“服务网格”来解决上述挑战。Linkerd 的服务网格提供了一个方便可靠的接口，不同的服务可以交互运行。除了通过为连接服务提供简单的方式和一致的抽象层来简化程序员的工作之外，Linkerd 还具备可伸缩性、高可用性和安全性等特点。该项目由 Buoyant 监管，于 2017 年初加入 CNCF。