企业Docker实施面面观( 二 ) _Docker

镜像完整需要确保系统上运行的镜像在从构建到运行之间没有被篡改过。
是否可以使用安全密钥来对镜像进行签名？
是否有可以重复使用的密钥库？
密钥库可以与选择的工具集成吗？
即使Docker流行了很多年，镜像的完整性仍然是一个新兴领域。很多的供应商的对此还持观望态度。Docker 公司在这方面做了一些有益的工作，比如Notary（Docker开源签名解决方案,已经转到CNCF基金会下）在Docker企业数据中心产品之外部署。

文章插图

第三方镜像

文章插图

如果希望使用一键部署，那么供应商的镜像则可以直接使用。
是否拥有验证供应商镜像的管理流程？
我们不光需要知道镜像是否安全，还需要知道谁可以在必要时更新镜像？
这些镜像可被其他镜像重用么？
这里有潜在的许可问题。是否有办法阻止其他项目/团队重用镜像？
是否强制要求运行于特定的环境（例如DMZ）？
Docker是否可以在这些环境中使用？
例如许多网络级应用程序运行在网络设备类似环境，并且需要认证，所以，它必须与其他容器或项目工作环境隔离。是否有可能在这些环境中运行镜像，需要考虑。
SDLC

文章插图

如果企业已经实施了软件开发生命周期（SDLC）流程，那么就要考虑Doc??ker和它适应的问题：
如何处理补丁？
如何识别哪些镜像需要更新？
如何更新它们？
如何通知团队更新？
如果他们不及时更新，如何强制他们更新？
该问题与上面已经提到的镜像扫描方案密切相关。可能需要在某些时候考虑将其与现有SDLC流程集成。
密码管理在实施中数据库密码等信息需要传递到容器中。可以通过构建时（不建议）或运行时来完成该项工作。
如何在容器内管理密码？
是否对密码信息的使用进行了审核/跟踪并确保安全？

文章插图

和镜像签名一样，密码管理也是一个仍在快速变化的新兴领域。业界有OpenShift/Origin与Hashicorp Vault等现有集成解决方案。Docker Swarm等核心组件中也有对密码管理的支持，Kubernetes 1.7加强了其密码安全功能。
基础镜像如果在企业中运行Docker，则可能需要在公司范围内强制使用基础镜像：
该基本镜像应该包含哪些内容？
应该使用哪种标准工具？
谁负责管理集成镜像？
需要提前准备好很多关于基本镜像的问题。另外开发人员非常注重镜像的精简。
安全和审计root权限默认情况下，访问docker命令（特别是访问Docker UNIX套接字）需要机器root权限。对于生产环境中的来说，这是不可能接受的。需要回答以下问题：
谁（组）有权能够运行docker命令？
怎么管理这些有运行权限的人员？
如何控制可运行的内容？
这些都有解决方案，但它们相对较新，通常是其他更大解决方案的一部分。
例如，OpenShift具有强大的RBAC控制功能，但需要购买整个平台。Twistlock和Aquasec这样的容器安全工具提供了一种管理这些工具的方法，可以考虑集成他们。

文章插图

运行时监控【企业Docker实施面面观】企业可能希望能够确定线上容器运行情况。
如何知道线上运行了哪些容器？
这些运行中的容器，怎样容器注册表？怎么关联的，怎么在容器注册表中管理的？
启动以后，容器都更改过哪些关键性的文件？
同样，这还有其他一些问题，这些构成Docker基础运行策略。在这方面另一个经常被供应商提起的功能是异常检测。安全解决方案提供了诸如花哨的机器学习的解决方案，声称可以通过学习容器该做什么，并对可能的异常活动发出告警。例如连接到与应用程序无关的外部应用程序的端口。虽然听起来不错，但是需要考虑一下如何运维他们。一般来说可能会有大量的误报，需要大量调整和回归验证的，是否有人力和资金来维持运维，是问题的关键。
审计当发生问题后，我们需要知道发生了什么。在物理和虚拟机的架构体系中，有很多安全措施来协助故障调查。而Docker容器的体系下，有可能是一个没有"黑匣子记录"的。