在生产环境中运行Docker时应考虑哪些最佳和全面的实践？

最后，您非常喜欢Docker，因此想要将具有敏感客户数据的在线关键业务生产系统移至Docker Swarm。有些甚至可能已经这样做了。另一组织无法通过禁止在root模式下运行的生产流程的策略来承担该费用。

对于Docker生产环境，可以考虑的构建基清单清单是什么？一个并不需要所有，但是所有它们都应该被评估很重要。

免责声明：我知道有一个SE策略可以避免“无尽的大列表”，但是我认为此清单不能太大...反之亦然。

那么-这些积木是什么？

1. 如果尚未部署，请考虑运行具有高级安全设置的Linux主机系统-强化内核，SELinux等。
2. 考虑使用微小的Docker基本映像，例如alpine，busybox甚至是草稿，例如从空的基本映像开始
3. 使用除root以外的USER设置
4. 仔细评估以进一步减少授予容器的已缩减的内核功能集
5. 考虑每个容器只有一个可执行二进制文件来启动进程，理想情况下是静态链接
6. 那些想要破坏您的系统以获取外壳程序访问权限的人可能想知道他们是否发现您的容器已禁用所有外壳程序
7. 尽可能挂载只读卷

问题：还有什么？

运行容器的主机

在运行Docker容器的每个节点上运行Docker安全工作台https://github.com/docker/docker-bench-security

在运行Docker容器的节点上运行以下命令：

docker run -it --net host --pid host --cap-add audit_control \
    -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
    -v /var/lib:/var/lib \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v /usr/lib/systemd:/usr/lib/systemd \
    -v /etc:/etc --label docker_bench_security \
    docker/docker-bench-security

返回检查清单：

[INFO] 1 - Host Configuration

[WARN] 1.1  - Ensure a separate partition for containers has been created

[NOTE] 4.2  - Ensure that containers use trusted base images

[PASS] 4.6  - Ensure HEALTHCHECK instructions have been added to the container image

从资源库README中引用：

Docker Bench for Security是一个脚本，用于检查有关在生产环境中部署Docker容器的数十种常见最佳实践。这些测试都是自动化的，并且受到CIS Docker社区版Benchmark v1.1.0的启发。

通过阅读官方docker安全文章并将其与问题中定义的项目符号进行比较，可以解决安全工作台报告的某些问题，以下几点也很重要：

• 通过实现ssl保护docker daemon套接字
• 使用公证和DOCKER_CONTENT_TRUST变量的内容信任

Docker仍在开发中。

与其他所有软件一样，都会出现开发中的错误，可能会添加不安全的功能，并且可能存在导致安全漏洞的体系结构缺陷。不要小看这个！今天您的系统可能是完全安全的，但是在下周发布的补丁程序中，有人发现了一个漏洞，写了一个利用程序，突然，您的系统打开了。

除非您必须这样做，否则不要更新到最新版本。而是使用经过良好测试的最新版本。

Docker不是虚拟化

如果有人从Docker容器中逃脱，则该攻击者将立即在真实计算机上。没有像虚拟化这样的第二道门可以防止漏洞。

像对待其他程序一样对待Docker容器。以最低的用户权限运行，阻止所有不需要的网络流量，并在性能允许的情况下虚拟化整个Docker主机。

Docker不受保护

Docker容器中运行的任何代码都可以毫无疑问地从Docker运行。任何攻击者都可以简单地将其软件安装在容器内，而Docker将像其他任何代码一样运行该软件。

除了您在问题中提到的内容之外，请考虑使用指标和警报来通知是否有任何Docker映像在做奇怪的事情。是否有持续的CPU突然峰值？程序是否突然扫描网络端口？是否有可疑的磁盘访问？如果发生任何此类情况，您应该得到通知。有许多工具可以测量这些东西，您应该使用它们。

Docker映像本身

另一个选择是使用Clair。

Clair是一个开源项目，用于静态分析应用程序容器（当前包括appc和docker）中的漏洞。

Clair定期从一组配置的源中提取漏洞元数据，并将其存储在数据库中。

客户使用Clair API为其容器图像建立索引；这将创建图像中存在的功能列表，并将其存储在数据库中。

客户端使用Clair API向数据库查询特定图像的漏洞；每个请求都完成了漏洞与功能之间的关联，从而避免了重新扫描图像的麻烦。

发生漏洞元数据更新时，可以发送通知以警告系统已发生更改。

我们的目标是使基于容器的基础结构的安全性更加透明。因此，该项目以法语术语“ Clair”命名，该术语翻译为清晰，明亮，透明。

除了该线程中的要点；以下是我的建议：

• 使用dumb-init控制Docker PID1
  • 参考：PID1和僵尸收割问题
• 没有容器编排系统的情况下请勿在生产中运行docker
  • 从Kubernetes，Mesos，Swarm等中选择
• 将gosu用于Docker映像内的用户控制
• 遵循12要素应用程序范例，如果您正在容器中运行有状态的应用程序，请对其进行更改。
  • 如果您确实需要在容器中运行有状态的应用程序（mysql，zookeeper，elasticsearch），请利用诸如Kubernetes Statefulsets之类的协调器范例
• 使用hashicorp保险库/领事等工具进行可靠的秘密/配置管理
• 通过CI管道运送由开发人员构建的相同容器，以进行阶段，集成测试，从而进行生产。
• 围绕CVE和补丁创建通知，在补丁通知上触发构建
• 具有广泛的日志记录以深入了解正在运行的容器，您不想让开发人员通过SSH访问主机或容器
  • 推荐：流利
• 同时具有容器和主机指标
  • 推荐：prometheus + node-exporter

如果要使用sed命令填充docker入口点，请考虑以下做法：

• 使用confd之类的工具来管理您的docker映像配置文件并保持更新

Confd将从许多受支持的键值存储中读取数据并动态呈现配置模板。

可以使用A2D将应用程序烘烤到docker映像中，同时考虑某些因素，例如非root用户，权限，应用程序位置：

docker run -v $PWD:/projectName utrecht/a2d:1.0.0 \
       -projectName someProjectName -dockerfile /projectName/Dockerfile

返回：

FROM golang:1.12.4-alpine as builder
COPY . ./someProjectName/
WORKDIR someProjectName
RUN adduser -D -g '' someProjectName && \
    apk add git && \
    CGO_ENABLED=0 go build && \
    cp someProjectName /someProjectName && \
    chmod 100 /someProjectName

FROM scratch
COPY --from=builder /etc/group /etc/group
COPY --from=builder /etc/passwd /etc/passwd
COPY --from=builder --chown=someProjectName:someProjectName /someProjectName /usr/local/someProjectName
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
USER someProjectName
ENTRYPOINT ["/usr/local/someProjectName"]