distroless 镜像介绍及调试基于distroless 镜像的容器

1、概述

使用 Distroless 镜像来保护 Kubernetes 上的容器。

容器改变了我们看待技术基础设施的方式。这是我们运行应用程序方式的一次巨大飞跃。容器编排和云服务一起为我们提供了一种近乎无限规模的无缝扩展能力。

根据定义，容器应该包含 应用程序 及其 运行时依赖项。然而，在现实中，它们包含的远不止这些。标准容器基础镜像包含标准 Linux 发行版中可以找到的包管理器、shell 和其他程序。

虽然这些都是构建容器镜像所必需的，但它们不应该成为最终镜像的一部分。例如，一旦你把包安装好了，就不再需要在容器中使用 apt 等包管理工具了。

这不仅使你的容器里充满了不必要的软件包和程序，而且还为网络罪犯提供了攻击特定程序漏洞的机会。

你应该始终了解容器运行时中存在什么，并且应该精确地限制其只包含应用程序所需的依赖项。

除了那些必要的，你不应该安装任何东西。一些领先的科技巨头，如谷歌，有多年在生产中运行容器的经验，已经采用了这种方法。

谷歌现在通过提供 Distroless 镜像向全世界开放这种能力。谷歌构建的这些镜像的目标是只包含你的应用程序及其依赖项，同时它们将没有常规 Linux 发行版的所有特性，包括 shell。

这意味着虽然可以像以前一样运行应用程序的容器，但不能在容器运行的时候进入容器内。这是一个重大的安全改进，因为你现在已经为黑客通过 shell 进入你的容器关上了大门。

2、Distroless 基础镜像 

谷歌为大多数流行的编程语言和平台提供了 Distroless 的基础镜像。

以下基础镜像是正式发布的版本：

• gcr.io/distroless/static-debian10
• gcr.io/distroless/base-debian10
• gcr.io/distroless/java-debian10
• gcr.io/distroless/cc-debian10
• gcr.io/distroless/nodejs-debian10

下面的基础镜像仍在实验阶段，不推荐用于生产环境：

• gcr.io/distroless/python2.7-debian10
• gcr.io/distroless/python3-debian10
• gcr.io/distroless/java/jetty-debian10
• gcr.io/distroless/dotnet

3、构建 Distroless 镜像

谷歌在内部使用 Bazel 来构建容器映像，但是我们可以使用 Docker 来做同样的事情。关于使用 Distroless 镜像的一个有争议的问题是：当我们有一个 Distroless 镜像时，我们如何使用 Dockerfile 来构建我们的应用程序呢？

通常，Dockerfile 以一个标准的 OS 基础镜像开始，然后是创建适当的运行时构建所需执行的多个步骤。这包括包的安装，为此需要像 apt 或 yum 这样的包管理器。

有两种方法：

1. 先在 Docker 外部构建好你的应用程序，然后使用 Dockerfile 中的 ADD 或 COPY 指令将二进制包复制到容器中。
2. 使用多阶段 Docker 构建。这是 Docker 17.05 及以后版本的一个新特性，它允许你将构建分为不同的阶段。第一阶段可以从标准的 OS 基础镜像开始，可以帮助你构建应用程序；第二阶段可以简单地从第一阶段获取构建的文件并使用 Distroless 作为基础镜像。

为了理解它是如何工作的，让我们使用多阶段构建流程进行一个实际操作练习。

4、如何调试基于distroless 镜像的容器

distroless 镜像没有 sh,要想进入基于distroless镜像的容器内部需要通过 busybox，下面以fluentbit镜像为例介绍如何调试基于distroless镜像的容器。

下载 busybox 到宿主机：

wget https://busybox.net/downloads/binaries/1.21.1/busybox-x86_64

拷贝bubybox到当前宿主机的flentbit容器内部

chmod 777 busybox-x86_64
mv busybox-x86_64 busybox
docker ps | grep fluent-bit

docker cp busybox 35a8129b9702:/

通过busybox在容器内部调试基于distroless镜像的容器

kubectl exec -it -n kubesphere-logging-system fluent-bit-98d94 /busybox sh
/ # /busybox ls

5、Distroless 镜像和 Alpine 镜像应该如何选择？

如果是在生产环境中运行，并且注重安全性， Distroless镜像可能会更合适。

Docker镜像中每增加一个二进制程序，就会给整个应用程序带来一定的风险。在容器中只安装一个二进制程序即可降低整体风险。

举个例子，如果黑客在运行于Distroless的应用中发现了一个漏洞，他也无法在容器中创建Shell，因为根本就没有。

如果更在意要是大小，则可以换成Alpine基础镜像。

这两个都很小，代价是兼容性。Alpine用了一个稍稍有点不一样的C标准库——muslc，时不时会碰到点兼容性的问题。

说明：
原生基础镜像非常适合用于测试和开发。它的尺寸比较大，不过用起来就像你主机上安装的Ubuntu一样。并且，你能访问该操作系统里有的所有二进制程序。

6、结论

使用 Distroless 作为基础镜像是一种令人兴奋的保护容器安全的方式。它仅包含您的应用程序及其运行时依赖项。它们不包含您希望在标准 Linux 发行版中找到的包管理器、shell或任何其他程序。容器里并没有Shell！如果黑客入侵了我们的应用程序并获取了容器的访问权限，他也无法造成太大的损害。由于镜像小并且仅包含应用程序和依赖项，因此它为应用程序提供了最小的攻击面。它在更大程度上提高了应用程序的安全性，所以它是保护容器安全的好方法。不过，代价是调试更麻烦。

参考：https://segmentfault.com/a/1190000040255793

参考：https://zhuanlan.zhihu.com/p/406666870

参考：https://zhuanlan.zhihu.com/p/416356541

参考：https://www.jianshu.com/p/ae1da50901d1