企业Docker实施面面观
如果企业已经实施了软件开发生命周期(SDLC)流程,那么就要考虑Docker和它适应的问题:
该问题与上面已经提到的镜像扫描方案密切相关。可能需要在某些时候考虑将其与现有SDLC流程集成。 密码管理 在实施中数据库密码等信息需要传递到容器中。可以通过构建时(不建议)或运行时来完成该项工作。 如何在容器内管理密码? 是否对密码信息的使用进行了审核/跟踪并确保安全? ![]() 和镜像签名一样,密码管理也是一个仍在快速变化的新兴领域。业界有OpenShift/Origin与Hashicorp Vault等现有集成解决方案。Docker Swarm等核心组件中也有对密码管理的支持,Kubernetes 1.7加强了其密码安全功能。 基础镜像 如果在企业中运行Docker,则可能需要在公司范围内强制使用基础镜像:
安全和审计 root权限 默认情况下,访问docker命令(特别是访问Docker UNIX套接字)需要机器root权限。对于生产环境中的来说,这是不可能接受的。需要回答以下问题:
这些都有解决方案,但它们相对较新,通常是其他更大解决方案的一部分。 例如,OpenShift具有强大的RBAC控制功能,但需要购买整个平台。Twistlock和Aquasec这样的容器安全工具提供了一种管理这些工具的方法,可以考虑集成他们。 ![]() 运行时监控 企业可能希望能够确定线上容器运行情况。 如何知道线上运行了哪些容器? 这些运行中的容器,怎样容器注册表?怎么关联的,怎么在容器注册表中管理的? 启动以后,容器都更改过哪些关键性的文件? 同样,这还有其他一些问题,这些构成Docker基础运行策略。在这方面另一个经常被供应商提起的功能是异常检测。安全解决方案提供了诸如花哨的机器学习的解决方案,声称可以通过学习容器该做什么,并对可能的异常活动发出告警。例如连接到与应用程序无关的外部应用程序的端口。虽然听起来不错,但是需要考虑一下如何运维他们。一般来说可能会有大量的误报,需要大量调整和回归验证的,是否有人力和资金来维持运维,是问题的关键。 审计 当发生问题后,我们需要知道发生了什么。在物理和虚拟机的架构体系中,有很多安全措施来协助故障调查。而Docker容器的体系下,有可能是一个没有"黑匣子记录"的。 能马上查询出谁在运行容器吗? 能马上查询出谁构建了了容器吗? 要删除容器时,能快速确定该容器的作用吗? 要删除容器时,能确定改容器可能做了什么吗? (编辑:西安站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |