理论上，是的。实际上，也许。
我们常说，“HTTPS安全”，或者“HTTP不安全”。但我们真正的意思是，“HTTPS更难以窃听，难以进行中间人攻击”，或者“电脑小白都能偷听HTTP通信”。
然而，HTTPS已经被黑过了，而某些情况下，HTTP已足够安全。而且，一旦在支持HTTPS的常用实现中发现可利用的缺陷(想想OpenSSL和心脏滴血)，HTTPS就会在该实现被修正之前都被当成入侵的门道。
HTTP和HTTPS是IETF(互联网工程任务组) RFC 7230-7237和2828中定义的协议。HTTPS被设计成HTTP的安全版本，但说HTTPS安全而HTTP不安全，却隐藏了重要的例外情况。
虚拟机(VM)和容器的定义没那么严格，也没有被特意设计成谁比谁更安全。因此，这里面的安全问题就更加隐晦了。
为什么虚拟机比容器更安全
分治法，在战争和软件界都是制胜法宝。架构师将单一复杂安全问题分解为更简单的多个问题时，大多数情况下，结果都会比包揽所有问题的单个解决方案更安全。
容器，就是一个将分治法水平铺开到多个应用中的例子。通过将每个应用限制在自己的范围里，单个应用中的弱点便不能影响到其他容器中的应用。VM同样采用分治思想，但它们的隔离又更进了一步。
被隔离应用中的漏洞不能直接影响到其他应用，但被隔离应用会破坏与其他容器共享的操作系统(OS)，进而影响到所有容器。共享操作系统的情况下，应用、容器和OS实现栈中任意一点上的缺陷，都可以令整个堆栈的安全性失效，侵害到物理机器。
虚拟化之类的分层架构，则将每个应用的执行栈从上到下从软件到硬件地隔离开，清除掉共享OS造成应用间相互影响的可能性。另外，每个应用栈与硬件之间的接口都有定义，从而限制了滥用可能。这给各应用间独善其身创造了格外坚实的边界。
虚拟机管理程序控制着客户OS与硬件间的交互，VM就是通过该管理程序隔离开了控制用户活动的OS。VM客户OS控制着用户活动，但不参与硬件交互。某应用或客户OS中的漏洞，不可能影响到物理硬件或其他VM。VM客户OS和支持容器的OS相同的时候(这种情况很常见)，OS上会破坏所有其他容器的漏洞，却不会危害到其他VM。由此，VM不仅水平分隔应用，也纵向隔离了OS和底层硬件。
VM开销
VM提供的额外安全性是有代价的。计算系统中，控制转移往往开销巨大，从处理器周期和其他资源耗用上都可以呈现出来。执行栈需要存储和重置，外部操作可能不得不挂起或允许继续完成，诸如此类。
客户OS和虚拟机管理程序间的切换开销很大，且经常发生。即便处理器芯片中烧录进特殊控制指令，控制转移开销也降低了VM的整体效率。这种降低很巨大吗?难说。可以通过管理控制转移，来调整应用，减低开销;大多数服务器处理器如今也设计成了简化控制转移的类型。换句话说，效率降低大不大，取决于应用和服务器，但“开销不可能被完全清除”这一点是毫无争议的。
虚拟机管理程序漏洞
更糟糕的是，VM架构中的分隔层还引发了另一个潜藏的幽灵：虚拟机管理器漏洞。虚拟机管理程序被破坏，可能导致牵一发而动全身的巨大后果，尤其是在公共云环境中。可以想见，仅仅一个漏洞利用，就可以让一名黑客，在控制着其他公共云消费者应用的VM上执行代码，掌控公共云的一部分。
再坚如磐石的架构，也会有可大幅削弱系统的实现缺陷。虚拟机管理器被黑事件常常被大言不惭的声明搪塞过去：理由是虚拟机管理程序太简单了，而且写得很完美，也经过了超仔细的审查，所以永远不会出故障，不会被黑。虚拟机管理程序漏洞利用的破坏性堪比WannaCry，但也不用太担心这一点。不过，心脏滴血确实发生了，而OpenSSL的代码行数也远远不及虚拟机管理程序多。
目前为止还没出现什么重大虚拟机管理程序安全事件。但稍微瞄一眼通用漏洞与暴露(CVE)数据库，就可以知道研究人员们确实找到了可以利用的虚拟机管理程序漏洞。虚拟机管理程序开发者和厂商的补丁速度倒是也不算慢。2017年3月，微软发布安全公告 MS17-008，记录了7个已打补丁的Hyper-V虚拟机管理程序漏洞——全部被认定为关键级别漏洞。
VM比容器的安全性更高，但我们也必须仔细审查VM系统的安全。而且，容器和VM往往捆绑在一起，需要注意的点还很多。
