當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

docker的安全管理与TLS/LLS加密通信

發布時間：2024/9/3 编程问答 33 豆豆

生活随笔收集整理的這篇文章主要介紹了 docker的安全管理与TLS/LLS加密通信小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

文章目錄

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

一：Docker 容器與虛擬機的區別

1.1 容器的安全性問題

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

1.2 隔離與共享

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

而Docker容器則是通過隔離的方式，將文件系統、進程、設備、網絡等資源進行隔離，再對權限、cpu資源等進行控制，最終讓容器之間互不影響,容器無法影響宿主機。Docker 通過Namespace進行隔離

容器與宿主機共享內核、文件系統、硬件等資源。

1.3 性能與損耗

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

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

而docker 容器與宿主機共享內核、文件系統等資源，更有可能對其他容器、宿主機產生影響。

不同點Docker容器虛擬機

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

二：Docker 存在的安全問題

2.1 Docker 自身漏洞

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

2.2 Docker 源碼問題

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

黑客上傳惡意鏡像

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

鏡像使用有漏洞的軟件

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

中間人攻擊篡改鏡像

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

三： Docker 架構缺陷與安全機制

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

3.1 容器之間的局域網攻擊

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

3.2 DDos攻擊耗盡資源

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

3.3 有漏洞的系統調用

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

3.4 共享root用戶權限

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

四： Docker 安全基準線標準

下面從內核、主機、網絡、鏡像、容器以及其它等6個方面總結Docker安全基線標準。

4.1 內核級別

及時更新內核。

User NameSpace (容器內的root權限在容器之外處于非高權限狀態)。

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

通過啟用SELinux/AppArmor/GRSEC (控制文件訪問權限)適當的強化系統來增加額外的安全性。

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

Seccomp (限定系統調用) ,限制不必要的系統調用。

禁止將容器的命名空間與宿主機進程命名空間共享,比如host網絡模式。

4.2 主機級別

為容器創建獨立分區，比如創建在分布式文件系統上。

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

禁止上將宿主機上敏感目錄映射到容器，-yv創建數據卷時需要注意。

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

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

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

4.3網絡級別

通過iptables設定規則實現禁止或允許容器之間網絡流量。

允許Docker修改iptables.

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

禁止在容器上映射特權端口。

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

禁止在容器上使用host網絡模式。

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

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 鏡像級別

創建本地私有鏡像倉庫服務器。

鏡像中軟件都為最新版本,建議根據實際情況使用對應版本,業務穩定優先。

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

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

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

使用鏡像掃描。

使用鏡像簽名。

4.5 容器級別

容器最小化,操作系統鏡像最小集。

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

禁止–privileged標記使用特權容器。

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

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

明確定義屬于容器的數據盤符。

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

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

4.6 其他設置

定期對宿主機系統及容器進行安全審計。

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

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

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

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

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

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

五：容器相關的常用安全配置

5.1 容器最小化

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

5.2 Docker遠程的API訪問控制

Docker 的遠程調用API 接口存在未授權訪問漏洞，至少應該限制外網訪問。建議使用Socket 方式訪問。

在docker 服務配置文件中指定監聽內網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

在客戶端實現遠程授權訪問

#在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

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

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

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

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

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

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

七鏡像安全

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

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

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

八： DockerClient 端與DockerDaemon 的通信安全

8.1 SSL/TLS的通信過程

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

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

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

客戶端發起請求,連接到服務器的進程端口。

服務器必須要有一套數字證書(證書內容有公鑰、證書頒發機構、失效日期等) 。

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

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

客戶端將公鑰加密后的密鑰發送到服務器。

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

服務器將加密后的密文數據返回到客戶端。

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

8.2 創建ca證書過程

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

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

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

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

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

8.3創建目錄，生成ca證書

8.3.1 創建目錄，生成私鑰文件

#卸載原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#創建目錄 [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算法產生私鑰

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

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

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

8.3.2 創建ca證書

#創建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:執行證書簽發命令-new:新證書簽發請求

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

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

-key:指定私鑰路徑

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

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

-out:輸出文件的路徑

8.4 用ca證書簽發server端證書

#創建服務器私鑰 [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證書與私鑰證書簽發服務端簽名證書（密碼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:表示創建證書序列號文件，創建的序列號文件默認名稱為ca.srl

8.5用ca 證書簽發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#創建擴展配置文件extfile.cnf，使得密鑰適合客戶端身份驗證 [root@host103 tls]# echo extendedKeyUsage=clientAuth > extfile.cnf#使用ca證書簽發客戶端簽名證書。密碼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服務配置文件，重啟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 復制ca證書和客戶端私鑰，客戶端簽名證書到客戶端主機，并修改服務端主機名，做hosts映射

# 復制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/#配置服務端主機名和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 上大量泄露個人或企業各種賬號密碼，出現這種問題一般都使用 dockerfile 或者 docker-compose 文件創建容器。如果這些文件中存在賬號密碼等認證信息，一旦 Docker 容器對外開放，則這些宿主機上的敏感信息也會隨之泄露。
因此可以通過以下方式檢查容器創建模板的內容。

# 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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： consul 自动发现与自动注册
下一篇：在做TLS/SSL时报错