Aaron Grattafiori在美國西雅圖舉辦的 DockerCon 2016上發表了“ 金色門票：Docker與高安全性的微服務”的演講。其中主要對執行基於容器的安全微服務方案建議：啟用使用者名稱空間、配置應用特定的AppArmor、SELinux及seccomp白名單、加固宿主系統（包括執行一個滿足要求的最小作業系統）、限制宿主機的訪問以及考慮加入網路安全策略。

身為NCC Group的技術負責人以及《 理解及加固Linux容器（PDF）》的作者，Grattafiori以

最小許可權原則對於系統安全極為重要，比如避免使用root許可權執行應用。一個整體的應用往往使用單一的流程來提供大部分的功能，這使得它很難應用這個原則。 最小意外原則——“合理的預設值，基於信任的隔離”——以及 最小訪問原則也對全面防禦起著至關重要的作用。Grattafiori指出這些原則的共同點是“最小”，這能防止過度性和複雜性，並能讓系統構築師：

1.建立信任邊界
2.識別、最小化及加固攻擊面
3.降低作用域和訪問許可權
4.分層的保護與防禦

整體應用安全（AppSec）的好處包括其構建和維護的易於理解及“已知的已知”。這種架構往往相對簡單，並且在開發、業務、合規等過程中通常有著根深蒂固的現有習慣（及相關責任分工）。整體應用安全的劣勢包括向單點的妥協，往往也意味著對整個應用及網路的妥協、全域性的認證需求以及安全機制往往很難協調。

微服務應用安全的好處包括：廣為接受的Unix 單一職責原則

Grattafiori接下來深入分析了微服務系統各個區域的安全影響，首先是在網路安全方面。雖然大部分軟體系統在 OSI模型7層（應用層）提供身份認證，這點常被爭論為只能提供有限的優勢，最好是通過在4/5層的 TLS來實現，如果需要額外的網路安全那麼可以實現3層的 IPSEC。

許多組織使用Linux容器如 Docker、 rkt或 LXC來包裝微服務，這兩者之間在安全方面有明顯的相似之處：

減少應用和容器的 威脅模型攻擊樹很有必要。這包括通過利用防禦性程式碼和容器安全（如 能力（capabilities）、 使用者名稱空間、只讀根檔案目錄（rootfs）、不可變檔案、mount標記（mount flags）和 強制訪問控制（MAC））來限制由應用弱點所造成的危害。

容器逃逸所造成的傷害可以被使用者名稱空間限制，它可以讓容器中的root使用者對應到容器外的非root（uid-0）使用者。雖然Docker守護程序支援 Docker 1.10使用者名稱空間，但是預設是沒有開啟的。 seccomp、kernel加固和MAC可以限制kernel和 syscall的呼叫。受限的kernel或主機操作所造成的破壞能進一步被網路加固、信任隔離、最低許可權、最小訪問、日誌和報警所限制。

Grattafiori表示容器安全始於宿主機的作業系統，並極力推薦使用最小的Linux發行版如 CoreOS、 alpine Linux、 Project Atomic或 RancherOS。對操作員來說理解發行版如何升級、二進位制包編譯、預設安全配置（如MAC）和預設kernel引數及sysctl配置也是非常重要的。

容器映象也應該保持最小化，典型的如“FROM debian:jessie”或“FROM debian:wheezy”來建立映象。然而這可能還不夠小，就算在用apt-get安裝應用所需軟體之前，已有許多應用用不到的類庫、可執行檔案和語言檔案，這意味著更多的補丁、更多的磁碟空間、更多的攻擊面以及更多的攻擊方法。

演講中演示了使用Docker和 runC來構建最小容器的例子，以及幾個使用scratch容器來執行靜態編譯的二進位制程式（如Golang構建的應用）。

Grattafiori強烈建議使用 強制訪問控制（MAC），從作業系統角度應用最小訪問原則。MAC引用一種作業系統限制主體（特別是程序或執行緒）訪問或操作物件（如檔案、TCP/UDP埠、共享記憶體段）的訪問控制。MAC作為一種Linux安全元件（LSM）是由 AppArmor和 SELinux（還推薦使用 grsecurity，它內部包含了一套MAC解決方案，是一組強調安全增強的Linux kernel補丁）實現的。在Mac OSX上MAC通過 TrustedBSD實現，微軟平臺有 強制完整性控制（MIC）。

預設的Docker AppArmor策略已經非常好了，但是鑑於這個策略是通用的，它一定包含了大量的檔案、許可權授權和複雜性。微服務更適合使用自定義安全描述檔案的實踐。基於Docker的應用的自定義AppArmor的描述檔案可以通過 aa-genprof或 Jessie Frazelle的Bane專案來生成。然而這需要分析目標應用（因為需要理解和使用這個應用）、常見錯誤如提供過多許可權、萬用字元的使用和基於路徑的訪問控制列表（ACLs）。

Grattafiori提醒應該避免使用AppArmor的拒絕列表（黑名單），因為它們只能提供有限的值。其他的易混淆的地方包括描述檔案必須先被AppArmor載入，在描述檔案中太過大量地運用抽象，這導致很難在生產環境中充分驗證所有的功能是有效的（雖然單元測試和迴歸測試會有幫助）。

雖然MAC很有價值，但是它還是無法避免 kernel攻擊，不巧kernel攻擊的攻擊面是巨大的。“ 安全計算模式（seccomp）”是一個電腦保安裝置，它在Linux kernel提供應用的沙箱機制（雖然seccomp本質上 不是沙箱）。seccomp允許程序單向轉變進入“安全”態，在其中只能對已經開啟的檔案描述符使用exit、sigreturn、read、write這些系統呼叫。如果它嘗試其他的系統呼叫，kernel會使用 SIGKILL終止程序。 seccomp-bpf是seccomp的一個擴充套件，它使用 伯克利封包過濾器允許使用一個配置的策略來過濾系統呼叫。

Docker引擎1.10後seccomp預設過濾器預設啟用，但是由於通用需求，內部啟用了304個系統呼叫（佔所有系統呼叫大約75%）。最小許可權原則建議微服務應用只應該擁有最小的系統呼叫集，相應地可以建立自定義描述檔案。建立seccomp描述檔案的方法包括 strace/ltrace、kernel幫助（ sysdig或 systemtap）、 auditd/auditctl或seccomp自己通過SECCOMP_RET_TRACE和PTRACE_O_TRACESECCOMP。在Docker中可以通過使用“--security-opt seccomp=<profile>”標記來指定自定義的seccomp描述檔案。Grattafiori強調seccomp配置檔案是對架構依賴的，所以會限制移植性。

Grattafiori開始總結演講時，陳述了執行安全的基於Docker的微服務的高層次建議：

• 啟用使用者名稱空間
• 儘可能地使用應用特定的AppArmor或SELinux
• 儘可能地使用應用特定的seccomp白名單
• 加固宿主機系統
• 限制宿主機訪問許可權
• 考慮使用網路安全策略
• 使用不可變的容器

管理構建和執行時祕鑰（secrets）的問題可以通過臨時繫結mount來進行臨時祕鑰注入，再載入祕鑰到記憶體，然後unmount；或者理想地使用開源祕鑰管理工具如 HashiCorp Vault或 Square Keywhiz。祕鑰不應該通過環境變數或普通檔案注入，因為這很容易導致祕鑰洩露到容器層、日誌或錯誤報告中。

最後的安全建議包括建立一個安全規格書、生成應用特定和全域性的威脅模型、確保任何應用/服務的安全性、確保協調框架和相關服務發現的安全性。

如果應用自身是脆弱的，那麼容器和微服務也無能為力

微服務的日誌和可計量也很重要，日誌應該被統一收集儲存，並定期複審。如果把安全融入到軟體的開發週期，同時使用 OWASP的ZAP、 bdd-security、 Brakeman或 gauntlt等工具將核實的過程作為標準構建鏈的一環，這樣就更容易達成安全性目標了。

Grattafiori在DockerCon的視訊“ 金色門票：Docker與高安全性的微服務”可以在YouTube的會議頻道找到，幻燈片可以在 Docker的SlideShare賬號找到。Grattafiori也是NCC Group白皮書《 理解及加固Linux容器（PDF）》的作者，這本書對每個正要詳細理解容器安全的人是必不可少的。