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

最后，您非常喜欢Docker，因此想要将具有敏感客户数据的在线关键业务生产系统移至Docker Swarm。有些甚至可能已经这样做了。另一个组织无法通过禁止在root模式下运行生产过程的策略来负担这一切。一个并不需要所有，但是所有它们都应该被评估。很大...而且永无止境。

那么-这些构建基块是什么？
安全设置-加固的内核，SELinux等。
考虑使用微型Docker基本映像，例如alpine，busybox甚至是便笺，例如从空的基础映像开始
使用root以外的用户设置
仔细评估以进一步减少授予容器的已缩减的内核功能集。进程，理想情况下是静态链接
那些想要破坏您的系统以获取shell访问权限的人可能想知道他们是否发现您的容器已禁用所有shell
仅在可能的地方安装只读卷

问题：还有什么？

我觉得这很广泛。但与此同时，我喜欢这个问题。因此，我将让社区对此做出决定：)

标签devsecops是什么意思？

还可以-devsecops.org/blog/2015/2/15/what-is-devsecops

您能解释一下为什么要考虑使用一个很小的Docker基础映像吗，例如alpine，busybox甚至是临时的。从空的基础映像开始可以增强安全性？

@ 030，安装的次数越少，可以更好地保护维护不足和/或可能被利用的不必要的服务/软件。减少到最低限度总是会更好，因为应该将每个容器用于提供一项服务。/目标。

#1 楼

在其上运行容器的主机

在运行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容器中部署Docker的常见最佳实践。 >生产。这些测试都是自动化的，并且受到CIS
Docker社区版基准测试
v1.1.0的启发。

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

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

#2 楼

Docker仍在开发中。

和所有其他软件一样，会发生开发中错误，可能会添加不安全的功能，并且可能存在导致安全漏洞的体系结构缺陷。不要小看这个！您的系统今天可能是完全安全的，但是在下周发布的补丁程序中，有人发现了一个错误，写了一个利用程序，突然您的系统便大开了。最新版本。而是使用经过良好测试的最新版本。

Docker不是虚拟化

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

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

Docker没有保护作用毫无疑问，Docker容器内部的运行是正常的。任何攻击者都可以简单地将其软件安装在容器中，并且Docker可以像运行其他任何代码一样运行该软件。

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

#3 楼

Docker映像本身

另一个选择是使用Clair。

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

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

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

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

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

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

#4 楼

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

使用dumb-init来控制Docker PID1

ref：PID1和僵尸获取问题

不要在没有容器编排系统的情况下在生产环境中运行docker

从Kubernetes，Mesos，Swarm等中进行选择。

使用gosu在docker映像内进行用户控制
遵循12要素应用范例，如果您在容器中运行有状态的应用，请对其进行更改。

如果您真的需要在容器中运行有状态的应用程序（mysql，zookeeper，elasticsearch），请使用诸如Kubernetes Statefulsets之类的协调器范例。使用hashicorp vault / consul之类的工具
将由开发人员构建的相同容器运送到CI管道中，以对其进行暂存和集成测试。
围绕CVE和补丁创建通知，触发构建patch-notify
具有广泛的loggi要了解正在运行的容器，您不希望授予开发人员SSH访问主机或容器的权限

推荐：fluentd

同时具有容器和主机指标

推荐：prometheus + node-exporter

#5 楼

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

使用诸如confd之类的工具来管理docker映像配置文件并保持更新
< br Confd将从许多受支持的键值存储中读取数据并动态呈现配置模板。

#6 楼

阅读官方Docker安全文章并将其与问题中定义的项目符号进行比较，以下几点也很重要：

通过实现ssl保护docker守护进程套接字使用公证人和DOCKER_CONTENT_TRUST变量进行内容信任

您应该尝试编译答案，该部分可以在您的其他两个答案中的任何一个内

–滕西拜
17年7月7日14:56在

#7 楼

人们可以使用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"]

编程黑洞网