文章目錄
前言:
Docker容器是目前很火的技術之一,應用的場景也非常之多,由此而來的安全問題更是稱爲了重中之重,本篇博客就Docker安全管理,做一些講述。
一、Docker使用場景
-
次處列舉了Docker 的8個使用場景,分別爲:
-
① 簡化配置
- 虛擬機的最大好處是能在你的硬件設施上運行各種配置不一樣的平臺(軟件, 系統), Docker在降低額外開銷的情況下提供了同樣的功能. 它能讓你將運行環境和配置放在代碼彙總然後部署, 同一個Docker的配置可以在不同的環境環境中使用, 這樣就降低了硬件要求和應用環境之間耦合度.
-
② 代碼流水線管理
- 代碼從開發者的機器到最終在生產環境上的部署, 需要經過很多的中堅環境. 而每一箇中間環境都有自己微小的差別, Docker給應用提供了一個從開發到上線均一致的環境, 讓代碼的流水線變得簡單不少
-
③ 提升開發效率
-
不同環境中, 開發者的共同目標
想讓開發環境儘量貼近生產環境
想快速搭建開發環境
-
開發環境的機器通常內存比較小, 之前使用虛擬的時候, 我們經常需要爲開發環境的機器加內存, 而現在Docker可以輕易的讓幾十個服務在Docker中跑起來
-
-
④ 隔離應用
-
開發時會在一個臺機器上運行不同的應用
爲了降低成本, 進行服務器整合
將一個整體式的應用拆分成低耦合的單個服務(微服務架構)
-
-
⑤ 整合服務器
- Docker隔離應用的能力使得Docker可以整合多個服務器以降低成本. 由於沒有多個操作系統的內存佔用, 以及能在多個實例之間共享沒有使用的內存, Docker可以比虛擬機提供更好的服務器整合解決方案
-
⑥ 調式能力
- Docker提供了很多的工具, 這些工具不一定只是針對容器, 但是卻適用於容器. 他們提供了很多功能, 包括可以爲容器設置檢查點, 設置版本, 查看兩個容器之間的差別, 這些特性可以幫助調試Bug
-
⑦ 多租戶環境
- 多租戶環境的應用中, 它可以避免關鍵應用的重寫.我們一個特別的關於這個場景的例子是爲loT(物聯網)的應用開發一個快速, 易用的多租戶環境. 這種多租戶的基本代碼非常複雜, 很難處理, 重新規劃以應用不但消耗時間, 也浪費金錢
- 使用Docker, 可以爲每一個租戶的應用層的多個實例創建隔離的環境, 這不僅簡單而且成本低廉, 因爲Docker環境啓動的速度快, diff命令很高效
-
⑧ 快速部署
- Docker爲進程創建一個容器, 不需要啓動一個操作系統, 時間縮短爲秒級別
- 可以在數據中心創建銷燬資源而無須擔心重新啓動帶來的開銷. 通常數據中心的資源利用率只有30% , 通過使用Docker並進行有效的資源分配可以提高資源的利用率
二、Docker 容器與虛擬機的區別
2.1 隔離與共享
- 虛擬機通過添加Hypervisor(虛擬機監視器:用於虛擬化硬件)層,虛擬出網卡、內存、CPU等虛擬硬件,再在其上建立虛擬機,每個虛擬機都由自己的系統內核。
- Docker容器則是通過隔離的方式,將文件系統、進程、設備、網絡等資源進行隔離,再對權限、CPU資源等進行控制。最終讓容器之間互不影響
- 容器無法影響宿主機,容器與宿主機共享內核、文件系統、硬件等資源(此處就是隱患之一,可以使用cgroups資源控制來防範)
2.2 性能與損耗
- 與虛擬機相比,容器資源損耗較小,同樣的宿主機下,能夠建立容器的數量要比虛擬機多(虛擬機受設定的內存空間限制),容器啓動速度類似於應用,如:systemctl start firewalld,近似於毫秒級別。但是,虛擬機的安全性要比容器稍好。
- 如果要從虛擬機共破到宿主機或者其他虛擬機,需要先攻破Hypervisor層,這是極其困難的
- 而docker容器與宿主機共享內核、文件系統等資源,更有可能對其他容器產生影響
三、Docker 存在的安全問題
3.1 Docker 自身漏洞
- 作爲一款應用,Docker 本身實現上會有代碼缺陷。CVE官方記錄Docker歷史版本共有超過20項漏洞
- 黑客常用的攻擊手段主要有代碼執行、權限提升、信息泄露、權限繞過等。目前Docker版本更迭非常快
- 使用Docker 最好將其升級爲最新版本
3.2 Docker 源碼問題
- Docker 提供了Docker hub,可以讓用戶上傳創建的鏡像,以便其他用戶下載,快速搭建環境。
- 同時也帶來了一些安全問題。例如以下三種情況:
- ① 黑客上傳惡意鏡像:如果有黑客再製作的鏡像中植入木馬、後門等惡意軟件,那麼環境從一開始就已經不安全了,後續更沒有什麼安全可言。
- ② 鏡像使用有漏洞的軟件:Docker hub 上能下載的鏡像裏面,75%的鏡像都安裝了有漏洞的軟件,所以在下載鏡像後,需要檢查其中軟件的版本信息,對應的版本信息是否存在漏洞,並及時更新打上補丁
- ③ 中間人攻擊篡改鏡像:鏡像在傳輸過程中可能被篡改,目前版本的Docker已經提供了想要的校驗機制來預防這個問題
3.3 Docker 架構缺陷與安全機制
-
Docker 本身的架構與機制就可能產生問題,例如以下攻擊場景:
-
黑客已經控制了宿主機上的一些容器,或者獲得了通過在公有云上建立榮光其的方式,然後對宿主機或者其他容器發起攻擊。
-
① 容器之間的局域網攻擊
主機上的容器之間可以構成局域網,因此針對局域網的ARP欺騙、嗅探、廣播風暴等攻擊方式便可以用上
-
② DDos 攻擊耗盡資源
Cgroups安全機制就是要防止此類工具,不要爲單一的容器分配過多的資源即可避免此類問題
-
③ 有漏洞的系統調用
Docker與虛擬機的一個重要的區別就是Docker與宿主機共用一個操作系統內核。一旦宿主內核存在可以越權或者提權的漏洞,儘管Docker使用普通用戶執行,在容器被侵入的時候,攻擊者還可以利用內核漏洞作爲跳板跳到宿主機做更多的事情。
-
④ 共享root用戶權限
如果以root用戶權限運行容器,容器內的root用戶也就擁有了宿主機的root權限
-
3.4 Docker 安全基線標準
- 此處將從內核、主機、網絡、鏡像、容器以及其他等6個方面總結Docker 安全基線標準
3.4.1 內核級別
- ① 及時更新內核
- ② User NameSpace (容器內的root權限在容器之外儲於非高權限狀態)
- ③ Cgroups(對資源的配額和度量)
- ④ Selinux/AppArmor/GRSEC(控制文件訪問權限)
- ⑤ Capability(權限劃分)
- ⑥ Seccomp(限定系統調用)
- ⑦ 禁止將容器命名空間與宿主機進程命名空間共享
3.4.2 主機級別
- ① 爲容器創建獨立分區
- 不要和其他應用掛載在同一個分區,可以使用一塊遠程的存儲空間(分佈式文件系統)直接掛載使用
- ② 僅允許必要的服務
- ③ 禁止將宿主機上敏感目標映射到容器
- ④ 對Docker 守護進程、相關文件和目錄進行審計
- ⑤ 設置適當的默認文件描述符數
- 文件描述符:內核(kernel)利用文件描述符(file descriptor)來訪問文件。文件描述符是非負整數
- 打開現存文件或新建文件時,內核會返回一個文件描述符,讀寫文件也需要使用文件描述符來指定待讀寫的文件
- ⑥ 用戶權限爲root的Docker相關文件的訪問權限應該設爲644或者更低權限
- ⑦ 週期性檢查每個主機的容器清單,並清理不必要的容器
3.4.3 網絡級別
- ① 通過iptables 設定規則實現禁止或允許容器之間網絡流量
- ② 允許Docker修改iptables
- ③ 禁止將Docker綁定到其他IP/Port 或者Unix Socket
- ④ 禁止容器上映射特權端口
- ⑤ 容器上之開放所需要的端口
- ⑥ 禁止在容器上使用主機網絡模式
- ⑦ 若宿主機有多個網卡,將容器進入流量綁定到特定的主機網卡上
3.4.4 鏡像級別
- ① 創建本地鏡像倉庫服務器
- ② 鏡像中軟件都爲最新版本
- ③ 使用可信鏡像文件,並通過安全通道下載
- ④ 重新構建鏡像而非對容器和鏡像打補丁
- ⑤ 合理管理鏡像標籤,及時一處不再使用的鏡像
- ⑥ 使用鏡像掃描
- ⑦ 使用鏡像前面
3.4.5 容器級別
- ① 容器最小化,操作系統鏡像最小集
- ② 容器以單一主進程的方式允許
- ③ 禁止privileged 標記使用特權容器
- ④ 禁止在容器上運行ssh服務
- ⑤ 以只讀的方式掛載容器的根目錄系統
- ⑥ 明確定義屬於容器的數據盤符
- ⑦ 通過設置on-failure 限制容器嘗試重啓的次數,容器反覆重啓容易丟失數據
- ⑧ 限制在容器中可用的進程數,以防止fork bomb (fork炸彈,迅速增長子進程,耗盡系統進程數量)
3.4.6 其他設置
- ① 定期對宿主機系統及容器進行安全審計
- ② 使用最少資源和最低權限運行容器
- ③ 避免在統一宿主機上部署大量容器,維持在一個能夠管理的數量
- ④ 監控Docker 容器的使用,性能以及其他各項指標
- ⑤ 增加實時威脅檢測和事件響應功能
- ⑥ 使用中心和遠程日誌收集服務
四、容器訪問控制
- 如果僅在容器中運行必要的服務,像SSH等服務是不能輕易開啓去連接容器的,通常使用以下方式來進入容器
docker exec -it 容器ID bash
4.1 Docker remote api 訪問控制
-
Docker 的遠程調用API接口存在未授權訪問漏洞,至少應限制外網訪問,可以使用Socket 方式訪問
-
準備兩臺centos 7虛擬機
- docker 1 IP爲192.168.226.132
- docker 2 IP爲192.168.226.133
- 目的:在docker1服務器查看docker2服務的鏡像/容器狀態
4.2 Docker 2服務器配置
- 環境設置
#關閉核心防護
[root@docker2 ~]# setenforce 0
#查看服務狀態
[root@docker2 ~]# netstat -natp | grep docker
[root@docker2 ~]#
#可見,docker未對外提供訪問的端口,無法訪問
- 開啓訪問
[root@docker2 ~]# vim /usr/lib/systemd/system/docker.service
#14行註銷,14行準啓動中地址指向的是本地的通訊文件目錄
#15行插入以下內容,對外提供2375端口
ExecStart=/usr/bin/dockerd -H unix:///var/run/docker.sock -H tcp://192.168.226.133:2375
#以上配置項中,通訊文件使用的是unix的
#-H 指定監聽地址爲本地IP且對外提供的端口爲2375
......省略部分內容
- 重新加載參數、重啓docker
[root@docker2 ~]# systemctl daemon-reload
[root@docker2 ~]# systemctl restart docker
[root@docker2 ~]# netstat -natp | grep docker
tcp 0 0 192.168.226.133:2375 0.0.0.0:* LISTEN 28163/dockerd
#可見通過2375端口被訪問
- 以TCP通訊的方式查看本地容器信息
[root@docker2 ~]# docker -H tcp://192.168.226.133:2375 version
Client: Docker Engine - Community
Version: 19.03.8
API version: 1.40
Go version: go1.12.17
Git commit: afacb8b
Built: Wed Mar 11 01:27:04 2020
OS/Arch: linux/amd64
Experimental: false
......省略部分內容
- 下載鏡像、創建容器
[root@docker2 ~]# docker pull nginx
[root@docker2 ~]# docker run -itd --name c1 nginx /bin/bash
.....省略部分內容
4.2 Docker 1 使用Tcp通訊方式訪問Docker 2
- Docker 2需要關閉防火牆或者清空防火牆規則Docker 1纔可以以Tcp通訊方式進行訪問查詢
#Dokcer 2 清空防火牆規則
iptbales -F
#Docker 1 遠程查看Docker 2鏡像列表
[root@docker1 ~]# docker -H tcp://192.168.226.133:2375 images
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx latest 602e111c06b6 2 days ago 127MB
五、 限制流量流向
- 當創建容器之後,會在防火牆中創建規則,允許外部進行訪問,但是防火牆默認是沒有做內部主動訪問外部的規則,所以需要主動設置規則保證安全
- 使用防火牆過濾器限制Docker 容器的源IP地址範圍和外界通訊
[root@docker1 ~]# firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv4" source address="192.168.226.132/24" reject"
success
#重載規則
[root@docker1 ~]# firewall-cmd --reload
success
-
參數詳解:
–permanent :永久生效
–zone=public :公共區域
–add-rich-rule:定義副語言規則
rule family=“ipv4”:版本爲ipv4
source address="192.168.226.132/24 :目標源地址爲本地IP 24網段
reject :拒絕
-
對於外網訪問本地端口的安全問題及建議如下:
-
① 安全問題:
一般來說,大量問題是因爲Docker容器端口外放引起的漏洞。除了操作系統賬戶權限控制上的問題,更在於對Docker Daemon的進程管理上存在隱患,目前常用的Docker版本都支持Docker Daemon 管理宿主的iptables,而且一旦啓動進程加上-p host_port:guest_port 的端口映射,Dokcer Daemon 會直接增加對於的FORWARD Chain並且-j ACCEPT,而默認的DROP規則是在INPUT鏈做的,對docker沒法限制,這就留下了很嚴重的安全隱患。
② 建議:
- ① 不再有外網ip的機器上使用Docker服務
- ② 使用k8s等docker 編排系統管理Docker 容器
- ③ 宿主上Docker daemon啓動命令加一個–iptbales=false,然後把常用的iptables寫進文件裏,再用iptables-restore刷新
六、鏡像安全
- Docker 鏡像安全掃描,在鏡像倉庫客戶端使用證書認證,對下載的鏡像進行檢查
- 通過與CVE數據同步掃描鏡像,一旦發現漏洞則通知用戶處理,或者直接組織鏡像繼續構建
- 如果企業使用的是自己的鏡像源,可以跳過此步,否則需要驗證baseimage 的md5等特質,確認後再進一步構建
- 一般情況下,要確保只從受信任的庫中獲取鏡像,並且不建議使用–insecure-registry=[] 參數,推薦使用harbor私有倉庫
七、Docker-TLS加密通訊
7.1 TLS簡介
-
TLS(Transport Layer Security,安全傳輸層),TLS是建立在傳輸層TCP協議之上的協議,服務於應用層,它的前身是SSL(Secure Socket Layer,安全套接字層),它實現了將應用層的報文進行加密後再交由TCP進行傳輸的功能。
-
爲了防止鏈路劫持、會話劫持等問題導致Docker通訊時被中間人攻擊,c/s 兩端應該通過加密方式通訊
-
CA認證:
證書頒發機構(CA, Certificate Authority)即頒發數字證書的機構。是負責發放和管理數字證書的權威機構,並作爲電子商務交易中受信任的第三方,承擔公鑰體系中公鑰的合法性檢驗的責任。
CA 證書頒發的時候,證書中是包含密鑰對的,同時用戶信息也是進行加密的,所以CA頒發的證書具有兩個特點:
① 用戶發送的信息都是加密的
② 身份的唯一性
7.2 TLS 配置詳解
-
實驗環境
兩臺centos7 (與上文的IP一致),鏡像還原到只安裝了Docker 的狀態
Docker 1 作爲服務端(master)
Docker 2 作爲客戶端(client)
7.2.1 服務端配置
- ① 修改主機名和映射文件
[root@localhost ~]# hostnamectl set-hostname master
[root@localhost ~]# su
[root@master ~]# vim /etc/hosts
127.0.0.1 master
- ② 創建tls目錄
[root@master ~]# mkdir /tls
- ③ 創建ca密鑰
[root@master tls]# openssl genrsa -aes256 -out ca-key.pem 4096
Generating RSA private key, 4096 bit long modulus
.............................++
....++
e is 65537 (0x10001)
Enter pass phrase for ca-key.pem: #設置密碼爲123123
Verifying - Enter pass phrase for ca-key.pem: #重複輸入
[root@master tls]# ls
ca-key.pem
-
參數詳解:
openssl :開放源代碼的軟件庫包,應用程序可以使用這個包來進行安全通信,避免竊聽。
genrsa:rsa 非對稱密鑰
-aes256:指定密鑰長度位256位
-out ca-key.pem:創建ca-key.pam密鑰文件
-
④ 創建ca證書
[root@master tls]# openssl req -new -x509 -days 1000 -key ca-key.pem -sha256 -subj "/CN=*" -out ca.pam
Enter pass phrase for ca-key.pem: #創建ca密鑰時設置的密碼
[root@master tls]# ls
ca-key.pem ca.pam
#此ca.pam證書是官方頒發的
-
參數詳解、
req -new:請求創建新的證書
-x509:證書的一個參數
-days:證書週期是1000天
-key:指定密鑰文件
-sha256:哈希驗證
-subj “/CN=*”:指定項目名稱
-out ca.pam:產生出ca證書
-
⑤ 創建證書
以上創建完成後,下面的步驟爲:
- 創建自己”master"服務端的證書和“client”客戶端的證書
① 創建服務端證書
#創建私鑰
[root@master tls]# openssl genrsa -out server-key.pem 4096
Generating RSA private key, 4096 bit long modulus
.............................................................................................................................................++
....................++
e is 65537 (0x10001)
#簽名私鑰
[root@master tls]# openssl req -subj "/CN=*" -sha256 -new -key server-key.pem -out server.csr
#使用server-key.pem 密鑰文件進行簽名,生成簽名文件
#server.csr 簽名文件
[root@master tls]# ls
ca-key.pem ca.pam server.csr server-key.pem
#使用ca證書與私鑰證書籤名,密碼輸入123123,生成服務端 509證書
- 使用ca證書與私鑰證書籤名,密碼輸入123123,生成服務端 509證書
[root@master tls]# openssl x509 -req -days 1000 -sha256 -in server.csr -CA ca.pam -CAkey ca-key.pem -CAcreateserial -out server-cert.pem
Signature ok
subject=/CN=*
Getting CA Private Key
Enter pass phrase for ca-key.pem:
[root@master tls]# ls
ca-key.pem ca.pam ca.srl server-cert.pem server.csr server-key.pem
-
參數詳解
openssl x509:使用openssl方式生成 509證書
-req :請求
-days 1000:有效期天數
-sha256:哈希值驗證
-in server.csr :導入簽名文件
-CA ca.pam :加入CA官方授權的證書
-CAkey ca-key.pem:加入CA官方的密鑰
-CAcreateserial -out server-cert.pem:創建服務端的證書
-
② 創建客戶端證書
客戶端的證書也是要由服務端進行申請
#創建密鑰
[root@master tls]# openssl genrsa -out key.pem 4096
Generating RSA private key, 4096 bit long modulus
................................................++
...............++
e is 65537 (0x10001)
[root@master tls]# ls
ca-key.pem ca.pam ca.srl key.pem server-cert.pem server.csr server-key.pem
#使用密鑰進行簽名
[root@master tls]# openssl req -subj "/CN=client" -new -key key.pem -out client.csr
[root@master tls]# ls
ca-key.pem ca.srl key.pem server.csr
ca.pam client.csr server-cert.pem server-key.pem
-
創建配置文件
區分服務端和客戶端
[root@master tls]# echo extendedKeyUsage=clientAuth > extfile.cnf
[root@master tls]# ls
ca-key.pem ca.srl extfile.cnf server-cert.pem server-key.pem
ca.pam client.csr key.pem server.csr
- 簽名證書
[root@master tls]# openssl x509 -req -days 1000 -sha256 -in client.csr -CA ca.pam -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile extfile.cnf
Signature ok
subject=/CN=client
Getting CA Private Key
Enter pass phrase for ca-key.pem: #密碼123123
[root@master tls]# ls
ca-key.pem ca.srl client.csr key.pem server.csr
ca.pam cert.pem extfile.cnf server-cert.pem server-key.pem
- ⑥ 刪除多餘文件
[root@master tls]# rm -rf ca.srl client.csr extfile.cnf server.csr
[root@master tls]# ls
ca-key.pem ca.pam cert.pem key.pem server-cert.pem server-key.pem
[root@master tls]# vim /usr/lib/systemd/system/docker.service
#註釋14行默認的準啓動內容
#在15行添加準啓動內容
ExecStart=/usr/bin/dockerd --tlsverify --tlscacert=/tls/ca.pem --tlscert=/tls/server-cert.pem --tlskey=/tls/server-key.pem -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock
#--tls 加密通訊。指定/tls目錄下的證書。指定使用tcp訪問方式,對外開啓端口2376(使用unix通訊文件)
----->wq
- 重載參數/進程、重啓服務
[root@master tls]# systemctl daemon-reload
[root@master tls]# systemctl restart docker
- 將 /tls中的ca.pem、cert.pem、key.pem 推送到客戶端/etc/docker目錄下
[root@master tls]# scp ca.pem [email protected]:/etc/docker/
The authenticity of host '192.168.226.133 (192.168.226.133)' can't be established.
ECDSA key fingerprint is SHA256:aSyVuV+25pwNT0PVyk530AC+5Age6Mm3zx2EEXFKdmU.
ECDSA key fingerprint is MD5:5a:d1:49:cb:73:aa:a1:0e:be:41:0c:02:0c:91:30:a0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.226.133' (ECDSA) to the list of known hosts.
[email protected]'s password:
ca.pem 100% 1765 1.3MB/s 00:00
[root@master tls]# scp cert.pem [email protected]:/etc/docker/
[email protected]'s password:
cert.pem 100% 1696 1.3MB/s 00:00
[root@master tls]# scp key.pem [email protected]:/etc/docker/
[email protected]'s password:
key.pem 100% 3243 2.6MB/s 00:00
#客戶端查看推送的文件
[root@client docker]# ls
ca.pem cert.pem daemon.json key.json key.pem
7.2.2 驗證
- ① 服務端關閉核心防護、清空防火牆規則
- 客戶端關閉核心防護
#服務端
[root@master tls]# setenforce 0
[root@master tls]# iptables -F
#客戶端
[root@client docker]# setenforce 0
- ② 在服務端隨意下載一個鏡像文件
[root@master tls]# docker pull tomcat
[root@master tls]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
tomcat latest 927899a31456 32 hours ago 647MB
- ③ 本地驗證(master服務器)
#在服務端以TCP訪問的形式查詢鏡像列表
[root@master tls]# docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H tcp://master:2376 images
REPOSITORY TAG IMAGE ID CREATED SIZE
tomcat latest 927899a31456 32 hours ago 647MB
-
參數詳解
–tlsverify :TLS 證書
–tlscacert=ca.pem:CA官方頒發的ca證書
–tlscert=cert.pem:客戶端證書
–tlskey=key.pem:客戶端密鑰證書
-H tcp://master:2376 images:使用tcp 通訊方式查詢鏡像列表
-
④ 客戶端驗證
將master地址添加到hosts
[root@client docker]# vim /etc/hosts
192.168.226.132 master
#添加以上信息
- 在客戶端進行驗證,以Tcp訪問的方式查看master服務端的鏡像列表(與上一個本地驗證命令相同)
- 使用此方式查詢,前提是 當前路徑中的文件必須包含ca.pam證書,否則會報錯
[root@client docker]# docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H tcp://master:2376 images
REPOSITORY TAG IMAGE ID CREATED SIZE
tomcat latest 927899a31456 32 hours ago 647MB
八、檢查docker模板
- 2016 年的 8 月 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
# Add your checks in below
總結
-
配置思路:
① 在服務端創建ca官方的ca密鑰和ca證書
② 設置服務端私鑰:確保安全加密
③ 服務端私鑰簽名:確保身份真實不可抵賴
④ 製作證書
⑤ 客戶端:
- 生成客戶端密鑰
- 密鑰簽名
- 創建配置文件
- 簽名證書
- 配置docker.service
- 重載進程、重啓docker
-
⑥ 在服務端將證書推送到客戶端
-
⑦ 最後在客戶端,包含ca.pem文件的目錄中使用tcp 通訊訪問查詢服務端信息