是。docker是是一個(gè)開源的應(yīng)用容器引擎，讓開發(fā)者可以打包他們的應(yīng)用以及依賴包到一個(gè)可移植的鏡像中，配置nfs權(quán)限是只讀，nfs服務(wù)器安全戰(zhàn)略:把敞開目錄約束為只讀權(quán)限能夠在/etc/exports文褲和件中設(shè)定權(quán)限選項(xiàng)ro，一般需要把戚純帶NFS服務(wù)器對(duì)客高蘆戶敞開的任何目錄或文件體系設(shè)置為只讀拜。
做網(wǎng)站、網(wǎng)站建設(shè)介紹好的網(wǎng)站是理念、設(shè)計(jì)和技術(shù)的結(jié)合。創(chuàng)新互聯(lián)公司擁有的網(wǎng)站設(shè)計(jì)理念、多方位的設(shè)計(jì)風(fēng)格、經(jīng)驗(yàn)豐富的設(shè)計(jì)團(tuán)隊(duì)。提供PC端+手機(jī)端網(wǎng)站建設(shè)，用營銷思維進(jìn)行網(wǎng)站設(shè)計(jì)、采用先進(jìn)技術(shù)開源代碼、注重用戶體驗(yàn)與SEO基礎(chǔ)，將技術(shù)與創(chuàng)意整合到網(wǎng)站之中，以契合客戶的方式做到創(chuàng)意性的視覺化效果。
以Docker 容器的安全問題為例
(1) Docker 自身安全
Docker 作為一款容器李鋒引擎，本身也會(huì)存在一些安全漏洞，CVE 目前已經(jīng)記錄了多項(xiàng)與 Docker 相關(guān)的安全漏洞，主要有權(quán)限提升、信息泄露等幾類安全問題。
(2) 鏡像安全
由于Docker 容器是基于鏡像創(chuàng)建并啟動(dòng)，因此鏡像的安全直接影響到容器的安全。具體影響鏡像安全的總結(jié)如下。
鏡像軟件存在安全漏洞：由于容器需要安裝基礎(chǔ)的軟件包，如果軟件包存在漏洞，則可能會(huì)被不法分子利用并且侵入容器，影響其他容器或主機(jī)安全。
倉庫漏洞：無論是Docker 官方的鏡像倉庫還是我們私有的鏡像倉庫，都有可能被攻擊，然后篡改鏡像，當(dāng)我們使用鏡像時(shí)，就可能成為攻擊者的目標(biāo)對(duì)象。
用戶程序漏洞：用戶自己構(gòu)建的軟件包可能存在漏洞或者被植入惡意腳本，這樣會(huì)導(dǎo)致運(yùn)行時(shí)提權(quán)影響其他容器或主機(jī)安全。
(3) Linux 內(nèi)核隔離性不夠
盡管目前Namespace 已經(jīng)提供了非常多的資源隔離類型，但是仍有部分關(guān)鍵內(nèi)容沒有被完全隔離，其中包括一些系統(tǒng)的關(guān)鍵性目錄（如 /sys、/proc 等），這些關(guān)鍵性的目錄可能會(huì)泄露主機(jī)上一些關(guān)鍵性的信息，讓攻擊者利用這些信息對(duì)整個(gè)主機(jī)甚至云計(jì)算中心發(fā)起攻擊。
而且僅僅依靠Namespace 的隔離是遠(yuǎn)遠(yuǎn)不夠的，因?yàn)橐坏﹥?nèi)核的 Namespace 被突破，使用者就有可能直接提權(quán)獲取到主機(jī)的超級(jí)權(quán)限，從而影響主機(jī)安全。
(4) 所有容器共享主機(jī)內(nèi)核
由于同一宿主機(jī)上所有容器共享主機(jī)內(nèi)核，所以攻擊者可以利用一些特殊手段導(dǎo)致內(nèi)核崩潰，進(jìn)而導(dǎo)致主機(jī)宕機(jī)影響主機(jī)上其他服務(wù)。
既然容器有這么多安全上的問題，那么我們應(yīng)該如何做才能夠既享受到容器的便利性同時(shí)也可以保障容器安全呢？下面我?guī)銇碇鸩搅私庀氯绾谓鉀Q容器的安全問題。
如何解決容器的安全問題？
(1) Docker 自身安全性改進(jìn)
事實(shí)上，Docker 從 2013 年誕生到現(xiàn)在，在安全性上面已經(jīng)做了非常多的努力。目前 Docker 在默認(rèn)配置和默認(rèn)行為下是足夠安全的。
Docker 自身是基于 Linux 的多種 Namespace 實(shí)現(xiàn)的，其中有一個(gè)很重要的 Namespace 叫作 User Namespace，User Namespace 主要是用來做容器內(nèi)用戶和主機(jī)的用戶隔離的。在過去容器里的 root 用戶就是主機(jī)上的 root 用戶，如果容器受到攻擊，或者容器本身含有惡意程序，在容器內(nèi)就可以直接獲取到主機(jī) root 權(quán)限。Docker 從 1.10 版本開始，使用 User Namespace 做用戶隔離，實(shí)現(xiàn)了容器中的 root 用戶映射到主機(jī)上的非 root 用戶，從而大大減輕了容器被突破的風(fēng)險(xiǎn)。
因此，我們盡可能地使用Docker 最新版本就可以得到更好的安全保障。
(2) 保障鏡像安全
為保障鏡像安全，我們可以在私有鏡像倉庫安裝鏡像安全掃描組件，對(duì)上傳的鏡像進(jìn)行檢查，通過與CVE 數(shù)據(jù)庫跡拍對(duì)比，一旦發(fā)現(xiàn)有漏洞的鏡像及時(shí)通知用戶或阻止非安全鏡像繼續(xù)構(gòu)建和分發(fā)。同時(shí)為了確保我姿擾羨們使用的鏡像足夠安全，在拉取鏡像時(shí)，要確保只從受信任的鏡像倉庫拉取，并且與鏡像倉庫通信一定要使用 HTTPS 協(xié)議。
(3) 加強(qiáng)內(nèi)核安全和管理
由于僅僅依賴內(nèi)核的隔離可能會(huì)引發(fā)安全問題，因此我們對(duì)于內(nèi)核的安全應(yīng)該更加重視。可以從以下幾個(gè)方面進(jìn)行加強(qiáng)。
宿主機(jī)及時(shí)升級(jí)內(nèi)核漏洞
宿主機(jī)內(nèi)核應(yīng)該盡量安裝最新補(bǔ)丁，因?yàn)楦碌膬?nèi)核補(bǔ)丁往往有著更好的安全性和穩(wěn)定性。
使用Capabilities 劃分權(quán)限
Capabilities 是 Linux 內(nèi)核的概念，Linux 將系統(tǒng)權(quán)限分為了多個(gè) Capabilities，它們都可以單獨(dú)地開啟或關(guān)閉，Capabilities 實(shí)現(xiàn)了系統(tǒng)更細(xì)粒度的訪問控制。
容器和虛擬機(jī)在權(quán)限控制上還是有一些區(qū)別的，在虛擬機(jī)內(nèi)我們可以賦予用戶所有的權(quán)限，例如設(shè)置cron 定時(shí)任務(wù)、操作內(nèi)核模塊、配置網(wǎng)絡(luò)等權(quán)限。而容器則需要針對(duì)每一項(xiàng) Capabilities 更細(xì)粒度的去控制權(quán)限，例如：
cron 定時(shí)任務(wù)可以在容器內(nèi)運(yùn)行，設(shè)置定時(shí)任務(wù)的權(quán)限也僅限于容器內(nèi)部；
由于容器是共享主機(jī)內(nèi)核的，因此在容器內(nèi)部一般不允許直接操作主機(jī)內(nèi)核；
容器的網(wǎng)絡(luò)管理在容器外部，這就意味著一般情況下，我們?cè)谌萜鲀?nèi)部是不需要執(zhí)行ifconfig、route等命令的 。
由于容器可以按照需求逐項(xiàng)添加Capabilities 權(quán)限，因此在大多數(shù)情況下，容器并不需要主機(jī)的 root 權(quán)限，Docker 默認(rèn)情況下也是不開啟額外特權(quán)的。
最后，在執(zhí)行docker run命令啟動(dòng)容器時(shí)，如非特殊可控情況，–privileged 參數(shù)不允許設(shè)置為 true，其他特殊權(quán)限可以使用 --cap-add 參數(shù)，根據(jù)使用場(chǎng)景適當(dāng)添加相應(yīng)的權(quán)限。
使用安全加固組件
Linux 的 SELinux、AppArmor、GRSecurity 組件都是 Docker 官方推薦的安全加固組件。下面我對(duì)這三個(gè)組件做簡單介紹。
SELinux (Secure Enhanced Linux): 是 Linux 的一個(gè)內(nèi)核安全模塊，提供了安全訪問的策略機(jī)制，通過設(shè)置 SELinux 策略可以實(shí)現(xiàn)某些進(jìn)程允許訪問某些文件。
AppArmor: 類似于 SELinux，也是一個(gè) Linux 的內(nèi)核安全模塊，普通的訪問控制僅能控制到用戶的訪問權(quán)限，而 AppArmor 可以控制到用戶程序的訪問權(quán)限。
GRSecurity: 是一個(gè)對(duì)內(nèi)核的安全擴(kuò)展，可通過智能訪問控制，提供內(nèi)存破壞防御，文件系統(tǒng)增強(qiáng)等多種防御形式。
這三個(gè)組件可以限制一個(gè)容器對(duì)主機(jī)的內(nèi)核或其他資源的訪問控制。目前，容器報(bào)告的一些安全漏洞中，很多都是通過對(duì)內(nèi)核進(jìn)行加強(qiáng)訪問和隔離來實(shí)現(xiàn)的。
資源限制
在生產(chǎn)環(huán)境中，建議每個(gè)容器都添加相應(yīng)的資源限制。下面給出一些執(zhí)行docker run命令啟動(dòng)容器時(shí)可以傳遞的資源限制參數(shù)：
1??--cpus ?????????????????????????限制 CPU 配額
2??-m, --memory ???????????????????限制內(nèi)存配額
3??--pids-limit ???????????????????限制容器的 PID 個(gè)數(shù)
例如我想要啟動(dòng)一個(gè)1 核 2G 的容器，并且限制在容器內(nèi)最多只能創(chuàng)建 1000 個(gè) PID，啟動(dòng)命令如下：
1 ?$ docker run -it --cpus=1 -m=2048m --pids-limit=1000 busybox sh
推薦在生產(chǎn)環(huán)境中限制CPU、內(nèi)存、PID 等資源，這樣即便應(yīng)用程序有漏洞，也不會(huì)導(dǎo)致主機(jī)的資源完全耗盡，最大限度降低安全風(fēng)險(xiǎn)。
(4) 使用安全容器
容器有著輕便快速啟動(dòng)的優(yōu)點(diǎn)，虛擬機(jī)有著安全隔離的優(yōu)點(diǎn)，有沒有一種技術(shù)可以兼顧兩者的優(yōu)點(diǎn)，做到既輕量又安全呢？
答案是有，那就是安全容器。安全容器是相較于普通容器的，安全容器與普通容器的主要區(qū)別在于，安全容器中的每個(gè)容器都運(yùn)行在一個(gè)單獨(dú)的微型虛擬機(jī)中，擁有獨(dú)立的操作系統(tǒng)和內(nèi)核，并且有虛擬化層的安全隔離。
安全容器目前推薦的技術(shù)方案是Kata Containers，Kata Container 并不包含一個(gè)完整的操作系統(tǒng)，只有一個(gè)精簡版的 Guest Kernel 運(yùn)行著容器本身的應(yīng)用，并且通過減少不必要的內(nèi)存，盡量共享可以共享的內(nèi)存來進(jìn)一步減少內(nèi)存的開銷。另外，Kata Container 實(shí)現(xiàn)了 OCI 規(guī)范，可以直接使用 Docker 的鏡像啟動(dòng) Kata 容器，具有開銷更小、秒級(jí)啟動(dòng)、安全隔離等許多優(yōu)點(diǎn)。
Docker是Docker.Inc公司開源的一個(gè)基于輕量級(jí)虛擬化技術(shù)的容器引擎項(xiàng)目,整個(gè)項(xiàng)目基于Go語言開發(fā)，并遵從Apache 2.0協(xié)議。通過賀悄磨分層鏡像標(biāo)準(zhǔn)化和內(nèi)核虛擬化技術(shù)，Docker使得應(yīng)用開發(fā)者和運(yùn)維工程師可以以統(tǒng)一的方式跨平臺(tái)發(fā)布應(yīng)用，并且以幾乎沒有額外開銷的情況下提供資源隔離的應(yīng)用運(yùn)行環(huán)境。由于眾多新穎的特性以及項(xiàng)目本身的開放性，Docker在不到兩禪斗年的時(shí)間里迅速獲得諸多IT廠商的參與，其中更是包括Google、Microsoft、VMware等業(yè)界行業(yè)領(lǐng)導(dǎo)者。同時(shí)，Docker在開發(fā)者社區(qū)也是一石激起千層浪，許多如我之碼農(nóng)紛紛開始關(guān)注、學(xué)習(xí)和使用Docker，許多企業(yè)，尤其是互聯(lián)網(wǎng)企業(yè)，也在不斷加大對(duì)Docker的投入，大有掀起一場(chǎng)容器革命之勢(shì)。
Docker鏡像命名解析
鏡像是Docker最核心的技術(shù)之一，也是應(yīng)用發(fā)布的標(biāo)準(zhǔn)格式。無論你是用docker pull image，或者是在Dockerfile里面寫FROM image，從Docker官方Registry下載鏡像應(yīng)該是Docker操作里面最頻繁的動(dòng)作之一了。那么在我們執(zhí)行docker pull image時(shí)背后到底發(fā)生了什么呢？在回答這個(gè)問題前，我們需要先了解下docker鏡像是如何命名的，這也是Docker里面比較容易令人混淆的一塊概念：Registry，Repository, Tag and Image。
下面是在本地機(jī)器運(yùn)行docker images的輸出結(jié)果：
我們可以發(fā)現(xiàn)我們常說的“ubuntu”鏡像其實(shí)不是一個(gè)鏡像名稱，而是代表了一個(gè)名為ubuntu的Repository，同時(shí)在這個(gè)Repository下面有一系列打了tag的Image，Image的標(biāo)記是一個(gè)GUID，為了方便也可以通過Repository:tag來引用。
那么Registry又是什么呢？Registry存儲(chǔ)鏡像數(shù)據(jù)，并且提供拉取和上傳鏡像的功能。Registry中鏡像是通過Repository來組織的，而每個(gè)Repository又包含了若干個(gè)Image。
Registry包含一個(gè)或多個(gè)Repository
Repository包含一個(gè)或多個(gè)Image
Image用GUID表示，有一個(gè)或多個(gè)Tag與之關(guān)聯(lián)
那么在哪里指定Registry呢？讓我們?cè)倮∫粋€(gè)更完整命名的鏡像吧：
上面我試圖去拉取一個(gè)ubuntu鏡像，并且指定了Registry為我本機(jī)搭建的私有Registry。下面是Docker CLI中pull命令的代碼片段 (docker/api/client/command.go中的CmdPull函數(shù))
在運(yùn)行時(shí)，上面的taglessRemote變量會(huì)被傳入localhost:5000/ubuntu。上面代碼試圖從taglessRemote變量中解析出Registry的地址，在我們的例子中，它是localhost:5000。
那我們回過頭再來看看下面這個(gè)耳熟能詳?shù)膒ull命令背后的故事吧：運(yùn)嫌
我們跟著上面的示例代碼，進(jìn)一步進(jìn)入解析函數(shù)ResolveRepositoryName的定義代碼片段(docker/registry/registry.go)
我們發(fā)現(xiàn)，Docker CLI會(huì)判斷傳入的taglessRemote參數(shù)的第一部分中是否包含’.’或者':’，如果存在則認(rèn)為第一部分是Registry地址，否則會(huì)使用Docker官方默認(rèn)的Registry（即index.docker.io其實(shí)這里是一個(gè)Index Server，和Registry的區(qū)別留在后面再去深究吧），即上面代碼中高亮的部分。背后的故事還沒有結(jié)束，如果你向DockerHub上傳過鏡像，應(yīng)該記得你上傳的鏡像名稱格式為user-name/repository:tag，這樣用戶Bob和用戶Alice可以有相同名稱的Repository，通過用戶名前綴作為命名空間隔離，比如Bob/ubuntu和Alice/ubuntu。官方鏡像是通過用戶名library來區(qū)分的，具體代碼片段如下(docker/api/client/command.go中的CmdPull函數(shù))
我們回過頭再去看Docker命令行中解析Tag的邏輯吧(docker/api/client/command.go中的CmdPull函數(shù))：
代碼會(huì)試著在用戶輸入的Image名稱中找’ : ‘后面的tag,如果不存在，會(huì)使用默認(rèn)的‘DEFAULTTAG’，即‘latest’。
也就是說在我們的例子里面，命令會(huì)被解析為下面這樣（注意，下面的命令不能直接運(yùn)行，因?yàn)镈ocker CLI不允許明確指定官方Registry地址）
配置Registry Mirror
Docker之所以這么吸引人，除了它的新穎的技術(shù)外，圍繞官方Registry（Docker Hub）的生態(tài)圈也是相當(dāng)吸引人眼球的地方。在Docker Hub上你可以很輕松下載到大量已經(jīng)容器化好的應(yīng)用鏡像，即拉即用。這些鏡像中，有些是Docker官方維護(hù)的，更多的是眾多開發(fā)者自發(fā)上傳分享的。而且你還可以在Docker Hub中綁定你的代碼托管系統(tǒng)（目前支持Github和Bitbucket）配置自動(dòng)生成鏡像功能，這樣Docker Hub會(huì)在你代碼更新時(shí)自動(dòng)生成對(duì)應(yīng)的Docker鏡像，是不是很方便？
不幸的是Docker Hub并沒有在國內(nèi)放服務(wù)器或者用國內(nèi)的CDN，下載個(gè)鏡像20分鐘最起碼，我等碼農(nóng)可耗不起這么長時(shí)間，老板正站在身后催著我們搬運(yùn)代碼呢。為了克服跨洋網(wǎng)絡(luò)延遲，一般有兩個(gè)解決方案：一是使用私有Registry，另外是使用Registry Mirror，我們下面一一展開聊聊.
方案一就是搭建或者使用現(xiàn)有的私有Registry，通過定期和Docker Hub同步熱門的鏡像，私有Registry上保存了一些鏡像的副本，然后大家可以通過docker pull private-registry點(diǎn)抗 /user-name/ubuntu:latest，從這個(gè)私有Registry上拉取鏡像。因?yàn)檫@個(gè)方案需要定期同步Docker Hub鏡像，因此它比較適合于使用的鏡像相對(duì)穩(wěn)定，或者都是私有鏡像的場(chǎng)景。而且用戶需要顯式的映射官方鏡像名稱到私有鏡像名稱，私有Registry更多被大家應(yīng)用在企業(yè)內(nèi)部場(chǎng)景。私有Registry部署也很方便，可以直接在Docker Hub上下載Registry鏡像，即拉即用，具體部署可以參考官方文檔。
方案二是使用Registry Mirror，它的原理類似于緩存，如果鏡像在Mirror中命中則直接返回給客戶端，否則從存放鏡像的Registry上拉取并自動(dòng)緩存在Mirror中。最酷的是，是否使用Mirror對(duì)Docker使用者來講是透明的，也就是說在配置Mirror以后，大家可以仍然輸入docker pull ubuntu來拉取Docker Hub鏡像，除了速度變快了，和以前沒有任何區(qū)別。
了以更便捷的方式對(duì)接Docker Hub生態(tài)圈，使用Registry Mirror自然成為我的首選。接下來我就和大家一起看看Docker使用Mirror來拉取鏡像的過程。下面的例子，我使用的是由DaoCloud提供的Registry Mirror服務(wù)，在申請(qǐng)開通Mirror服務(wù)后你會(huì)得到一個(gè)Mirror地址，然后我們要做的就是把這個(gè)地址配置在Docker Server啟動(dòng)腳本中，重啟Docker服務(wù)后Mirror配置就生效了（如何獲得Mirror服務(wù)可以參考本篇文章的附錄）
Ubuntu下配置Docker Registry Mirror的命令如下：
sudo echo “DOCKER_OPTS=\”\$DOCKER_OPTS –registry-mirror= -d\”” /etc/default/docker
sudo service docker restart
如果你是用的Boot2Docker，配置命令為：
# 進(jìn)入Boot2Docker Start Shell，并執(zhí)行
sudo su
echo “EXTRA_ARGS=\”–registry-mirror=\”” /var/lib/boot2docker/profile
exit
# 重啟Boot2Docker
配置好Registry Mirror后，就可以拉取Docker鏡像了，經(jīng)我測(cè)試，使用DaoCloud的Mirror后，拉取常見鏡像的速度可以達(dá)到1.5M左右，具體速度在你的網(wǎng)絡(luò)環(huán)境可能會(huì)略有不同。
我們來看看配置了Registry Mirror后，Docker拉取鏡像的過程吧。首先是CLI拉取鏡像命令代碼片段(docker/api/client/command.go中的CmdPull函數(shù))
首先，Docker CLI會(huì)試圖獲得授權(quán)，在我們的例子中會(huì)向請(qǐng)求認(rèn)證，認(rèn)證完成后，認(rèn)證服務(wù)器會(huì)返回一個(gè)對(duì)應(yīng)的Token。注意，這里用戶認(rèn)證與配置的Registry Mirror完全無關(guān)，這樣我們就不用擔(dān)心使用Mirror的安全問題了。接著Docker CLI會(huì)調(diào)用Docker Server（即Docker daemon程序）的創(chuàng)建鏡像命令，Docker Server隨之會(huì)執(zhí)行具體的拉取鏡像動(dòng)作，代碼片段如下(docker/graph/pull.go的pullRepository函數(shù))
從代碼中可以發(fā)現(xiàn)，如果配置了Registry Mirror，Docker Server會(huì)首先從Mirror中拉取鏡像，如果Mirror拉取失敗會(huì)退而求其次從鏡像中指定的Registry拉取。大家又可以松口氣了，就算配置的Registry Mirror失效，也不會(huì)影響用戶拉取鏡像，只不過速度就。。。
鏡像拉下來后，就可以運(yùn)行容器了
重慶分公司
重慶分公司
