Docker容器明文密碼解決方案

　Docker 帶著 “Dockerize Everything” 的口號，以“軟件標準”的姿態(tài)展現(xiàn)于世人面前，不斷影響大家對于軟件的理解。然而現(xiàn)實是否就如想象中的那么飽滿，新的科技誕生之際，是摧枯拉朽之勢，還是循序漸進，皆有個過程，面對異軍突起的 Docker，軟件傳統(tǒng)的精髓又是何去何從？這些無一不是值得深思的話題。
　　在《存儲類 Docker 容器的明文密碼問題》一文中，我們初步領略了存儲類軟件與 Docker 結(jié)合時，存在的些許安全隱患，比如明文密碼問題。
　　過去數(shù)十年間，MySQL 數(shù)據(jù)庫的創(chuàng)建都在人機交互過程中完成，流程大致可以分為以下三個步驟：
　　運維人員創(chuàng)建機器，安裝并配置 MySQL 服務器；
　　DBA 負責管理 MySQL 數(shù)據(jù)庫，如 MySQL 數(shù)據(jù)庫的創(chuàng)建、刪除與權(quán)限更改等；
　　開發(fā)人員使用 DBA 交付的數(shù)據(jù)庫，對數(shù)據(jù)庫進行增刪改查等操作。
　　MySQL 歷經(jīng)了許多年，形成了以上這種交付方式，在 Docker 誕生之前，沒有任何風吹草動。然而，在 Docker 誕生之后，MySQL 的 Docker 化路程似乎并不平坦。
　　常言道，Docker 橫空出世，極大地推動了DevOps的發(fā)展。雖然看似 MySQL 與 Docker 的結(jié)合并沒有對開發(fā)造成直接的影響，但是 Docker 化的 MySQL 的確加速了運維進度，原本冗長的人機交互，以及多方協(xié)調(diào)，如今一條簡易的docker run命令即可全部完成。無可否認，自動化的程度有了質(zhì)的飛躍，然而當我們審視自動化流程時，我們也可以從中找到一些隱患——MySQL容器的明文密碼問題。
　　MySQL 容器的明文密碼問題，指的是：Docker 創(chuàng)建 MySQL 容器時，通過環(huán)境變量的方式傳遞 MySQL 存儲引擎的密碼，縱使 MySQL 會對密碼進行加密，然而環(huán)境變量的存在卻會泄漏密碼信息，因此存在安全隱患。
　　明文密碼解決方案
　　Docker 容器的明文密碼問題，在于控制流程的過于自動化，并且環(huán)境變量的方式又無可避免地使用明文記錄了密碼。在一個完整的 MySQL 容器創(chuàng)建過程中，環(huán)境變量和 MySQL 引擎密碼始終保持一致，假設我們可以做到用戶為 MySQL 設定的密碼最終可以落實到 MySQL 引擎處，而不存在于任何環(huán)境變量中，那就可以說明明文密碼可以解決。換言之，用戶為 MySQL 容器設定的密碼時，可以繞過環(huán)境變量。眾所周知，環(huán)境變量在 Docker 的世界中是配置環(huán)境最常用的方式，連完成容器間通信的docker link命令最終也是通過環(huán)境變量來完成。
　　繞過環(huán)境變量又是從何說起，首先讓我們分析下圖。
　　
　　上圖中，我們通過 Docker Daemon 創(chuàng)建了兩個 MySQL 容器，容器名分別為 MySQL1 和 MySQL2，并且兩個容器中的 MySQL 引擎的密碼分別為 mysql1 和 mysql2。創(chuàng)建容器時使用的命令分別為：
　　docker run -d -e MYSQL_ROOT_PASSWORD=daocloud --name MySQL1 mysql docker run -d -e MYSQL_ROOT_PASSWORD=docker --name MySQL2 mysql
　　假設一位用戶希望創(chuàng)建一個密碼不會泄漏的 MySQL 容器，密碼為 daocloud。為了彌合明文密碼問題，繞過環(huán)境變量，我們可以按照以下三個步驟來完成。
　　1.創(chuàng)建兩個 MySQL 容器 MySQL1 與 MySQL2，MySQL 的 root 密碼分別為 daocloud 與 docker；
　　2.待 MySQL1 啟動完畢，使用docker stop命令停止 MySQL1 容器，并將 MySQL1 容器的 volume1 全部拷貝出來，最終使用docker rm命令刪除 MySQL1 容器；
　　3.待 MySQL2 啟動完畢，使用docker stop命令停止 MySQL2 容器，并將 MySQL2 容器 volume2 內(nèi)的文件全部刪除，接著將 volume1 的內(nèi)容拷貝至 volume2 下，最終啟動 MySQL2。
　　通過以上三個步驟，我們直接交付 MySQL2 容器，此時 MySQL2 容器中 MySQL 的 root 密碼為 daocloud，即目標達成。雖然 MySQL2 容器的環(huán)境變量 MYSQLROOTPASSWORD 依舊是 docker，但是 MySQL 引擎使用的密文密碼已經(jīng)轉(zhuǎn)變?yōu)?daocloud，交付完畢的 MySQL2 容器中不存在任何有關字符串 daocloud 的明文信息，同時無需再使用的 MySQL1 容器也被我們刪除。
　　上述流程的執(zhí)行，可以很巧妙的通過替換volume的方式，完成密文的轉(zhuǎn)移，同時使得明文環(huán)境變量的失效。
　　Docker層與應用層
　　通過實踐，可以驗證解決方案的可行性。不過很多讀者看到這里，不禁會對上述方案產(chǎn)生一些質(zhì)疑，是否替換 volume 就是一個合理的解決方案。
　　以下的觀點，相信很多人會認為同樣是合理的解決方案。
　　明文密碼固然是一個大問題，然而當 MySQL 容器創(chuàng)建完畢之后，用戶完全有權(quán)限通過 mysql-client 等工具登陸 MySQL 引擎，實現(xiàn) MySQL 引擎 root 密碼的修改，最終的結(jié)果是：密碼修改同樣會作用到 volume 中的密文，使得充當明文密碼的 Docker 容器環(huán)境變量失效。
　　不可否認，上述觀點同樣具有可行性。仔細分析和對比兩種解決方案，可以看到兩者之間存在一些明顯的差異。
　　最大的差異性，當屬通用性。替換 volume的方式，雖然在容器創(chuàng)建流程中加入了部分額外的操作（比如創(chuàng)建兩個容器、啟動容器、替換 volume等），但是在通用性方面，優(yōu)勢十分明顯。通用性的體現(xiàn)何在？本文舉例的是 MySQL 容器，其實其他存儲類 Docker 容器如 MongoDB、Redis 等，均可以采用這種方式。
　　換言之，對于存儲類 Docker 容器而言，Docker Daemon 的管理員無需獲知容器內(nèi)部運行的是何種服務，機械化操作替換volume即可導致明文密碼失效。通過 mysql-client 修改密碼的方式，只能由容器的用戶來完成，而現(xiàn)實情況中， Docker Daemon 管理員與容器用戶很有可能并非同一個人，尤其是在公有云服務上。因此，Docker Daemon 交付出的容器，必須由用戶進行二次加工，才能真正滿足用戶需求，無疑在便捷性方面，無法盡如人意。
　　更為細致的比較，我們就能發(fā)現(xiàn)：其實兩者的實現(xiàn)的立足點不同。替換 volume則是從 Docker 層出發(fā)；而修改密碼則是站在應用層出發(fā)。
　　何為Docker層？Docker 是一款軟件，Docker 的世界中 Docker 鏡像、Docker 容器等，對于容器的管理（比如啟動停止、環(huán)境變量的設置等），筆者都認為是 Docker 層的概念。
　　何為應用層？此處的應用層，指的是與用戶鏡像內(nèi)或者容器內(nèi)與應用直接相關的內(nèi)容。
　　依然以 MySQL 為例，通過 MySQL 鏡像啟動 MySQL 容器時，會使用MYSQL_ROOT_PASSWORD這個環(huán)境變量。環(huán)境變量是一個 Docker 層的概念，原因很簡單，Docker Daemon 會機械化地將所有用戶設置的環(huán)境變量作用到容器進程，而不會去關心具體哪個環(huán)境變量在容器中充當什么樣的角色。同樣的道理，名為MYSQL_ROOT_PASSWORD的環(huán)境變量就是一個應用層的概念，這個具體的環(huán)境變量，有可能會被容器內(nèi)部的應用進程來使用，最終影響容器內(nèi)部的應用。
　　同樣的道理，volume 是一個 Docker 層的概念，volume 內(nèi)部的具體內(nèi)容則是應用層的概念。因此，通過 volume 來操作容器，屬于 Docker 層的操作，不會涉及任何應用層的內(nèi)容。而通過事先獲知容器內(nèi)部應用的詳細情況，再針對應用進程做出相應的行為，則屬于應用層的操作。