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

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

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

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

安全工作流程

在典型的工作流程中，一旦開發人員完成了某項功能，就會推送到持續集成(CI)系統，該系統將構建和測試鏡像。然后，鏡像被推送到注冊中心(registry)。現在鏡像準備部署到生產環境，這通常需要一種編排系統，比如Docker的內置編排工具、Kubernetes和Mesos等。一些企業可能在推送到生產環境之前改而推送到登臺環境。

圖1：在容器工作流程中，開發人員將變更內容推送到擁有測試組件的持續集成系統。簽名的鏡像將移到注冊中心，它在這里可以部署到生產環境。

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

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

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

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

·隔離和最低權限：使用最少資源和最低權限運行的容器需要高效運行。它們不能對主機或其他容器造成不當的干擾。

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

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

鏡像起源

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

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

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

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

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

安全掃描

Docker鏡像的安全掃描是幾家公司提供的一項新服務。基本想法很簡單：拿來Docker鏡像后，將鏡像包含的軟件與已知安全漏洞列表相互對照，為鏡像出具一份“健康證明”。基于這些信息，企業隨后就可以采取行動，緩解安全漏洞。

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

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

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

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

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

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

審查

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

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

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

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

隔離和最低權限

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

信息安全領域的基本概念之一是最低權限原則，這個原則最初是這樣闡述的：

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

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

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

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

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

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

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

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

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

運行時威脅檢測和響應

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

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

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

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

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

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

訪問控制

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

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

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

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

結論

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

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

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

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

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