【51CTO.com 快譯】任何理性的企業(yè)都希望能在容器上運行關(guān)鍵任務型服務，但他們會有這樣的疑問：“容器真的安全嗎?我們真的可以把數(shù)據(jù)和應用程序放心地交給容器嗎?”

在技術(shù)人員當中，這常常導致容器與虛擬機之爭，并討論虛擬機中的虛擬機管理程序?qū)犹峁┑谋Ｗo。雖然這可能是一種有趣而翔實的討論，但容器與虛擬機這種對立本身就是錯的；有關(guān)方應在虛擬機里面運行容器，目前這一幕出現(xiàn)在大多數(shù)云提供商身上。一個顯著的例外是來自Joyent的Triton，它使用SmartOS Zones，確保租戶相互隔離。還有一個日益壯大的社區(qū)認為，Linux上的容器安全和隔離已得到了長足的改進，用戶可以使用裸機容器服務，而不是使用虛擬機，實現(xiàn)隔離。比如說，IBM在Bluemix公共云服務上構(gòu)建了一種托管的容器服務，該服務運行時租戶之間虛擬機并不隔離。

為了保持容器的靈活性優(yōu)勢，多個容器在每個虛擬機里面運行。關(guān)注安全的企業(yè)可以使用虛擬機，隔離在不同安全級別下運行的容器。比如說，可以安排處理計費信息的容器在不同于留給面向用戶型網(wǎng)站的節(jié)點的節(jié)點上運行。值得關(guān)注的是，包括Hyper、英特爾和VMware在內(nèi)的幾家公司正致力于構(gòu)建速度飛快的基于虛擬機的框架，這些框架實施了Docker API，試圖把容器工作流程的速度與虛擬機管理程序的安全性結(jié)合起來。

一旦我們改用容器并不意味著放棄虛擬機管理程序提供的已確立、得到驗證的安全性，下一步就是調(diào)查，可以通過使用容器和基于容器的工作流程實現(xiàn)安全的增益。

安全工作流程

在典型的工作流程中，一旦開發(fā)人員完成了某項功能，就會推送到持續(xù)集成(CI)系統(tǒng)，該系統(tǒng)將構(gòu)建和測試鏡像。然后，鏡像被推送到注冊中心(registry)?，F(xiàn)在鏡像準備部署到生產(chǎn)環(huán)境，這通常需要一種編排系統(tǒng)，比如Docker的內(nèi)置編排工具、Kubernetes和Mesos等。一些企業(yè)可能在推送到生產(chǎn)環(huán)境之前改而推送到登臺環(huán)境。

圖1：在容器工作流程中，開發(fā)人員將變更內(nèi)容推送到擁有測試組件的持續(xù)集成系統(tǒng)。簽名的鏡像將移到注冊中心，它在這里可以部署到生產(chǎn)環(huán)境。

遵循安全最佳實踐的系統(tǒng)會擁有下列功能和屬性：

·鏡像起源：安全標簽系統(tǒng)落實到位，負責識別生產(chǎn)環(huán)境中運行的容器到底確切地來自哪里。

·安全掃描：鏡像掃描工具自動檢查所有鏡像，查找已知漏洞。

·審查：生產(chǎn)環(huán)境定期接受審查，確保所有容器都基于最新的容器，主機和容器都得到了安全配置。

·隔離和最低權(quán)限：使用最少資源和最低權(quán)限運行的容器需要高效運行。它們不能對主機或其他容器造成不當?shù)母蓴_。

·運行時威脅檢測和響應：這種功能檢測運行時環(huán)境中的容器化應用程有沒有活躍威脅，并自動采取響應措施。

·訪問控制：AppArmor或SELinux等Linux安全模塊用來執(zhí)行訪問控制。

鏡像起源

企業(yè)要認真對待運行的軟件，尤其是生產(chǎn)環(huán)境中的軟件。避免運行過期、易受攻擊的軟件，或避免已受到某種破壞或篡改的軟件，這點至關(guān)重要。由于這個原因，能夠識別和驗證任何容器的來源，包括誰構(gòu)建了容器，它到底在運行哪個版本的代碼，這很重要。

鏡像起源的黃金標準是Docker Content Trust(https://docs.docker.com/engine/security/trust/content_trust/)。啟用Docker Content Trust后，一個數(shù)字簽名被添加到鏡像，然后鏡像被推送到注冊中心。獲取鏡像時，Docker Content Trust會驗證簽名，從而確保鏡像來自相應的企業(yè)，確保鏡像內(nèi)容完全符合被推送的鏡像。這確保攻擊者沒有篡改鏡像，無論在傳送過程中，還是存儲在注冊中心時。Docker Content Trust還通過實施更新框架(TUF)，可以預防其他更先進的攻擊，比如回滾攻擊和凍結(jié)攻擊。

撰寫本文時，Docker Content Trust得到了Docker Hub、Artifactory和Docker Trusted Registry(目前處于實驗階段)的支持?？梢杂肈ocker Content Trust來搭建開源的專用注冊中心，但是這還需要搭建一臺Notary服務器(欲知詳情，請參閱這些說明：https://docs.docker.com/engine/security/trust/content_trust/)。

要是沒有Docker Content Trust，仍可以使用摘要(digest)來驗證鏡像起源，摘要就是鏡像內(nèi)容的密碼散列。鏡像被推送后，Docker客戶機返回表示鏡像摘要的一個字符串(比如sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2)。然后，這個摘要可用于獲取鏡像。只要以這種方式獲取鏡像，Docker就會驗證摘要與鏡像匹配。不像標記，摘要總是會指向同一個鏡像;鏡像的任何更新都會導致新的摘要生成。使用摘要存在的問題是，企業(yè)需要搭建一個專有系統(tǒng)，用于自動提取并分發(fā)摘要。

還需要明確來自第三方的鏡像的起源，無論它們直接使用，還是用作基本鏡像。使用Docker Hub時，所有“官方”鏡像已得到Docker的審核，附有內(nèi)容信任信息，應該被視為是最安全的Hub鏡像。使用其他鏡像應謹慎行事，不過要注意：“自動化構(gòu)建的鏡像”連接到構(gòu)建所使用的源代碼，應該被認為比普通的用戶鏡像更值得信賴。企業(yè)應考慮自行從源代碼構(gòu)建鏡像，而不是從不可信的庫來獲取。由于Docker Store(https://store.docker.com)的出現(xiàn)，這種情況目前在發(fā)生一點變化。Store將為發(fā)布者提供一個可信賴的商店，運作方式如同蘋果的應用程序商店。

安全掃描

Docker鏡像的安全掃描是幾家公司提供的一項新服務?；鞠敕ê芎唵危耗脕鞤ocker鏡像后，將鏡像包含的軟件與已知安全漏洞列表相互對照，為鏡像出具一份“健康證明”?；谶@些信息，企業(yè)隨后就可以采取行動，緩解安全漏洞。

目前的產(chǎn)品包括紅帽的Atomic Scan、IBM的Bluemix Vulnerability Advisor、CoreOS的Clair、 Docker公司的Docker Security Scanning、Aqua Security的Peekr以及Twistlock Trust。無論工作方式、訪問方式還是成本，它們都大不一樣。一個關(guān)鍵的區(qū)別在于掃描工具識別安裝在鏡像中的軟件的方式。

包括Clair在內(nèi)的一些掃描工具會質(zhì)詢軟件包管理器(比如Debian和Ubuntu上的Apt)，以查找已安裝的軟件，但是這對通過打包軟件(tarball)安裝的軟件來說行不通;如果掃描工具無法識別軟件包管理器，也行不通。相比之下，Docker Security Scanning對鏡像執(zhí)行二進制代碼層面的分析;無論是什么軟件包管理器，這種方法都適用，還能識別靜態(tài)鏈接庫的版本。Twistlock也值得關(guān)注，原因在于它可以對通過打包文件安裝的軟件執(zhí)行掃描，漏洞掃描能夠發(fā)現(xiàn)零日攻擊，并且可在嚴加隔離的環(huán)境下工作。

考慮安全掃描如何整合到你的系統(tǒng)中至關(guān)重要。Docker Security Scanning可作為Docker Cloud和Docker Datacenter的一個組成部分，而不是作為一項獨立服務。其他提供商提供應用程序接口(API)，允許整合到現(xiàn)有的CI系統(tǒng)和定制工作流程中。一些掃描工具可安裝在本地環(huán)境，這對要求所有軟件都放在內(nèi)部的企業(yè)來說很重要。

一旦你已整合了安全掃描服務，首先想到的可能是全面禁止存在安全漏洞的任何鏡像在生產(chǎn)環(huán)境中運行。遺憾的是，你很可能會發(fā)現(xiàn)，你的大多數(shù)鏡像存在一些漏洞，全面禁止在現(xiàn)實中不是一個辦法。比如說，Ubuntu向來以迅速更新鏡像而著稱，但是在撰寫本文時，由于使用的Perl版本，16.04基本鏡像隨帶一個重大的安全漏洞(其他大多數(shù)鏡像存在的問題多得多)。因此你可能會發(fā)現(xiàn)，需要逐個調(diào)查發(fā)現(xiàn)的漏洞，確定它們是不是果真對系統(tǒng)構(gòu)成了重大風險。

如果使用去除了不必要軟件的輕量級容器，就可以大大緩解這種情況。要做到這一點，最簡單的方法就是，使用非常小巧的基本鏡像，比如Alpine，大小只有5MB。另一種有點極端的方法就是，構(gòu)建靜態(tài)鏈接二進制代碼，然后把代碼拷貝到“空空如也”的鏡像上。這樣一來，根本不存在操作系統(tǒng)層面的漏洞。這種方法的主要缺點是，構(gòu)建和調(diào)試變得復雜許多，甚至沒有外殼可用。

對業(yè)界的安全人士來說，自動化掃描向前邁出了一大步。它迅速發(fā)現(xiàn)潛在風險，并對廠商施壓、要求及時給易受攻擊的基本鏡像打補丁。通過關(guān)注掃描結(jié)果、迅速反應，企業(yè)才能比許多潛在的攻擊者領(lǐng)先一步。

審查

緊隨安全掃描和鏡像起源的就是審查。我們希望能夠隨時看到哪些鏡像在生產(chǎn)環(huán)境下運行，它們在運行哪個版本的代碼。尤其是，識別哪些容器在運行過期、可能易受攻擊的鏡像很重要。

使用容器時，強烈建議遵循有時所謂的“黃金鏡像”方法：別給運行中的容器打補丁，而是把它們換成運行更新后代碼的新容器――藍綠部署和滾動升級可以用來避免停機。使用這種方法，只要查看構(gòu)建所用的鏡像，就可以審查數(shù)量眾多的運行中的容器。Docker diff之類的工具可用來驗證容器文件系統(tǒng)沒有偏離底層鏡像。

請注意：在部署鏡像之前掃描鏡像還不夠。新的漏洞報告后，之前擁有健康證明的鏡像會變得已知易受攻擊。因此，不斷掃描生產(chǎn)環(huán)境中運行的所有鏡像很重要。是否需要深入的重新掃描，這取決于具體使用的掃描解決方案;掃描工具可以列出鏡像已掃描的軟件，并迅速拿來與新的漏洞作一比較。

審查基于容器的系統(tǒng)下的主機仍然很重要，但是如果運行極簡發(fā)行版，比如CoreOS、Red Hat Atomic或Ubuntu Snappy，可以簡化這一步，這類發(fā)行版被設計成可運行容器，所含的需要審查的軟件比較少。另外，Docker Bench for Security等工具可用于核查配置，Aqua Security和Twistlock都提供了審查主機和配置的解決方案。

隔離和最低權(quán)限

容器的一大安全好處就是添加了隔離方面的工具。容器的工作原理是，構(gòu)建一種在文件系統(tǒng)、網(wǎng)絡和進程方面有著不同世界觀(即獨立命名空間)的系統(tǒng)。另外，控制組(cgroup)用于控制對處理器和內(nèi)存等資源訪問的級別。此外，可以通過Linux功能和seccomp，控制容器做出的Linux內(nèi)核調(diào)用。

信息安全領(lǐng)域的基本概念之一是最低權(quán)限原則，這個原則最初是這樣闡述的：

“系統(tǒng)的每一個程序和每一個特權(quán)用戶都應該使用完成工作所必需的最低權(quán)限來操作。” — Jerome Saltzer

就容器而論，這意味著每個容器應該以有效操作所需的最低權(quán)限來運行。運用這個原則使攻擊者的日子難過得多;即使發(fā)現(xiàn)了某個容器的漏洞，攻擊者也很難有效地利用弱點。如果容器無法訪問易受攻擊的特性，它就不會被壞人利用。

一個有效而簡單的安全措施就是運行擁有只讀文件系統(tǒng)的容器。在Docker中，只要將–read-only標志傳遞給docker run，就能做到這一點。這一步落實到位后，利用漏洞的任何攻擊者會發(fā)現(xiàn)對系統(tǒng)做手腳困難得多;他們無法將惡意腳本寫入到文件系統(tǒng)，也無法篡改文件內(nèi)容。許多應用程序想要寫出到文件，但是針對特定的文件或目錄使用tmpfs(https://docs.docker.com/engine/reference/run/#tmpfs-mount-tmpfs-filesystems)或卷，就可以支持這一點。

限制對其他資源的訪問同樣有效。限制容器可用的內(nèi)存量將防止攻擊者耗用主機上的所有內(nèi)存，導致其他運行中的服務無內(nèi)存可用。限制處理器和網(wǎng)絡帶寬可以防止攻擊者運行耗用大量資源的進程，比如比特幣挖掘或種子文件節(jié)點(Torrent peer)。

在生產(chǎn)環(huán)境中運行容器時最常見的錯誤也許是容器以root用戶的身份來運行。構(gòu)建鏡像時，通常需要root權(quán)限來安裝軟件、配置鏡像。然而，容器啟動時執(zhí)行的主進程不該以root的身份來運行。如果這么做，黑客只要危及進程，就會在容器里面擁有root層面的權(quán)限。最糟糕的是，由于用戶在默認情況下并不使用命名空間，萬一攻擊者設法擺脫容器、進入到主機，他們也許能夠?qū)χ鳈C獲得root層面的全部權(quán)限。

為了防止這種情況，應始終確保Dockerfile聲明非特權(quán)用戶，執(zhí)行主進程之前切換到該用戶。自Docker1.10以來，就有支持啟用用戶命名空間的選項，這會自動將容器中的用戶映射到主機上的高編號用戶。這一招管用，但目前有幾個缺點，包括使用只讀文件系統(tǒng)和卷存在問題。許多這些問題在Linux社區(qū)的上游得到了解決，因此預計在不遠的將來，用戶命名空間支持對更大比例的使用場合而言會變得更切實可行。

限制容器所做的內(nèi)核調(diào)用也能顯著減小攻擊面，一方面限制攻擊者能做的破壞，另一方面減小內(nèi)核代碼面臨漏洞的風險。限制權(quán)限的首要機制是使用Linux功能。Linux定義了約40種功能，它們映射到一組組內(nèi)核調(diào)用。容器運行時環(huán)境(包括rkt和Docker)讓用戶可以選擇容器應以哪些權(quán)限來運行。這些功能映射到約330個系統(tǒng)調(diào)用，這意味著幾種功能(尤其是SYS_ADMIN)映射到大量調(diào)用。想對允許哪些內(nèi)核調(diào)用實行更精細的控制，Docker現(xiàn)在擁有seccomp支持，用于指定到底可以使用哪些調(diào)用，并隨帶一個默認的seccomp策略，它已證明在緩解Linux內(nèi)核的問題方面頗有成效。這兩種方法的主要問題就是，要搞清楚你的應用程序需要做出的一組最少的內(nèi)核調(diào)用。僅僅以不同級別的功能來運行、查找故障很有效但很費時，可能會錯過未測試的部分代碼中的問題。

現(xiàn)有工具可能有助于確定應用程序使用系統(tǒng)調(diào)用的情況，而不是求助于反復試錯。如果你能借助跟蹤功能(比如strace2elastic)完全演練應用程序的代碼路徑，這將報告容器運行過程中在你的應用程序里面使用的系統(tǒng)調(diào)用。

雖然操作系統(tǒng)層面的隔離和實施最低權(quán)限至關(guān)重要，但隔離還需要與應用程序邏輯聯(lián)系起來。如果不了解在主機上運行的應用程序，操作系統(tǒng)層面的隔離可能本身不是很有效。

運行時威脅檢測和響應

不管你在漏洞掃描和容器加固方面的工作做得多好，運行時總會出現(xiàn)未知的代碼錯誤和安全漏洞，會引起入侵或泄密。這就是為什么為系統(tǒng)添置實時威脅檢測和事件響應功能很重要。

相比整體式應用程序，容器化應用程序明顯來得更精簡、不可改變。這就有可能為你的應用程序設定基線，其逼真度比傳統(tǒng)的整體式應用程序來得更高。使用該基線，你應該能夠檢測實時威脅、異常情況和安全隱患，誤報率低于傳統(tǒng)的異常檢測系統(tǒng)。

行為基線是2016年黑帽大會上最熱門的潮流之一，它是指，安全機制專注于了解應用程序或系統(tǒng)的典型行為，從而識別異常情況。行為基線的關(guān)鍵是讓設定基線、持續(xù)監(jiān)控以及檢測和響應盡可能實現(xiàn)自動化。如今，大多數(shù)企業(yè)結(jié)合手動勞力和數(shù)據(jù)科學來獲得行為基線。然而，由于容器具有瞬時性，整個過程自動化顯得尤為重要。

主動式響應與基線相輔相成。主動式反應是指一旦檢測到威脅，如何應對攻擊、泄密或異常情況。響應可能有多種不同的形式，比如提醒相關(guān)人員、與企業(yè)故障單系統(tǒng)進行聯(lián)系，或者對系統(tǒng)和應用程序采取一些預先確定的糾正措施。

在容器環(huán)境下，主動式響應可能意味著執(zhí)行額外的日志，運用額外的隔離規(guī)則，動態(tài)禁用用戶，甚至積極刪除容器。自動化在這里又是關(guān)鍵――執(zhí)行的所有操作不得對應用程序邏輯帶來負面影響，比如讓系統(tǒng)處于不一致的狀態(tài)，或者干擾非冪等操作。

目前提供這種級別的運行時威脅檢測和響應的一些產(chǎn)品包括：Aqua Security、Joyent Triton SmartOS、Twistlock和紅帽O(jiān)penShift。隨著越來越多的關(guān)鍵任務型應用程序遷移到容器，運行時威脅檢測和響應自動化對容器安全而言將越來越重要。想針對容器化環(huán)境擴展運行時安全體系，唯一的辦法就是能夠關(guān)聯(lián)信息、分析攻陷指標、管理取證及響應動作，而且這一切采用自動化方式。

訪問控制

Linux內(nèi)核支持在執(zhí)行內(nèi)核調(diào)用之前執(zhí)行策略的安全模塊。兩種最常見的安全模塊就是AppArmor和SELinux，兩者都實現(xiàn)了所謂的強制訪問控制(MAC)。MAC可核查用戶或進程有權(quán)對某個對象(比如文件、套接字或進程)執(zhí)行各種操作，比如讀取和寫入。訪問策略集中定義，而且無法由用戶改變。與之形成對比的則是文件和權(quán)限的標準Unix模式：擁有足夠權(quán)限的用戶隨時可以更改，這有時又叫自由訪問控制(DAC)。

SELinux最初由美國國家安全局(NSA)開發(fā)，但現(xiàn)在主要由紅帽開發(fā)，用在紅帽的發(fā)行版中。雖然使用SELinux確實另外添加了一道強大的安全層，但用起來有點難度。一旦啟用SELinux，你會注意到的頭一件事就是，卷無法正常工作，需要額外的標志來控制卷的標簽。AppArmor很相似，但不如SELinux來得全面，對于卷缺乏同樣的控制。默認情況下它在Debian和Ubuntu發(fā)行版上已被啟用。

在這兩種情況下，可以制定特殊的策略，以便運行特定的容器，比如運行Apache或NGINX的Web服務器策略，允許某些網(wǎng)絡操作，但是不允許其他各種調(diào)用。理想情況下，所有鏡像都有各自專門制定的策略，但是制定這類策略往往是令人沮喪的過程，bane等第三方工具有一點幫助。在將來，我們預計會看到與容器如影相隨的集成式安全配置文件，為內(nèi)核調(diào)用、SELinux/AppArmor配置文件和資源需求指定設置。

進一步探討訪問控制話題，有必要指出：有權(quán)運行Docker容器的人實際上擁有該主機的root權(quán)限――他們可以掛載和編輯任何文件，或者創(chuàng)建可以拷回到主機的setuid(一旦執(zhí)行就設置用戶ID)二進制代碼。在大多數(shù)情況下，這一點完全要注意，但一些企業(yè)希望對用戶權(quán)限擁有更細粒度的控制。為此，企業(yè)可能應該考慮使用更高級的平臺，比如Docker Datacenter和OpenShift，或者是Aqua Security和Twistlock之類的工具，添加這類控制。

結(jié)論

企業(yè)在實施基于容器的工作流程或在生產(chǎn)環(huán)境中運行容器時，考慮安全至關(guān)重要。安全影響整個工作流程，需要一開始就考慮進來。鏡像起源始于開發(fā)人員在筆記本電腦上構(gòu)建、獲取和推送鏡像，然后通過持續(xù)集成和測試階段，最后終于容器在生產(chǎn)環(huán)境下運行。

容器和黃金鏡像方法帶來了新的工作方式和新的工具，尤其是鏡像掃描和審查方面。企業(yè)更能夠跟蹤了解生產(chǎn)環(huán)境下運行的軟件，而且極容易、極快速地應對安全漏洞。更新后的基本鏡像可以在短短幾分鐘內(nèi)測試、集成和部署。鏡像簽名證實了容器的真實性，確保攻擊者沒有篡改容器的內(nèi)容。

由于經(jīng)過驗證和簽名的鏡像變得很常見，集成式安全配置文件等功能添加以來，未來會出現(xiàn)更重要的功能。在今后幾個月，單單安全優(yōu)點就是企業(yè)向容器遷移的一個充分理由。

原文標題：Assessing the Current State of Container Security   作者：Adrian Mouat

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】