解决隔离和容器通讯、操作和开发之间的内在张力意味着所采取的措施既要控制容器内部相互影响的程度，也要限制通过插孔或开放的端口进入到Docker 群组的容器的数量。
3.加强用户访问控制
直到最近，根在默认情况下访问Docker主机是一个非此即彼的命题，使安全专员对此十分焦虑。虽然限制访问容器主机根账户花费了他们大量的精力——并且推动了Docker在系统中删除特权访问这一新功能的投资——对安全更广泛的关注是对特权账户的强制访问控制和部署管道的操作运行。显而易见，扩大创建实用有效的访问控制规模很有益处：可以保证问责性和操作一致性。
问责需要一定的能力以便查明是什么改变了容器的设置或配置或下载图像或在生产中创建了一个容器。拥有通用的根访问权限之后，要确定是什么做出了改变几乎是不可能的。即使根访问可能是开发人员在工作过程中所需要的最简单的一种访问方式，这也意味着他们有太多的访问权限。此外，得到访问根账户权限的攻击者就相当于得到了任意访问容器的权限，包括其数据和程序。
应用集中管理约束条例使用户可以基于自己的角色做出更改或命令，而不是他们访问根账户的能力，使企业能够定义和执行标准流程。实现职责分离访问和基于用户角色的命令约束条例是确保通过软件开发生命周期的基础。
如果不采取集中的方式，很难确定每个容器中不同的用户和其对应的不同的特权是否合适，与其职能作用和最小访问特权是否一致。
4.硬化主机
容器化最重要的好处之一就是它独立于应用程序，可以在任何地方独立运行而不依赖于任何自给系统。
一个重要的意义是有了专门的工具来限制哪些是自给系统可以访问和使用的，哪些是不可以访问和使用的。对照组和命名空间是关键容器的隔离元件。对照组决定一个容器可以使用多少共享内核和系统资源。命名空间决定了一个容器可以“查看”或有效确定容器被授权访问哪些资源。这些组件的设计目标非常明确：无论你想在哪个服务器中运行多种服务，这些服务彼此尽可能相互隔离，这是确保安全性和稳定性至关重要的一点。
严苛的细节确保了对照组和命名空间中配置的恰当性和一致性，并且保证了配置和安全政策相符。
尽管对照组和命名空间隔离可以用来限制对容器中内核资源的访问，但它并不能有效地隔离容器的执行路径。资源隔离对检测和预防滥用特权或打破容器中的“箱”等扩大化攻击无效。
在运行防御和容器分析过程中缺少分层法来保证对其的有效控制和可见性，由于配置错误或攻击者采取明确的行动操控命名空间，容器的安全性很容易就被破坏了。例如，容器环境下拒绝服务攻击与“流氓”容器消耗更多的内核资源和挤占其他过程并无二致。
5.容器安全过程的自动化
在安全性领域，将安全的理念落实到实际操作中去——而且不仅仅是随后在书面上描摹它——像是一个遥不可及的梦想。尽管在DeVops和安全团队中存在着一些领域或文化分歧，将安全渗透到容器的创建、传送和运行的过程中毫无疑问是企业最感兴趣的。这不仅会使内部应用程序更加安全，也会调动DeVops和安全团队的积极性，培养更具协作性的文化。
由于安全团队往往没有意识到导致容器在生产中运行的过程，重要的是要涉及到他们工作流程的定义和促进知识的转化。因此，他们可以给适当的控制和实践提供指导原则以满足其安全标准和审计要求。
换句话说，DeVops应该做它们最擅长的事情：自动化。基于容器的应用程序开发过程已经实现高度自动化。使用CI/CD和业务流程工具是在容器的整个生命周期中保障安全的最佳实践，这使建立安全管理框架的过程变得透明和相对安全简单。它将建立一个高度安全基线，减少了对后续安全工作的需要，也降低了安全成为部署障碍的可能性。
我们都知道当安全不是优先级时发生了什么，所以除了回滚以外还有什么其他的选择吗？容器为正确地解决这一问题提供了一个很好的机会，因为他们已经完全实现了自动化。将安全过程自动化到可操作的工作流程中可能是一个新的安全措施，但是这并不是第一次在容器中出现，其自动化已经成为所有方面的业务（网络、存储等）的规范。安全仅仅成为另一种满足自动化的要求。