如何使用 Distroless 让你的容器更加安全

标签: docker kubernetes | 发表时间:2021-06-29 00:44 | 作者:K8sCat
出处:https://segmentfault.com/blogs

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

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

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

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

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

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

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

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

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

Distroless 基础镜像

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

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

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

构建 Distroless 镜像

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

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

有两种方法:

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

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

必要条件

你需要具备以下内容:

  • Docker 版本大于等于 17.05,用于构建镜像
  • 可选的 Kubernetes 集群用于实践练习的第二部分。如果你想在 Docker 中运行你的容器,你可以使用等价的 docker 命令。

GitHub 代码仓

作为实践练习,将 此代码仓 Fork 到你的 GitHub 帐号下,然后克隆 GitHub 代码仓并使用 cd 进入到项目目录下。

该代码仓包含一个 PythonFlask 应用程序,当你调用API时,该应用程序会响应 Hello World!

app.py 文件如下所示:

  from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello World!"

if __name__ == '__main__':
    app.run(host='0.0.0.0', debug=True)

Dockerfile 包含两个阶段:

  FROM python:2.7-slim AS build
ADD . /app
WORKDIR /app
RUN pip install --upgrade pip
RUN pip install -r ./requirements.txt

FROM gcr.io/distroless/python2.7
COPY --from=build /app /app
COPY --from=build /usr/local/lib/python2.7/site-packages /usr/local/lib/python2.7/site-packages
WORKDIR /app
ENV PYTHONPATH=/usr/local/lib/python2.7/site-packages
EXPOSE 5000
CMD ["app.py"]

构建阶段:

  • 从 python:2.7-slim 的基础镜像开始
  • 将应用程序复制到 /app 目录下
  • 升级 pip 并安装依赖

Distroless 阶段:

  • 从 gcr.io/distroless/python2.7 的基础镜像开始
  • 将应用程序从构建阶段的 /app 目录复制到当前阶段的 /app 目录
  • 将 python 的 site-packages 从构建阶段复制到当前阶段的 site-packages 目录
  • 设置工作目录到 /app,将 python PATH 设置为 site-packages 目录,并暴露 5000 端口
  • 使用 CMD 指令运行 app.py

由于 Disroless 镜像不包含 shell,所以应该在最后使用 CMD 指令。如果不这样做,Docker 将认为它是一个 shell CMD,并试图这样执行它,但这是不工作的。

构建镜像:

  $ docker build -t <your_docker_repo>/flask-hello-world-distroless .
Sending build context to Docker daemon  95.74kB
Step 1/12 : FROM python:2.7-slim AS build
 ---> eeb27ee6b893
Step 2/12 : ADD . /app
 ---> a01dc81df193
Step 3/12 : WORKDIR /app
 ---> Running in 48ccf6b990e4
Removing intermediate container 48ccf6b990e4
 ---> 2e5e335be678
Step 4/12 : RUN pip install --upgrade pip
 ---> Running in 583be3d0b8cc
Collecting pip
  Downloading pip-20.1.1-py2.py3-none-any.whl (1.5 MB)
Installing collected packages: pip
  Attempting uninstall: pip
    Found existing installation: pip 20.0.2
    Uninstalling pip-20.0.2:
      Successfully uninstalled pip-20.0.2
Successfully installed pip-20.1.1
Removing intermediate container 583be3d0b8cc
...................................
Successfully installed Jinja2-2.11.2 MarkupSafe-0.23 click-7.1.2 flask-1.1.2 itsdangerous-0.24 werkzeug-1.0.1
Removing intermediate container c4d00b1abf4a
 ---> 01cbadcc531f
Step 6/12 : FROM gcr.io/distroless/python2.7
 ---> 796952c43cc4
Step 7/12 : COPY --from=build /app /app
 ---> 92657682cdcc
Step 8/12 : COPY --from=build /usr/local/lib/python2.7/site-packages /usr/local/lib/python2.7/site-packages
 ---> faafd06edeac
Step 9/12 : WORKDIR /app
 ---> Running in 0cf545aa0e62
Removing intermediate container 0cf545aa0e62
 ---> 4c4af4333209
Step 10/12 : ENV PYTHONPATH=/usr/local/lib/python2.7/site-packages
 ---> Running in 681ae3cd51cc
Removing intermediate container 681ae3cd51cc
 ---> 564f48eff90a
Step 11/12 : EXPOSE 5000
 ---> Running in 7ff5c073d568
Removing intermediate container 7ff5c073d568
 ---> ccc3d211d295
Step 12/12 : CMD ["app.py"]
 ---> Running in 2b2c2f111423
Removing intermediate container 2b2c2f111423
 ---> 76d13d2f61cd
Successfully built 76d13d2f61cd
Successfully tagged <your_docker_repo>/flask-hello-world-distroless:latest

登录到 DockerHub 并推送镜像:

  docker login
docker push <your_docker_repo>/flask-hello-world-distroless:latest

登录到 DockerHub(或者你的私有镜像仓),你应该会看到容器镜像可以使用:

如果你看一下压缩后的大小,它只有 23.36 MB。如果你使用 slim 发行版作为基础镜像,它将占用 56 MB。

你已经减少了超过一半的容器占用空间。That’s amazing!

在 Kubernetes 中运行容器

为了测试构建是否有效,让我们在 Kubernetes 集群中运行容器。如果你没有 Kubernetes,你可以运行等价的 Docker 命令来做相同的活动,因为 Kubectl 和 Docker 命令是相似的。

我在代码仓中创建了一个 kubernetes.yaml 文件,该文件包含使用我们构建的镜像的 Deployment 和 负载均衡的 Service

  ---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: flask-deployment
spec:
  selector:
    matchLabels:
      app: flask
  replicas: 2
  template:
    metadata:
      labels:
        app: flask
    spec:
      containers:
      - name: flask
        image: bharamicrosystems/flask-hello-world-distroless
        ports:
        - containerPort: 5000
---
apiVersion: v1
kind: Service
metadata:
  name: flask-service
spec:
  selector:
    app: flask
  ports:
    - port: 80
      targetPort: 5000
  type: LoadBalancer

这是一个非常简单的设置。负载均衡器监听端口 80 并映射到目标端口 5000。这些 Pods 在默认的 5000 端口上监听 Flask 应用程序。

应用:

  $ kubectl apply -f kubernetes.yaml
deployment.apps/flask-deployment created
service/flask-service created

我们查看一下所有的资源,看看我们已经创建了什么:

  $ kubectl get all
NAME                                    READY   STATUS    RESTARTS   AGE
pod/flask-deployment-576496558b-hnbxt   1/1     Running   0          47s
pod/flask-deployment-576496558b-hszpq   1/1     Running   0          73s

NAME                    TYPE           CLUSTER-IP   EXTERNAL-IP      PORT(S)        AGE
service/flask-service   LoadBalancer   10.8.9.163   35.184.113.120   80:31357/TCP   86s
service/kubernetes      ClusterIP      10.8.0.1     <none>           443/TCP        26m

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/flask-deployment   2/2     2            2           88s

NAME                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/flask-deployment-576496558b   2         2         2       89s

我们看到存在两个 Pods、一个 Deployment、一个带有外部 IP 的 LoadBalancer 服务和一个 ReplicaSet

让我们访问应用程序:

  $ curl http://35.184.113.120
Hello World!

我们得到了 Hello World!。这表明 Flask 应用程序在正常工作。

使用 Shell 对应用程序进行访问

正如我在引言中所描述的, Disroless 容器中没有 shell,因此不可能进入到容器内。然而,让我们试着在容器中执行 exec:

  $ kubectl exec -it flask-deployment-576496558b-hnbxt /bin/bash
OCI runtime exec failed: exec failed: container_linux.go:349: starting container process caused "exec: \"/bin/bash\": stat /bin/bash: no such file or directory": unknown
command terminated with exit code 126

我们无法连接到容器上。

容器日志呢?如果拿不到容器日志,我们就失去了调试应用程序的方法。

让我们试着去拿日志:

  $ kubectl logs flask-deployment-576496558b-hnbxt
 * Running on http://0.0.0.0:5000/
 * Restarting with reloader
10.128.0.4 - - [31/May/2020 13:40:27] "GET / HTTP/1.1" 200 -
10.128.0.3 - - [31/May/2020 13:42:01] "GET / HTTP/1.1" 200 -

所以容器日志是可以被获取到的!

结论

使用 Distroless 作为基础镜像是一种令人兴奋的保护容器安全的方式。由于镜像小并且仅包含应用程序和依赖项,因此它为应用程序提供了最小的攻击面。它在更大程度上提高了应用程序的安全性,所以它是保护容器安全的好方法。

谢谢阅读!我希望你喜欢这篇文章。

原文链接

本文翻译自 How to Harden Your Containers With Distroless Docker Images

相关 [distroless 容器 安全] 推荐:

如何使用 Distroless 让你的容器更加安全

- - SegmentFault 最新的文章
使用 Distroless 镜像来保护 Kubernetes 上的容器. 容器改变了我们看待技术基础设施的方式. 这是我们运行应用程序方式的一次巨大飞跃. 容器编排和云服务一起为我们提供了一种近乎无限规模的无缝扩展能力. 根据定义,容器应该包含 应用程序 及其 运行时依赖项. 然而,在现实中,它们包含的远不止这些.

Docker容器安全性分析

- - FreeBuf互联网安全新媒体平台
Docker是目前最具代表性的容器技术之一,对云计算及虚拟化技术产生了颠覆性的影响. 本文对Docker容器在应用中可能面临的安全问题和风险进行了研究,并将Docker容器应用环境中的安全机制与相关解决方案分为容器虚拟化安全、容器安全管理、容器网络安全三部分进行分析. 一、从虚拟化安全到容器安全 .

云原生之容器安全实践

- - IT瘾-tuicool
笔者主要负责美团内部操作系统安全、云原生安全、重大高危漏洞应急响应. 10+年安全行业经验,熟悉多个安全领域,涉及渗透测试、Web安全、二进制安全、Iot安全、Linux/Android内核安全等,6+年的时间到至今,长期专注于Linux内核安全及开源软件安全. 21岁时受邀在第一届中国互联网安全领袖峰会(CSS)演讲,知名Linux/Android内核远程漏洞CVE-2017-8890发现者.

初识容器安全项目 Falco

- - DockOne.io
容器化普及进行的如火如荼,但是无论是公有云环境还是企业内部的容器化环境,都有可能会面对部分异常的用户行为,有些是有意为之,有些可能是无意之失,但是都可能给容器底层的主机造成安全的隐患. 容器的工作模式是共享宿主机内核,从出道以来就面临着各种安全的问题,比如 Fork 炸弹会一直耗尽主机的进程资源、容器逃逸获取到主机各种资源等都可能带来安全隐患(部分安全隐患已经得到了有效的解决,但是仍然存在众多的情况会造成安全问题).

浅析 Docker 容器安全管控方法

- - IT瘾-dev
二、浅析Docker容器生命周期安全问题. 2.3 容器系统入侵检测与防护. 2.4 容器网络入侵检测与防护. 2.6 Docker及其配套软件漏洞. 三、浅谈Docker容器安全现状改善方法. 3.1 “镜像深度扫描”管控方法. 3.2 “容器系统入侵检测与防护”管控方法. 3.3 “容器网络入侵检测与防护”管控方法.

容器安全扫描工具推荐 (insights.thoughtworks.cn)

- - IT瘾-jianshu
在现代软件开发中, 我们会使用一些公共镜像作为基础镜像来快速构建我们的应用镜像,并将其部署到生产环境中. 随着越来越多的应用程序被容器化,容器安全也随之变得越来越重要. 在项目的 流水线 中, 我们可以使用漏洞扫描器进行扫描并提前获得反馈,实现 “安全左移” ,也可以更好的实践敏捷. 基于容器的应用程序的安全痛点.

Terrier:一款功能强大的镜像&容器安全分析工具

- - FreeBuf互联网安全新媒体平台
Terrier是一款针对OCI镜像和容器的安全分析工具,Terrier可以帮助研究人员扫描OCI镜像和容器文件,并根据哈希来识别和验证特定文件是否存在. 如需了解源代码安装步骤,请参考项目的. 工具使用必须扫描镜像的OCI TAR,这个值需要通过cfg.yml文件提供给Terrier. 下列Docker命令可以用来将一个Docker镜像转换成一个TAR文件,并提供给Terrier扫描:.

谁更安全?

- iceman.yu - 比特客栈的文艺复兴
原文:The triumph of coal marketing – Seth Godin. 翻译+整理:David Frank. 你对核能发电是不是也有一些看法. 相比其他的发电方式,它们谁更安全. 数据来自这里,图片来自这里,上图是一幅毫不夸张的数据简化图. 同样的发电量,每当核能发电误杀一个人,煤炭发电会导致4,000人的死亡.

网络安全

- - CSDN博客系统运维推荐文章
1、防止入侵者对主机进行ping探测,可以禁止Linux主机对ICMP包的回应.  iptables 防火墙上禁止ICMP应答.  关闭不必要的端口,时常检查网络端口情况.  nmap  可以扫描端口.  关闭不必要的服务和端口.  为网络服务指定非标准的端口.  开启防火墙,只允许授权用户访问相应的服务端口.

安全机制

- - 开源软件 - ITeye博客
ActiveMQ中所有安全相关的概念都是通过插件的形式实现的.这样可以通过ActiveMQ的XML. 配置文件的元素来简化配置和自定义安全认证机制.ActiveMQ提供两种认证方式:.     简单认证插件 -- 直接通过XML配置文件或者属性文件处理认证.     JAAS认证插件 -- 实现了JAAS API,提供一种更强大的可自定义的认证解决方案.