文章目錄

• 一：Docker 容器與虛擬機的區(qū)別
• • 1.1 容器的安全性問題
  • 1.2 隔離與共享
  • 1.3 性能與損耗
• 二：Docker 存在的安全問題
• • 2.1 Docker 自身漏洞
  • 2.2 Docker 源碼問題
• 三： Docker 架構(gòu)缺陷與安全機制
• • 3.1 容器之間的局域網(wǎng)攻擊
  • 3.2 DDos攻擊耗盡資源
  • 3.3 有漏洞的系統(tǒng)調(diào)用
  • 3.4 共享root用戶權(quán)限
• 四： Docker 安全基準線標準
• • 4.1 內(nèi)核級別
  • 4.2 主機級別
  • 4.3網(wǎng)絡(luò)級別
  • 4.4 鏡像級別
  • 4.5 容器級別
  • 4.6 其他設(shè)置
• 五： 容器相關(guān)的常用安全配置
• • 5.1 容器最小化
  • 5.2 Docker遠程的API訪問控制
  • • 在docker 服務(wù)配置文件中指定監(jiān)聽內(nèi)網(wǎng)IP
    • 重啟docker
    • 在宿主機的firewalld上做ip訪問控制。source address 指定客戶端地址
    • 在客戶端實現(xiàn)遠程授權(quán)訪問
• 六： 限制流量流向
• 七 鏡像安全
• 八： DockerClient 端與DockerDaemon 的通信安全
• • 8.1 SSL/TLS的通信過程
  • 8.2 創(chuàng)建ca證書過程
  • 8.3創(chuàng)建目錄，生成ca證書
  • • 8.3.1 創(chuàng)建目錄，生成私鑰文件
    • 8.3.2 創(chuàng)建ca證書
  • 8.4 用ca證書簽發(fā)server端證書
  • 8.5用ca 證書簽發(fā)client端證書
  • 8.6 配置docker服務(wù)配置文件，重啟docker
  • 8.7 復(fù)制ca證書和客戶端私鑰，客戶端簽名證書到客戶端主機，并修改服務(wù)端主機名，做hosts映射
  • 8.8客戶端遠程訪問
• 九：避免Docker 容器中信息泄露

一：Docker 容器與虛擬機的區(qū)別

1.1 容器的安全性問題

容器的安全性問題的根源在于容器和宿主機共享內(nèi)核。如果容器里的應(yīng)用導(dǎo)致ELinux內(nèi)核崩潰，那么整個系統(tǒng)可能都會崩潰。與虛擬機是不同的，虛擬機并沒有與主機共享內(nèi)核，虛擬機崩潰一般不會導(dǎo)致宿主機崩潰。

1.2 隔離與共享

虛擬機通過添加Hypervisor層(虛擬化中間層)，虛擬出網(wǎng)卡、內(nèi)存、cpu等虛擬硬件，再在其上建立虛擬機，每個虛擬機都有自己的系統(tǒng)內(nèi)核。虛擬機通過Hypervisor進行隔離

而Docker容器則是通過隔離的方式，將文件系統(tǒng)、進程、設(shè)備、網(wǎng)絡(luò)等資源進行隔離，再對權(quán)限、cpu資源等進行控制，最終讓容器之間互不影響,容器無法影響宿主機。Docker 通過Namespace進行隔離

容器與宿主機共享內(nèi)核、文件系統(tǒng)、硬件等資源。

1.3 性能與損耗

與虛擬機相比，容器資源損耗要少。同樣的宿主機下，能夠建立容器的數(shù)量要比虛擬機多。

但是，虛擬機的安全性要比容器稍好,要從虛擬機攻破到宿主機或其他虛擬機，需要先攻破Hypervisor層，這是極其困難的。

而docker 容器與宿主機共享內(nèi)核、文件系統(tǒng)等資源，更有可能對其他容器、宿主機產(chǎn)生影響。

不同點Docker容器虛擬機

啟動速度	快，幾秒鐘	慢，幾分鐘
運行性能	接近原生（直接在內(nèi)核中運行）	運行與Hypervisor上，50%左右損失
磁盤占用	小，甚至幾十kb(根據(jù)鏡像層的情況)	非常大，上GB
并發(fā)性	一臺宿主機可以啟動成百上千個容器	最多幾十個虛擬機
隔離性	進程級別	系統(tǒng)級別（更徹底）
操作系統(tǒng)很	主要支持Linux	幾乎所有
封裝程度	只打包項目代碼和依賴關(guān)系，共享宿主機內(nèi)核	完整的操作系統(tǒng)，與宿主機隔離

二：Docker 存在的安全問題

2.1 Docker 自身漏洞

Docker自身漏洞作為一款應(yīng)用Docker本身實現(xiàn)上會有代碼缺陷。CVE官方記錄Docker歷史版本共有超過20項漏洞,可參見Docker官方網(wǎng)站。黑客常用的攻擊手段主要有代碼執(zhí)行、權(quán)限提升、信息泄露、權(quán)限繞過等。目前Docker版本更迭非常快, Docker用戶可將Docker升級為最新版本。

2.2 Docker 源碼問題

Docker提供了Docker hub,可以讓用戶上傳創(chuàng)建的鏡像,以便其他用戶下載,快速搭建環(huán)境。但同時也帶來了一些安全問題。例如下面三種方式:

黑客上傳惡意鏡像

• 如果有黑客在制作的鏡像中植入木馬、后門等惡意軟件,那么環(huán)境從一開始就已經(jīng)不安全了,后續(xù)更沒有什么安全可言。

鏡像使用有漏洞的軟件

• DockerHub上能下載的鏡像里面, 758的鏡像都安裝了有漏洞的軟件。所以下載鏡像后,需要檢查里面軟件的版本信息,對應(yīng)的版本是否存在漏洞,并及時更新打上補丁。

中間人攻擊篡改鏡像

• 鏡像在傳輸過程中可能被篡改, 目前新版本的Docker已經(jīng)提供了相應(yīng)的校驗機制來預(yù)防這個問題。

三： Docker 架構(gòu)缺陷與安全機制

Docker本身的架構(gòu)與機制就可能產(chǎn)生問題，例如這樣一種攻擊場景，黑客已經(jīng)控制了宿主機上的一些容器，或者獲得了通過在公有云上建立容器的方式，然后對宿主機或其他容器發(fā)起攻擊。

3.1 容器之間的局域網(wǎng)攻擊

主機上的容器之間可以構(gòu)成局域網(wǎng),因此針對局域網(wǎng)的ARP欺騙、端口掃描、廣播風暴等攻擊方式便可以用上。
所以,在一個主機上部署多個容器需要合理的配置網(wǎng)絡(luò)安全,比如設(shè)置iptables規(guī)則。

3.2 DDos攻擊耗盡資源

cgroups安全機制就是要防止此類攻擊的,不要為單一的容器分配過多的資源即可避免此類問題。

3.3 有漏洞的系統(tǒng)調(diào)用

Docker與虛擬機的一個重要的區(qū)別就是Docker與宿主機共用一個操作系統(tǒng)內(nèi)核。
一旦宿主內(nèi)核存在可以越權(quán)或者提權(quán)漏洞,盡管Docker使用普通用戶執(zhí)行,在容器被入侵時,攻擊者還可以利用內(nèi)核漏洞跳到宿主機做更多的事情。

3.4 共享root用戶權(quán)限

如果以root用戶權(quán)限運行容器(docker run --privileged) ,容器內(nèi)的root用戶也就擁有了宿主機的root權(quán)限

四： Docker 安全基準線標準

下面從內(nèi)核、主機、網(wǎng)絡(luò)、鏡像、容器以及其它等6個方面總結(jié)Docker安全基線標準。

4.1 內(nèi)核級別

及時更新內(nèi)核。

User NameSpace (容器內(nèi)的root權(quán)限在容器之外處于非高權(quán)限狀態(tài))。

cgroups (對資源的配額和度量) ,設(shè)置CPU、內(nèi)存、磁盤1o等資源限制。

通過啟用SELinux/AppArmor/GRSEC (控制文件訪問權(quán)限)適當?shù)膹娀到y(tǒng)來增加額外的安全性。

Capability (權(quán)限劃分) ,比如劃分指定的CPU給容器。

Seccomp (限定系統(tǒng)調(diào)用) ,限制不必要的系統(tǒng)調(diào)用。

禁止將容器的命名空間與宿主機進程命名空間共享,比如host網(wǎng)絡(luò)模式。

4.2 主機級別

為容器創(chuàng)建獨立分區(qū)，比如創(chuàng)建在分布式文件系統(tǒng)上。

僅運行必要的服務(wù)，注意盡量避免在容器中運行 ssh 服務(wù)。

禁止上將宿主機 上敏感目錄映射到容器，-yv創(chuàng)建數(shù)據(jù)卷時需要注意。

對 Docker 守護進程、相關(guān)文件和目錄進行審計，防止有病毒或木馬文件生成。

設(shè)置適當?shù)哪J文件描述符數(shù)。（文件描述符∶簡稱fd，當應(yīng)用程序請求內(nèi)核打開/新建一一個文件時，內(nèi)核會返回個文件描述符用于對應(yīng)這個系統(tǒng)資源，理論上系統(tǒng)內(nèi)存多大就應(yīng)該可以打開多少個文件描述符，但是實際情況是，內(nèi)核會有系統(tǒng)級限制，以及用戶級限制，不讓某一個應(yīng)用程序進程消耗掉所有的文件資源，可以使用ulimit -n 查看）

用戶權(quán)限為 root 的 Docker 相關(guān)文件的訪問權(quán)限應(yīng)該為 644 或者更低權(quán)限。（7）周期性檢查每個主機的容器清單，并清理不必要的容器。

4.3網(wǎng)絡(luò)級別

通過iptables設(shè)定規(guī)則實現(xiàn)禁止或允許容器之間網(wǎng)絡(luò)流量。

允許Docker修改iptables.

禁止將Docker綁定到其他已使用的IP/Port或者Unix Socket.

禁止在容器上映射特權(quán)端口。

容器上只開放所需要的端口。

禁止在容器上使用host網(wǎng)絡(luò)模式。

若宿主機有多個網(wǎng)卡,將容器進入流量綁定到特定的主機網(wǎng)卡上。

docker network create --subnet=172.18.0.0/16 --opt “com.docker.network.bridqe .name”=“docker1” mynetwork

docker run -itd --net mynetwork --ip 172.18.0.100 centos:7 /bin/bash

iptables -t nat -A POSTROUTING -s 172.18.0.100 -o ens36 -j SNAT --to-source 192.168.80.10

4.4 鏡像級別

創(chuàng)建本地私有鏡像倉庫服務(wù)器。

鏡像中軟件都為最新版本,建議根據(jù)實際情況使用對應(yīng)版本,業(yè)務(wù)穩(wěn)定優(yōu)先。

使用可信鏡像文件,并通過安全通道下載。

重新構(gòu)建鏡像而非對容器和鏡像打補丁,銷毀異常容器重新構(gòu)建。

合理管理鏡像標簽,及時移除不再使用的鏡像。

使用鏡像掃描。

使用鏡像簽名。

4.5 容器級別

容器最小化,操作系統(tǒng)鏡像最小集。

容器以單一主進程的方式運行。

禁止–privileged標記使用特權(quán)容器。

禁止在容器上運行ssh服務(wù),盡量使用docker exec進入容器。

以只讀的方式掛載容器的根目錄系統(tǒng), -v宿主機目錄:容器目錄:ro.

明確定義屬于容器的數(shù)據(jù)盤符。

通過設(shè)置on-failure限制容器嘗試重啟的次數(shù),容器反復(fù)重啟容易丟失數(shù)據(jù), --restart=on-failure:3

限制在容器中可用的進程數(shù), docker run -m限制內(nèi)存的使用,以防止fork炸彈。(fork炸彈,迅速增長子進程,耗盡系統(tǒng)進程數(shù)量) 經(jīng)典的fork炸彈： . () { .| .&};

4.6 其他設(shè)置

定期對宿主機系統(tǒng)及容器進行安全審計。

使用最少資源和最低權(quán)限運行容器,此為Docker容器安全的核心思想。

避免在同一宿主機上部署大量容器,維持在一個能夠管理的數(shù)量。

監(jiān)控Docker容器的使用,性能以及其他各項指標,比如zabbix

增加實時威脅檢測和事件報警響應(yīng)功能,比如zabbix.

使用中心和遠程日志收集服務(wù),比如ELK 。

由于安全屬于非常具體的技術(shù),這里不再贅述,可直接參閱Docker官方文檔, https://docs.docker.com/engine/security

五： 容器相關(guān)的常用安全配置

5.1 容器最小化

如果僅在容器中運行必要的服務(wù)，像SSH等服務(wù)是不能輕易開啟去連接容器的。通常使用一下方式進入容器
docker exec -it 容器ID bash

5.2 Docker遠程的API訪問控制

Docker 的遠程調(diào)用API 接口存在未授權(quán)訪問漏洞，至少應(yīng)該限制外網(wǎng)訪問。建議使用Socket 方式訪問。

在docker 服務(wù)配置文件中指定監(jiān)聽內(nèi)網(wǎng)IP

[root@host103 ~]#vim /usr/lib/systemd/system/docker.service 13行修改 13:// ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock -H tcp://192.168.23.103:2375

重啟docker

[root@host103 ~]# systemctl daemon-reload [root@host103 ~]# systemctl restart docke[root@host103 ~]# netstat -natp | grep 2375 tcp 0 0 192.168.23.103:2375 0.0.0.0:* LISTEN 77808/dockerd

在宿主機的firewalld上做ip訪問控制。source address 指定客戶端地址

[root@host103 ~]# firewall-cmd --permanent --add-rich-rule="rule family="ipv4" source address="192.168.23.104" port protocol="tcp" port="2375" accept" success[root@host103 ~]# firewall-cmd --reload success

在客戶端實現(xiàn)遠程授權(quán)訪問

#在host103主機docker 客戶端啟動容器 [root@host103 ~]# docker run -itd --name test1 centos:7 bas [root@host103 ~]# docker run -itd --name test2 centos:7 ba [root@host103 ~]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS e816df360df1 centos:7 "bash" 4 seconds ago Up 3 secon acfda848249f centos:7 "bash" 8 seconds ago Up 8 sec#可以使用 -H選項指定ip和端口，能夠使用遠程的docker [root@host104 ~]# docker -H tcp://192.168.23.103:2375 ps CONTAINER ID IMAGE COMMAND CREATED STAT e816df360df1 centos:7 "bash" 13 seconds ago Up 1 acfda848249f centos:7 "bash" 17 seconds ago Up

六： 限制流量流向

使用防火墻過濾器限制Docker容器的源IP 地址范圍與外界通信

[root@host103 ~]# firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv4" source address="192.168.100.0/24" reject" success

生產(chǎn)環(huán)境中的大量問題是因為Docker容器端口外放引起的漏洞,除了操作系統(tǒng)賬戶權(quán)限控制上的問題,更在于對Docker Daemon的進程管理上存在隱患。

目前常用的Docker版本都支持Docker Daemon管理宿主機iptables的,而且一旦啟動進程加上-p host port:guest port

的端口映射, Docker Daemon會直接增加對應(yīng)的FORWARD Chain并且-j ACCEPT,而默認的DROP規(guī)則是在INPUT鏈做的,對docker沒法限制,這就留下了很嚴重的安全隱患。因此建議:

(1)不在有外網(wǎng)ip的機器上使用Docker服務(wù)。

(2)使用k8s等docker編排系統(tǒng)管理Docker容器。

(3)宿主機上Docker daemon啟動命令加一個–iptables=false,然后把常用iptables規(guī)則寫進文件里,再用iptables-restore重定向輸入去刷新規(guī)則。

七 鏡像安全

一般情況下,要確保只從受信任的庫中獲取鏡像,推薦使用harbor私有倉庫。

如果公司使用的不是自己的鏡像源,需要使用Docker鏡像安全掃描工具Clair,對下載的鏡像進行檢查。通過與CVE數(shù)據(jù)庫同步掃描鏡像,驗證鏡像的md5等特征值,確認一致后再基于鏡像進一步構(gòu)建。一旦發(fā)現(xiàn)漏洞則通知用戶處理,或者直接阻止鏡像繼續(xù)構(gòu)建。

也可以使用linux自帶的md5sum工具

八： DockerClient 端與DockerDaemon 的通信安全

8.1 SSL/TLS的通信過程

為了防止鏈路劫持、會話劫持等問題導(dǎo)致Docker通信時被中間人攻, c/s兩端應(yīng)該通過TLs加密方式通訊。

通過在服務(wù)端上創(chuàng)建t1s密鑰證書,再下發(fā)給客戶端,客戶端通過私鑰訪問容器,這樣就保證的docker通訊的安全性。

使用證書訪問的工作流程:

客戶端發(fā)起請求,連接到服務(wù)器的進程端口。

服務(wù)器必須要有一套數(shù)字證書(證書內(nèi)容有公鑰、證書頒發(fā)機構(gòu)、失效日期等) 。

服務(wù)器將自己的數(shù)字證書發(fā)送給客戶端(公鑰在證書里面,私鑰由服務(wù)器持有)。

客戶端收到數(shù)字證書之后,會驗證證書的合法性。如果證書驗證通過,就會生成一個隨機的密鑰對,用證書的公鑰加密。

客戶端將公鑰加密后的密鑰發(fā)送到服務(wù)器。

服務(wù)器接收到客戶端發(fā)來的密文密鑰之后,用自己之前保留的私鑰對其進行非對稱解密,解密之后就得到客戶端的密鑰,然后用客戶端密鑰對返回數(shù)據(jù)進行對稱加密,這樣傳輸?shù)臄?shù)據(jù)都是密文了

服務(wù)器將加密后的密文數(shù)據(jù)返回到客戶端。

客戶端收到后,用自己的密鑰對其進行對稱解密,得到服務(wù)器返回的數(shù)據(jù)。

8.2 創(chuàng)建ca證書過程

首先創(chuàng)建ca證書, ca證書只是一個官方認證的證書,接下來要創(chuàng)建server, client節(jié)點的證書。此時創(chuàng)建證書有三步:

(1)設(shè)置私鑰,確保安全加密

(2)使用私鑰簽名,確保身份真實不可抵賴

(3)使用ca證書制作證書

注意，docker 的go 版本要再1.15版本以下

8.3創(chuàng)建目錄，生成ca證書

8.3.1 創(chuàng)建目錄，生成私鑰文件

#卸載原docker-ce docker-ce-cli，安裝20.10.5-3的版本 [root@host103 ~]#yum remove -y docker-ce-cli docker-ce [root@host103 ~]#yum install -y docker-ce-cli-20.10.5-3.el7.x86_64 docker-ce #docker version查看到的docker 信息中，go版本不可以高于1.15 [root@host103 ~]#docker version#創(chuàng)建目錄 [root@host103 ~]# mkdir /tls [root@host103 ~]# cd /tls/#使用openssl 生成私鑰 [root@host103 tls]# openssl genrsa -aes256 -out ca-key.pem 4096 Generating RSA private key, 4096 bit long modulus ..............................................................................++ .......................................................................++ e is 65537 (0x10001) #驗證密碼輸入123123 Enter pass phrase for ca-key.pem:123123 Verifying - Enter pass phrase for ca-key.pem:123123

genrsa:使用RSA算法產(chǎn)生私鑰

-aes256:使用256位密鑰的AEs算法對私鑰進行加密，這樣每次使用私鑰文件都將輸入密碼，可省略

-out:輸出文件的路徑，若未指定輸出文件，則為標準輸出

4096:指定私鑰長度，默認為1024。該項必須為命令行的最后一項參數(shù)

8.3.2 創(chuàng)建ca證書

#創(chuàng)建ca證書 [root@host103 tls]# openssl req -new -x509 -days 1000 -key ca-key.pem -sha256 -subj "/CN=*" -out ca.pem #驗證密碼，是之前的123123 Enter pass phrase for ca-key.pem: 123123[root@host103 tls]# ls ca-key.pem ca.pem

req:執(zhí)行證書簽發(fā)命令-new:新證書簽發(fā)請求

-x509:生成x509格式證書，專用于創(chuàng)建私有cA時使用

-days:證書的有效時長，單位是天

-key:指定私鑰路徑

-sha256:證書摘要采用sha256算法

-subj: 證書相關(guān)的用戶信息 (subject的縮寫)

-out:輸出文件的路徑

8.4 用ca證書簽發(fā)server端證書

#創(chuàng)建服務(wù)器私鑰 [root@host103 tls]# openssl genrsa -out server-key.pem 4096 Generating RSA private key, 4096 bit long modulus ...................................................++ ..............++ e is 65537 (0x10001)#生成證書簽名請求文件（csr文件） [root@host103 tls]# openssl req -new -key server-key.pem -sha256 -subj "/CN=*" -out server.csr [root@host103 tls]# ls ca-key.pem ca.pem server.csr server-key.pem#使用ca證書與私鑰證書簽發(fā)服務(wù)端簽名證書（密碼123123） [root@host103 tls]# openssl x509 -req -days 1000 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem Signature ok subject=/CN=* Getting CA Private Key Enter pass phrase for ca-key.pem:123123[root@host103 tls]# ls ca-key.pem ca.pem ca.srl server-cert.pem server.csr server-key.pem

x509:生成x509格式證書

-req:輸入csr文件

-in:要輸入的csr文件

-CA:指定ca證書的路徑

-CAkey:指定ca證書的私鑰路徑

-CAcreateserial:表示創(chuàng)建證書序列號文件，創(chuàng)建的序列號文件默認名稱為ca.srl

8.5用ca 證書簽發(fā)client端證書

#生成客戶端私鑰 [root@host103 tls]# openssl genrsa -out client-key.pem 4096 Generating RSA private key, 4096 bit long modulus ......++ ............++ e is 65537 (0x10001) #生成了客戶端私鑰client-key.pem [root@host103 tls]# ls ca-key.pem ca.pem ca.srl client-key.pem server-cert.pem server.csr server-key.pem#生成證書簽名請求文件client-csr [root@host103 tls]# openssl req -new -key client-key.pem -subj "/CN=client" -out client.csr [root@host103 tls]# ls ca-key.pem ca.pem ca.srl client.csr client-key.pem server-cert.pem server.csr server-key.pem#創(chuàng)建擴展配置文件extfile.cnf，使得密鑰適合客戶端身份驗證 [root@host103 tls]# echo extendedKeyUsage=clientAuth > extfile.cnf#使用ca證書簽發(fā)客戶端簽名證書。密碼123123 [root@host103 tls]# openssl x509 -req -days 1000 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out client-cert.pem -extfile extfile.cnf Signature ok subject=/CN=client Getting CA Private Key Enter pass phrase for ca-key.pem:[root@host103 tls]# ls ca-key.pem ca.pem ca.srl client-cert.pem client.csr client-key.pem extfile.cnf server-cert.pem server.csr server-key.pem#刪除兩個證書簽名請求文件和擴展配置文件 [root@host103 tls]# rm -rf ca.srl client.csr extfile.cnf server.csr [root@host103 tls]# ls ca-key.pem ca.pem client-cert.pem client-key.pem server-cert.pem server-key.pem

8.6 配置docker服務(wù)配置文件，重啟docker

[root@host103 tls]# vim /lib/systemd/system/docker.service #修改13行 ExecStart=/usr/bin/dockerd --tlsverify --tlscacert=/tls/ca.pem --tlscert=/tls/server-cert.pem --tlskey=/tls/server-key.pem -H fd:// --containerd=/run/containerd/containerd.sock -H tcp://0.0.0.0:2376#重啟docker配置 [root@host103 tls]# systemctl daemon-reload [root@host103 tls]# systemctl restart docker [root@host103 tls]# netstat -natp | grep 2376 tcp6 0 0 :::2376 :::* LISTEN 81977/dockerd [root@host103 tls]# setenforce 0

8.7 復(fù)制ca證書和客戶端私鑰，客戶端簽名證書到客戶端主機，并修改服務(wù)端主機名，做hosts映射

# 復(fù)制ca證書和客戶端私鑰，客戶端簽名證書到客戶端主機 [root@host103 tls]# scp ca.pem 192.168.23.104:/etc/docker/ [root@host103 tls]# scp client-cert.pem 192.168.23.104:/etc/docker/ [root@host103 tls]# scp client-key.pem 192.168.23.104:/etc/docker/#配置服務(wù)端主機名和ip映射 [root@host103 tls]# echo '127.0.0.1 host103' >> /etc/hosts#本地連接 [root@host103 tls]# docker --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem -H tcp://host103:2376 images REPOSITORY TAG IMAGE ID CREATED SIZE#本地連接 [root@host103 tls]# docker --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem -H tcp://host103:2376 pull nginx[root@host103 tls]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE nginx latest 87a94228f133 8 days ago 133MB

8.8客戶端遠程訪問

[root@client ~]#yum remove -y docker-ce-cli docker-ce [root@client ~]#yum install -y docker-ce-cli-20.10.5-3.el7.x86_64 docker-ce[root@client ~]# echo '192.168.23.103 host103' > /etc/hosts[root@client ~]# cd /etc/docker/ [root@client docker]# ls ca.pem client-cert.pem client-key.pem daemon.json key.json[root@client docker]# docker --tlsverify --tlscacert=ca.pem --tlscert=client-cert.pem --tlskey=client-key.pem -H tcp://host103:2376 images REPOSITORY TAG IMAGE ID CREATED SIZE nginx latest 87a94228f133 8 days ago 133MB

如果訪問報錯如下：

rpc error: code = Unavailable desc = connection error: desc = "transport: authentication handshake failed: x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0"

則是因為docker版本過高，其go版本高于1.15，因為為 go 1.15 版本開始廢棄 CommonName

九：避免Docker 容器中信息泄露

近幾年 Github 上大量泄露個人或企業(yè)各種賬號密碼，出現(xiàn)這種問題一般都使用 dockerfile 或者 docker-compose 文件創(chuàng)建容器。 如果這些文件中存在賬號密碼等認證信息，一旦 Docker 容器對外開放，則這些宿主機上的敏感信息也會隨之泄露。
因此可以通過以下方式檢查容器創(chuàng)建模板的內(nèi)容。

# check created users grep authorized_keys $dockerfile# check OS users grep "etc/group" $dockerfile# Check sudo users grep "etc/sudoers.d" $dockerfile# Check ssh key pair grep ".ssh/.*id_rsa" $dockerfile

總結(jié)

以上是生活随笔為你收集整理的docker的安全管理与TLS/LLS加密通信的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。