Aaron Grattafiori在美國西雅圖舉辦的DockerCon 2016上發(fā)表了“金色門票：Docker與高安全性的微服務(wù)”的演講。其中主要對運行基于容器的安全微服務(wù)方案建議：啟用用戶命名空間、配置應(yīng)用特定的AppArmor、SELinux及seccomp白名單、加固宿主系統(tǒng)(包括運行一個滿足要求的最小操作系統(tǒng))、限制宿主機的訪問以及考慮加入網(wǎng)絡(luò)安全策略。身為NCC Group的技術(shù)負(fù)責(zé)人以及《理解及加固Linux容器(PDF)》的作者，Grattafiori以全面防御原則的介紹開啟了他的演講，這個原則是由分層的防御措施，并通過減少攻擊面，加固剩余的攻擊面組成。雖然微服務(wù)會增加系統(tǒng)架構(gòu)的總體復(fù)雜度(特別是針對伸縮性方面)，但相對一個典型的整體應(yīng)用，微服務(wù)對避免單點安全故障是有一定優(yōu)勢的。最小權(quán)限原則對于系統(tǒng)安全極為重要，比如避免使用root權(quán)限運行應(yīng)用。一個整體的應(yīng)用往往使用單一的流程來提供大部分的功能，這使得它很難應(yīng)用這個原則。最小意外原則——“合理的默認(rèn)值，基于信任的隔離”——以及最小訪問原則也對全面防御起著至關(guān)重要的作用。Grattafiori指出這些原則的共同點是“最小”，這能防止過度性和復(fù)雜性，并能讓系統(tǒng)構(gòu)筑師：1.建立信任邊界

2.識別、最小化及加固攻擊面

3.降低作用域和訪問權(quán)限

4.分層的保護與防御整體應(yīng)用安全(AppSec)的好處包括其構(gòu)建和維護的易于理解及“已知的已知”。這種架構(gòu)往往相對簡單，并且在開發(fā)、業(yè)務(wù)、合規(guī)等過程中通常有著根深蒂固的現(xiàn)有習(xí)慣(及相關(guān)責(zé)任分工)。整體應(yīng)用安全的劣勢包括向單點的妥協(xié)，往往也意味著對整個應(yīng)用及網(wǎng)絡(luò)的妥協(xié)、全局的認(rèn)證需求以及安全機制往往很難協(xié)調(diào)。微服務(wù)應(yīng)用安全的好處包括：廣為接受的Unix單一職責(zé)原則、普遍減少的公開暴露的攻擊面、服務(wù)可以被單獨打補丁、應(yīng)用(和相關(guān)的運行時容器)更方便地應(yīng)用最小權(quán)限和適應(yīng)服務(wù)特性的安全機制，并且這通常可以更方便地建立可信計算基(TCB)。相應(yīng)地，劣勢包含：微服務(wù)安全是一種“已知的未知”，成功的維護會需要習(xí)慣上的改變(如DevOps和DevOpsSec)、需要對整個系統(tǒng)的功能有一個很好的理解、遺留項目很難適用、復(fù)雜性(伸縮性方面)所帶來的不安全。Grattafiori接下來深入分析了微服務(wù)系統(tǒng)各個區(qū)域的安全影響，首先是在網(wǎng)絡(luò)安全方面。雖然大部分軟件系統(tǒng)在OSI模型7層(應(yīng)用層)提供身份認(rèn)證，這點常被爭論為只能提供有限的優(yōu)勢，最好是通過在4/5層的TLS來實現(xiàn)，如果需要額外的網(wǎng)絡(luò)安全那么可以實現(xiàn)3層的IPSEC。許多組織使用Linux容器如Docker、rkt或LXC來包裝微服務(wù)，這兩者之間在安全方面有明顯的相似之處：

 

減少應(yīng)用和容器的威脅模型攻擊樹很有必要。這包括通過利用防御性代碼和容器安全(如能力(capabilities)、用戶命名空間、只讀根文件目錄(rootfs)、不可變文件、mount標(biāo)記(mount flags)和強制訪問控制(MAC))來限制由應(yīng)用弱點所造成的危害。容器逃逸所造成的傷害可以被用戶命名空間限制，它可以讓容器中的root用戶對應(yīng)到容器外的非root(uid-0)用戶。雖然Docker守護進程支持Docker 1.10用戶命名空間，但是默認(rèn)是沒有開啟的。seccomp、kernel加固和MAC可以限制kernel和syscall的調(diào)用。受限的kernel或主機操作所造成的破壞能進一步被網(wǎng)絡(luò)加固、信任隔離、最低權(quán)限、最小訪問、日志和報警所限制。Grattafiori表示容器安全始于宿主機的操作系統(tǒng)，并極力推薦使用最小的Linux發(fā)行版如CoreOS、alpine Linux、Project Atomic或RancherOS。對操作員來說理解發(fā)行版如何升級、二進制包編譯、默認(rèn)安全配置(如MAC)和默認(rèn)kernel參數(shù)及sysctl配置也是非常重要的。容器鏡像也應(yīng)該保持最小化，典型的如“FROM debian:jessie”或“FROM debian:wheezy”來創(chuàng)建鏡像。然而這可能還不夠小，就算在用apt-get安裝應(yīng)用所需軟件之前，已有許多應(yīng)用用不到的類庫、可執(zhí)行文件和語言文件，這意味著更多的補丁、更多的磁盤空間、更多的攻擊面以及更多的攻擊方法。演講中演示了使用Docker和runC來構(gòu)建最小容器的例子，以及幾個使用scratch容器來運行靜態(tài)編譯的二進制程序(如Golang構(gòu)建的應(yīng)用)。

 

Grattafiori強烈建議使用強制訪問控制(MAC)，從操作系統(tǒng)角度應(yīng)用最小訪問原則。MAC引用一種操作系統(tǒng)限制主體(特別是進程或線程)訪問或操作對象(如文件、TCP/UDP端口、共享內(nèi)存段)的訪問控制。MAC作為一種Linux安全組件(LSM)是由AppArmor和SELinux(還推薦使用grsecurity，它內(nèi)部包含了一套MAC解決方案，是一組強調(diào)安全增強的Linux kernel補丁)實現(xiàn)的。在Mac OSX上MAC通過TrustedBSD實現(xiàn)，微軟平臺有強制完整性控制(MIC)。默認(rèn)的Docker AppArmor策略已經(jīng)非常好了，但是鑒于這個策略是通用的，它一定包含了大量的文件、權(quán)限授權(quán)和復(fù)雜性。微服務(wù)更適合使用自定義安全描述文件的實踐。基于Docker的應(yīng)用的自定義AppArmor的描述文件可以通過aa-genprof或Jessie Frazelle的Bane項目來生成。然而這需要分析目標(biāo)應(yīng)用(因為需要理解和使用這個應(yīng)用)、常見錯誤如提供過多權(quán)限、通配符的使用和基于路徑的訪問控制列表(ACLs)。Grattafiori提醒應(yīng)該避免使用AppArmor的拒絕列表(黑名單)，因為它們只能提供有限的值。其他的易混淆的地方包括描述文件必須先被AppArmor加載，在描述文件中太過大量地運用抽象，這導(dǎo)致很難在生產(chǎn)環(huán)境中充分驗證所有的功能是有效的(雖然單元測試和回歸測試會有幫助)。雖然MAC很有價值，但是它還是無法避免kernel攻擊，不巧kernel攻擊的攻擊面是巨大的。“安全計算模式(seccomp)”是一個計算機安全設(shè)備，它在Linux kernel提供應(yīng)用的沙箱機制(雖然seccomp本質(zhì)上不是沙箱)。seccomp允許進程單向轉(zhuǎn)變進入“安全”態(tài)，在其中只能對已經(jīng)打開的文件描述符使用exit、sigreturn、read、write這些系統(tǒng)調(diào)用。如果它嘗試其他的系統(tǒng)調(diào)用，kernel會使用SIGKILL終止進程。seccomp-bpf是seccomp的一個擴展，它使用伯克利封包過濾器允許使用一個配置的策略來過濾系統(tǒng)調(diào)用。

 

Docker引擎1.10后seccomp默認(rèn)過濾器默認(rèn)啟用，但是由于通用需求，內(nèi)部啟用了304個系統(tǒng)調(diào)用(占所有系統(tǒng)調(diào)用大約75%)。最小權(quán)限原則建議微服務(wù)應(yīng)用只應(yīng)該擁有最小的系統(tǒng)調(diào)用集，相應(yīng)地可以創(chuàng)建自定義描述文件。創(chuàng)建seccomp描述文件的方法包括strace/ltrace、kernel幫助(sysdig或systemtap)、auditd/auditctl或seccomp自己通過SECCOMP_RET_TRACE和PTRACE_O_TRACESECCOMP。在Docker中可以通過使用“--security-opt seccomp=”標(biāo)記來指定自定義的seccomp描述文件。Grattafiori強調(diào)seccomp配置文件是對架構(gòu)依賴的，所以會限制移植性。Grattafiori開始總結(jié)演講時，陳述了運行安全的基于Docker的微服務(wù)的高層次建議：啟用用戶命名空間

盡可能地使用應(yīng)用特定的AppArmor或SELinux

盡可能地使用應(yīng)用特定的seccomp白名單

加固宿主機系統(tǒng)

限制宿主機訪問權(quán)限

考慮使用網(wǎng)絡(luò)安全策略

使用不可變的容器

管理構(gòu)建和運行時秘鑰(secrets)的問題可以通過臨時綁定mount來進行臨時秘鑰注入，再加載秘鑰到內(nèi)存，然后unmount;或者理想地使用開源秘鑰管理工具如HashiCorp Vault或Square Keywhiz。秘鑰不應(yīng)該通過環(huán)境變量或普通文件注入，因為這很容易導(dǎo)致秘鑰泄露到容器層、日志或錯誤報告中。最后的安全建議包括創(chuàng)建一個安全規(guī)格書、生成應(yīng)用特定和全局的威脅模型、確保任何應(yīng)用/服務(wù)的安全性、確保協(xié)調(diào)框架和相關(guān)服務(wù)發(fā)現(xiàn)的安全性。如果應(yīng)用自身是脆弱的，那么容器和微服務(wù)也無能為力微服務(wù)的日志和可計量也很重要，日志應(yīng)該被統(tǒng)一收集保存，并定期復(fù)審。如果把安全融入到軟件的開發(fā)周期，同時使用OWASP的ZAP、bdd-security、Brakeman或gauntlt等工具將核實的過程作為標(biāo)準(zhǔn)構(gòu)建鏈的一環(huán)，這樣就更容易達成安全性目標(biāo)了。Grattafiori在DockerCon的視頻“金色門票：Docker與高安全性的微服務(wù)”可以在YouTube的會議頻道找到，幻燈片可以在Docker的SlideShare賬號找到。Grattafiori也是NCC Group白皮書《理解及加固Linux容器(PDF)》的作者，這本書對每個正要詳細(xì)理解容器安全的人是必不可少的。查看英文原文：Docker and High Security Microservices: A Summary of Aaron Grattafiori's DockerCon 2016 Talk