概述当前Docker容器化架构非常流行，越来越多的企业开始使用容器来构建自己的基础设施。通常，您自己构建Docker注册中心，在服务器上部署安装Docker，并通过Docker插件JenkinsCI管道安装Jenkins来管理Docker容器。在更大的规模上，将使用K8S或Swarm来编排集群。对于一个企业来说，从开始尝试使用容器到逐渐深入，扩大规模要经历一系列的问题和踩坑的过程，那么如何规范安全的实施容器化，又如何尽量避免踩坑？这篇文章给出了一个清单，我列出了企业在尝试容器化架构时需要考虑的方方面面的问题，希望能对大家有所帮助。镜像问题ContainerregistryDocker服务都需要一个registry（不是我们常说的windowsregistry），Dockerregistry就是存放Docker镜像和在线（Web）版本仓库（类似于代码的github仓库）。公有云容器注册中心服务有很多，比如Docker官方的DockerHub，很多公有云都提供自己的Docker注册中心服务：除了这些公有注册中心，企业基于安全性、网络访问速度、标准化程度等，维护一个自己的-拥有的容器注册服务。构建的Docker注册表（Docker私有服务器）也是必需的。搭建Docker私服可以使用官方的DockerDistribution，它是Docker官方推出的DockerRegistry2的开源产品。它是用Golang开发的，大大提高了安全性和性能。著名的Git服务器端Gitlab也提供了Gitlab容器注册中心。部署Gitlab的企业可以直接考虑使用该组件实现统一管理和集成。当然，除了开源，也可以使用商业产品，比如Vmware的开源Harbor：企业在选择容器注册中心时需要考虑以下问题：注册中心是否可以集成到企业内部的统一身份系统（如LDAP、Kerberos等）？是否支持？基于角色的访问控制(RBAC)？统一认证授权是企业的一大难题。尽管快速且廉价的开放注册表解决方案足以满足开发环境的构建。但是，对于企业在线环境，必须考虑安全和RBAC标准。有没有办法加快镜像？镜像应该区别对待。有些是快速的、功能齐全的，但可能是混乱的开发环境镜像，它们不需要首先考虑正确性；而在线镜像应该侧重于安全性、性能和正确的保护。企业对这些镜像进行分类，并通过注册中心的实例管理流程或标签强制执行。是否与其他Artefact包管理架构保持良好的一致性？企业可能已经拥有包文件存储库、内部Artefact存储等（如maven、npm、Gitlab等）。在一个理想的架构中，容器注册表应该是它的一个功能。如果架构是分开的，那么两者的集成和管理开销就必须长期考虑。镜像扫描这是一个非常重要的部分。镜像上传到自建容器镜像仓库时，需要进行合规性检查。例如，检查以下问题：bash版本是否易受shell破坏？ssl库是否过时？该映像是否基于不安全或不可接受的基本映像？是否存在易受攻击或过时的库(Strus2)和工具？等。这些问题可以通过静态图像分析来检查。我们需要注意的是，这些扫描可能并不完美，可能会遗漏一些非常明显的漏洞，所以它不是解决所有安全问题的万能药，而是一种必要的手段，尤其非常适合解决：防止恶意攻击者注入木马？全企业统一标准？快速发现并修复已知和标准的CVE漏洞？这些问题构成了图像扫描评估的基础，当然还需要考虑集成成本。常见的镜像扫描工具有Clair、Anchore、OpenSCAP、Dockerscan等。如何构建镜像？企业应该支持哪些构建方法？如何结合这些方法？Dockerfiles最常用的标准方法之一也可以使用S2I、Docker+Chef/Puppet/Ansible甚至手动方法构建。使用该CM（配置管理，如果您已经使用）工具进行管理。能否重用标准治理流程来与配置管理交互？任何人都可以构建图像吗？行业经验表明，Dockerfile方法是一种广泛使用的通用方法，并得到大量社区文档和问题反馈的支持。尝试使用更复杂的CM工具来满足VM的公司标准通常有一定的实施门槛。使用S2I或者Chef/Puppet/Ansible的方式更方便，也可以实现代码（playbook）复用。镜像完整性要求确保在系统上运行的镜像在构建和运行之间没有被篡改。可以使用安全密钥对图像进行签名吗？是否有可以重复使用的密钥库？密钥库可以与所选工具集成吗？尽管Docker已经流行了很多年，但镜像完整性仍然是一个新兴领域。许多供应商仍在观望。Docker在这方面做了一些有益的工作，比如在Docker的企业数据中心产品之外部署了Notary（Docker的开源签名解决方案，已经转移到CNCF基金会）。第三方镜像如果想使用一键部署，直接使用供应商的镜像即可。是否有验证供应商图像的管理流程？我们不仅需要知道镜像是否安全，还需要知道谁可以在必要时更新镜像？这些图像可以被其他图像重复使用吗？这里存在潜在的许可问题。有没有办法阻止其他项目/团队重复使用图像？是否必须在特定环境（例如DMZ）中运行？Docker可以用在这些环境中吗？例如，许多网络级应用程序在网络设备上运行在相似的环境中，并且需要身份验证。因此，它必须与其他容器或项目工作环境隔离。需要考虑是否可以在这些环境中运行图像。SDLC如果您的组织已经实施了软件开发生命周期(SDLC)流程，那么请考虑Docker及其适用的问题：您如何处理补丁？您如何确定哪些图像需要更新？你如何更新它们？您如何通知您的团队更新？如果他们没有及时更新，如何强制他们更新？这个问题与上面提到的镜像扫描方案密切相关。在某些时候可能需要考虑与现有SDLC流程的集成。在密码管理的实现中，需要将数据库密码等信息传递给容器。这可以在构建时（不推荐）或运行时完成。如何在容器内管理密码？密码信息的使用是否经过审核/跟踪并受到保护？与图像签名一样，密码管理是一个仍在迅速变化的新兴领域。业界已有OpenShift/Origin、HashicorpVault等集成方案。DockerSwarm等核心组件也支持密码管理，Kubernetes1.7加强了密码安全特性。基础镜像如果您在企业中运行Docker，您可能需要在公司范围内实施基础镜像：这个基础镜像应该包含什么？您应该使用哪些标准工具？谁来管理集成图像？问题。此外，开发人员非常注重图像的简化。安全和审核Root权限默认情况下，访问docker命令（尤其是访问DockerUNIX套接字）需要机器root权限。对于生产环境，这是不可能接受的。需要回答以下问题：谁（组）有权运行docker命令？您如何管理谁有权运行它们？您如何控制可以运行的内容？这些都有解决方案，但它们相对较新，通常是计划中其他更大的解决方案的一部分。例如，OpenShift具有强大的RBAC控件，但需要购买整个平台。Twistlock和Aquasec等容器安全工具提供了一种管理这些工具并考虑集成它们的方法。运行时监控组织可能希望能够确定实时容器的运行方式。我如何知道哪些容器在线运行？这些正在运行的容器是如何在容器注册表中注册的？它们在容器注册表中如何关联和管理？启动后，容器修改了哪些关键文件？还有其他问题构成了Docker运行时策略的基础。供应商在这方面经常引用的另一个功能是异常检测。安全解决方案提供诸如奇特的机器学习之类的东西，声称可以了解容器应该做什么并提醒它们可能的异常活动。例如，连接到与应用程序无关的外部应用程序的端口。虽然这听起来不错，但需要考虑如何操作和维护它们。一般来说，可能会出现大量的误报，需要进行大量的调整和回归验证。是否有人力和资金维持运维是问题的关键。审计当出现问题时，我们需要知道发生了什么。在物理机和虚拟机的架构体系中，有很多辅助故障排查的安全措施。在Docker容器系统下，可能会有一个没有“黑盒记录”的。你能立即找出谁在运行容器吗？你能马上找出是谁建造了容器吗？当你想删除一个容器的时候，你能快速判断出这个容器是干什么的吗？当你想删除容器时，你能确定容器可能做了什么吗？在这方面，我们可能希望实施特定的日志记录系统解决方案，以确保有关系统活动的信息在容器实例中持续存在。Sysdig的Falco（现已转入CNCF基金会）是容器安全监控和审计领域一个有趣且有前途的工具。运行日志应用日志是企业关心的问题之一：容器是否记录运行所需的内容？日志是否遵循企业日志记录标准？日志记录在哪里？容器的日志可能与传统的机器部署模型有很大不同。日志存储空间可能需要支持水平扩展，可能需要增加存储空间等。容器编排为了让容器能够随着业务的变化快速扩展和迭代，需要一个编排系统进行统一管理。所选的编排架构是否适合Docker基础架构的其余部分？是要采用与主流架构背道而驰的编排架构，还是随波逐流？Kubernetes目前看来是拿下编排系统的市场。选择Kubenetes以外的架构可能需要一个很好的理由。操作系统企业在线操作系统远远落后于最新和最常见的版本。生产线上的标准操作系统能否支持Do??cker的所有最新特性？例如，某些编排系统和Docker本身可能需要比它们支持的更新得多的内核版本或软件包，这可能是一个非常棘手的问题。系统包管理默认支持的Docker版本是多少？Docker版本之间可能存在显着差异（例如，1.10差异很大），我们需要注意这些差异的细节。发行版提供的Docker（或“Moby”版本）之间也存在差异，这会产生很大影响。例如，RedHat的二进制docker包请求的顺序是RedHat的注册表在DockerHub之前。开发开发环境开发人员经常会要求获得系统管理权限。如何控制他们的权限？更好的做法是为开发者提供一个VM，让他们在本地构建Docker，或者只运行dockerclient，在统一的服务器上运行Dockerserver。他们的客户端是否与部署环境一致？如果他们在桌面上使用docker-compose，他们可能不愿意在UAT和生产环境中切换到Kubernetespod。CI/CDJenkins是最流行的CI工具，但还有其他流行的替代品，如TeamCity、GitlabCI等。Docker引入了许多开发人员渴望使用的插件。其中很多都没有考虑到安全性，甚至可能与其他插件存在兼容性问题。您对CI/CD插件的策略是什么？您准备好释放大量新插件了吗？CI流程是否适用于短暂的Jenkins实例以及持久的、受支持的实例？基础设施共享存储Docker的核心是使用独立的卷来运行存储持久数据的容器。共享存储是否易于配置？NFS服务有其局限性，但已经成熟并且在大型组织中普遍得到很好的支持。共享存储支持能否满足您业务增长的需求？您是否需要跨部署位置提供共享存储？您可能有多个数据中心和/或云提供商。所有这些站点都可以相互交互吗？他们需要吗？网络企业通常有他们最喜欢的软件定义网络(SDN)解决方案，例如Nuage，或新的解决方案，例如Calico。您有规定的SDN解决方案吗？它如何与您选择的解决方案相互作用？SDN交互是否可能导致问题？aPaaS拥有像OpenShift或TutumCloud这样的aPaaS，可以通过集中Docker运行的上下文来解决上述许多问题。您是否考虑过使用aPaaS？云提供商如果您使用的是亚马逊或谷歌等云提供商，阿里云：如何在云提供商上提供图像和运行容器？您想将Docker解决方案与云提供商的产品相结合吗？连接，还是让它们与云供应商无关？选择解决方案时要注意的事项有两种方法可供选择。一种方法是使用来自单一供应商的整体式统一架构。另一种方法是使用来自多个供应商的个别优势产品，并将它们拼凑成一个企业解决方案。方法一的优点是：统一管理，统一认证。减少集成工作量和开销。交货更快。可以享受供应商更大的承诺和关注。对产品方向的可能影响更易于管理。单一供应商解决方案通常需要按节点付费，这会导致成本高昂，后续更换需要承担巨大损失，这也限制了内部架构。拼凑一体化解决方案的好处有：可以满足企业的需求，提供更灵活的不同费率的解决方案。通过整合他人的长处，你可以少走弯路，少犯错误。如果您有问题，可以随时调整和更换工具。从长远来看要便宜得多，而且不会被“锁定”给供应商、被抢劫、被吊死在树上。结论企业Docker架构和部署复杂多样。开发统一、经济高效、安全、完整和灵活的策略，可以快速交付而不会锁定，这是当今企业容器化面临的挑战之一。本文总结了企业Docker实施各个方面需要注意的问题，供大家参考。
