不，Docker容器並不比VM更安全。

引用 Daniel Shapira：

僅在2017年，發現了434個Linux內核利用程序，正如您在本文中所看到的那樣，內核利用程序對於容器化環境可能是毀滅性的。這是因為容器與主機共享同一內核，因此僅依靠內置保護機制是不夠的。

1。來自容器的內核漏洞利用

如果有人利用了容器內部的內核錯誤，他們就會在主機操作系統上對其進行利用。如果此漏洞利用允許代碼執行，它將在主機操作系統上執行，而不是在容器內部。

如果此漏洞利用允許任意的內存訪問，攻擊者可以更改或讀取任何其他容器的任何數據

在VM上，過程更長：攻擊者必須同時利用VM內核，管理程序和主機內核（這可能與VM內核不同）。 / p>

2。資源匱乏

由於所有容器共享相同的內核和相同的資源，因此，如果不限制對某些資源的訪問，則一個容器可以用盡所有資源並使主機操作系統和操作系統耗盡

在虛擬機上，資源是由管理程序定義的，因此，虛擬機管理程序本身可以配置為限制使用資源，因此任何虛擬機都不能拒絕任何資源的主機操作系統。

p>

3。容器突破

如果容器內的任何用戶能夠使用某些利用或配置錯誤逃脫該容器，則他們將有權訪問主機上運行的所有容器。發生這種情況是因為運行Docker引擎的用戶是運行容器的用戶。如果任何漏洞利用程序在主機上執行代碼，它將在docker引擎的特權下執行，因此它可以訪問任何容器。

4。數據分離

在Docker容器上，有一些未命名空間的資源：

• SELinux
• Cgroups
• / sys ， / proc / sys ，
• / proc / sysrq-trigger ， / proc / irq ， / proc / bus
• / dev / mem ， / dev / sd * 文件系統
• 內核模塊

如果有任何攻擊者可以利用這些元素中的任何一個，他們將擁有主機操作系統。

VM操作系統將無法直接訪問任何這些元素。它將與管理程序進行對話，管理程序將對主機OS進行適當的系統調用。它將濾除無效呼叫，​​從而增加了一層安全保護。

5。原始套接字

默認的Docker Unix套接字（ /var/run/docker.sock ）可以在沒有適當保護的情況下通過任何容器安裝。如果某些容器安裝了此套接字，則它可以關閉，啟動或創建新映像。

如果已正確配置和保護它，則可以使用Docker容器實現高級別的安全性，但是它將小於正確配置的VM。無論使用多少強化工具，VM始終將更加安全。裸機隔離甚至比VM更安全。某些裸機實現（例如IBM PR / SM）可以保證分區就像在單獨的硬件上一樣分離。據我所知，無法逃避PR / SM虛擬化。

說一個VM或Docker比另一個更安全，這過於簡化了。

VM提供硬件虛擬化；系統管理程序會仿真硬件，以便來賓內核認為它正在自己的計算機上運行。這種類型的虛擬化更容易彼此隔離。如果您對虛擬化的主要關注是隔離（您實際上並不需要虛擬機相互交互），那麼虛擬機的安全性將大大簡化。

Docker提供了內核/操作系統虛擬化，而Docker使用內核名稱空間來虛擬化內核和操作系統，以便來賓認為它正在自己的操作系統實例上運行。操作系統虛擬化為您如何確保容器之間的互連提供了更大的靈活性。如果您對虛擬化的主要關注需要您互連容器，那麼Docker提供了以虛擬機不可能或太繁瑣的方式定義這些共享規則的功能。

靈活性高會帶來很大的風險；錯誤配置docker比VM更容易，並且docker資源共享的靈活性也為實現和配置錯誤提供了更多機會。但是，如果您設法正確配置共享權限，並假設Docker或內核中沒有實現錯誤，那麼Docker提供的共享比硬件虛擬化要細得多，並且可以為您提供總體上更好的安全性。

例如，套接字共享。使用Docker，您可以通過共享套接字文件輕鬆地在兩個容器之間創建一個共享的命名套接字，並且您可以在兩個容器之間定義安全權限（使用任何現有的安全模塊：傳統的Unix權限，功能，SELinux，AppArmor，seccomp等）。套接字端點，以便docker / kernel強制應用程序訪問套接字端點以及哪些方式。使用虛擬機，您可以通過設置套接字鏈來將數據通過TCP傳遞到套接字的方式來使套接字更加繁瑣。但是，虛擬機管理程序的可見性非常有限，並且無法控制對套接字端點的訪問，因為來賓內核會應用對這些套接字端點的權限。

另一個示例是文件夾共享。使用容器，您可以通過設置共享安裝來共享文件夾，並且由於Docker / kernel強制執行容器使用的文件權限，因此來賓系統無法繞過該限制。對於VM，如果要共享文件夾，則必須讓一台計算機運行網絡文件服務器，Samba服務器或FTP服務器，並且管理程序對共享的可見性很小，並且無法強制執行共享權限。此處的其他活動部件（文件服務器）也可能有其自身的漏洞和配置錯誤問題。

TL; DR：DR：使用VM進行隔離，並使用容器進行受控共享。

正如您正確指出的那樣，Docker使用“操作系統級虛擬化”。您可以將其（如果您是* nix迷）認為是 chroot 的一種奇特形式。

通過利用操作系統中內置的功能，Docker充當了導演用於容器。該軟件對操作系統的看法由Docker決定。

所有容器都使用相同的內核。例如，如果我能夠在一個容器中引起內核崩潰（例如“藍屏死機”），所有其他容器都會受到影響。

配置似乎比基於硬件的解決方案更為關鍵。一切都有效地位於同一共享空間中。想像一下，將野生捕食者置於其天然食物來源旁邊。如果您沒有在捕食者周圍放置足夠堅固的外殼，或者每次離開它時都忘記關門，那麼您可能會想像會發生什麼。

雖然肯定是輕巧的解決方案，但我肯定不會在受信任的代碼旁邊運行任何未知的代碼。

惡意代碼必須確定一種方法，以將其特權提升到root / Administrator級別，以便以任何有意義的方式逃避容器。

在虛擬機中，系統管理程序將受到攻擊，而不是內核。由於“容器”之間存在更高的隔離級別，因此可能會更安全，但是會帶來更高的管理開銷。

據我所知，沒有什麼比“裸機”或基於硬件的Docker更安全的了解決方案。我傾向於說Docker不太安全。就每個軟件1個容器而言，這可以證明是不同的故事。

如果您不確定真實的示例，那麼我來看看OpenVZ。它使用與Docker類似的樣式使用操作系統級別的虛擬化，但是內核進行了修改。

Docker容器本來並不是“更安全”的，但是從安全角度來看，在集群中快速啟動和銷毀副本的能力非常有用。

好的，這裡還有很多其他答案人們往往會忘記，有時可以用來保護Web服務器/應用程序安全的最佳工具是能夠在已安裝的代碼遭到破壞後迅速重新部署乾淨的代碼。

世界上沒有100％安全或安全的工具安全。尤其是在公開的Web應用程序的世界中。但是，如果人們真正了解自己的價值並參與其中，那麼Docker會允許採用更好的做法。

• 定期對資產和數據庫進行備份。
• 始終具有可靠的，可移植的配置。
• 在代碼存儲庫中管理代碼。
• 使用部署過程，允許幾次擊鍵重新部署代碼。
• 並使用系統配置工具來確保可以以最少的努力快速重新創建系統/服務器。
• 如果可能的話，將代碼部署在某種負載平衡的集群中，以便一個“事物”在運行代碼遭到破壞，您可以在不完全關閉應用程序的情況下將其殺死。

Docker符合最後一點。 VM也是如此，但是Docker更是如此，因為一旦您決定使用Docker，就必然會使用一種工具，這種工具的心態/心態是：“我不會永遠堅持下去。

在受感染的Docker容器的情況下，您可以將其脫機（就外部世界而言），以進行一些取證，以了解發生了什麼並查看了什麼可以完成將代碼安全地重新部署到Docker容器內其他現有和新代碼庫安裝的操作。

虛擬機可能可以以這種方式使用，但是根據我的實踐和經驗，只有開發人員才真正想到虛擬機的這種方式。大多數係統管理員以及他們所屬的團隊將VM視為一種更輕鬆地從裸機服務器中擠出更多使用和實用性的方法，而不是將它們視為可以一時興起的快速可棄機器。 p>

使用Docker，您實際上必須盡一切努力使Docker容器成為非一次性的整體。 Docker是應用程序開發人員的工具，專為虛擬化變得快速，廉價和容易的時代而打造。而且，當部署在某種負載平衡的群集中時，您可以獲得很少甚至沒有停機的穩定性。

如果我們只是比較空白VM和空白Docker容器，我同意ThoriumBR的回答。但是，應該指出的是，例如在 Red Hat的Atomic Host中正確配置系統可以緩解許多因素，甚至消除一些因素。

此外，自Docker啟動以來，您一方面可以算出他的回答中提到的各種漏洞的數量，而所有這些漏洞都可以通過 SELinux之類的其他層來緩解。我們還開始看到基於虛擬機管理程序的OCI兼容運行時，如果您確實偏執狂並且願意承受性能損失，則可以使用運行時代替runc。

我還要指出，軟件中的大多數漏洞都不在VM具有安全優勢的內核/驅動程序空間中，而是在Docker容器具有優勢的 application 層中，因為它們使創建單進程更容易攻擊面。您可以使用單個靜態鏈接的可執行文件來構建可用的Docker容器，該可執行文件以非root用戶身份運行，並且資源和功能有限。您不能使虛擬機具有如此小的攻擊面。

最重要的是，您必須查看整個安全情況。 Docker容器可能非常安全，但是您必須查看整個軟件供應鏈，並確保正確配置Docker和主機。虛擬機有自己的優點和缺點。您不能只是比較兩個“開箱即用”並做出決定。您需要一個適當的過程來強化任一解決方案。

這個問題太廣泛了，無法用簡單的“是”或“否”來回答。

Docker容器有非常清晰和開放的攻擊面：

• 如果攻擊者是可以啟動容器（即可以訪問Docker API）的人，那麼他無需採取進一步行動即可立即具有對 root 的完全訪問權限。主辦。多年來，這是眾所周知的，並且已經得到證實，並且沒有任何人在爭論（Google或SE會立即為您提供簡單的命令行，甚至不需要特定的容器即可工作）。
• 如果攻擊者設法在容器內獲取 root ，那麼您就遇到了麻煩。實際上，他可以執行任意的內核調用並嘗試影響主機內核。不幸的是，許多Docker映像似乎都是以 root 的身份運行它們的內容，並跳過Dockerfile中的 USER -這不是Docker問題，而是用戶問題。

我看到了一種確實可以使基於Docker映像的系統更安全（可能是...）的情況：

• 如果您認真地減小映像，並且
• 所有這些都以非特權方式運行（即，沒有-privileged 且不以 root 身份運行）。 li>並且網絡盡可能緊密。

然後這將比具有以下參數的VM解決方案更安全：

• 已安裝基礎
• 在同一個VM中安裝了許多功能。
• 網絡連接盡可能緊密。

原因是，例如，一個HTTP服務器被破壞，並且它在一個最小的容器中運行（我在這裡的意思是“最小的”-即， alpine 帶有 nothing ，除了最低限度的最低要求） ，包括沒有出站網絡，沒有rw卷等），則攻擊者能夠執行任何操作的機率要低於運行其他服務的VM。

很明顯，這種情況假設虛擬機 實際上比容器要胖。如果使VM與容器相同，那麼這是有爭議的。但是，然後將這樣設計一個精心設計的Docker場景 。而且通常的VM安裝程序將至少在一段時間內可能會遷移到越來越多的正在安裝的東西上。

已經有了一些不錯的答案，但是要完整說明docker和VM之間的區別，我將添加一張圖片：

源

從這個角度來看，更容易理解為什麼VM比Docker容器更安全。

docker的主要賣點不是要更安全，而是要更容易。這包括：

• 有用的默認值，包括一些安全選項。
• 無需自行配置LXC，cgroup等。
• 現成的圖像只需一行即可下載。
• 可複制的VM。

Docker與其所使用的技術一樣安全，這些技術主要是LXC（Linux名稱空間），selinux和apparmor。

docker的常用用法通常非常不安全。人們正在使用一行來下載某人製作的圖像，他們甚至在運行其操作系統容器之前都從未讀過其名稱。即使您是從自己的基本映像（例如，可以像構建chroot時一樣，通過 debootstrap 生成映像）和Dockerfile來構建的，Dockerfile通常也包含 curl $ URL | bash 反模式以在容器中安裝軟件。

另一件事是，“ docker方法”不是升級映像，但要重建它們。這意味著停止（人們通常會假設您具有使用新映像運行的故障轉移），重建並重新開始。

這來自創建快照的方式，其中通常使用 apt-get從docker的角度來看，dist-upgrade 引入了從語義上講是噪音的層，其中的歷史記錄應類似於“ baseimage”，“添加的apache”，“添加的php”，“已安裝的roundcube”，而無需“每日apt-get”

如果要在LAN中維護自己的映像存儲庫，則docker可能會非常有用，因為您可以快速重新部署更新的映像。

快照功能是另一項可以改善安全性的功能，當您可以快速回滾或派生圖像以在測試環境中嘗試一些新操作，然後將容器重置為安全狀態時。

最重要的是，對於開發人員來說，docker是一個非常有用的工具，他們想要測試可重現的代碼部署並且無需更改已安裝的操作系統，但是有更好的生產解決方案。因此，您可以在生產環境中安全地運行docker，但這不會比沒有docker的良好LXC設置更安全。很快就會受到限制，尤其是當它們也以Windows為目標時。選擇另一個後端具有與LXC，KVM和VirtualBox相同的安全隱患。其他幾點可能保持不變。

首先，我想指出的是，越難重複使用/共享相同資源，就越容易保證其安全性。

表示，Docker嘗試在沙盒上運行每個進程（容器），這就是為什麼可以認為docker更安全的唯一原因。從理論上講，通過服務器運行的多個進程，您將可以訪問自己的進程，並將共享文件夾或套接字公開給其他進程。即使在同一台“機器”上，也無法訪問配置文件，憑據，其他調試和維護端口/套接字的機密信息。工作：將每個正在運行的進程沙箱化。在Virtual Machines和Baremetal中，您可以在一組進程和應用程序中進行沙箱檢查，並在它們之間進行相應的設置權限。