一千萬個為什麽

搜索

在生產中運行docker時需要考慮哪些最佳和全面的實踐?



最後,您非常喜歡Docker,您希望將具有敏感客戶數據的在線業務關鍵型生產系統遷移到Docker Swarm。有些人甚至可能已經這樣做了。另一個組織無法通過禁止以root模式運行生產流程的策略負擔得起。

什麽可能是Docker生產環境考慮的構建塊清單?一個並不需要所有這些,但所有這些都應該是重要的評估。

免責聲明:我知道有一個SE策略可以避免“大量無盡名單”,但我認為這個清單不可能很大......而且現在無止境。

那麽 - 這些建築塊是什麽?

  1. 如果尚未部署,請考慮運行具有高級功能的Linux主機系統 安全設置 - 強化內核,SELinux等。
  2. 考慮使用小型Docker基本映像,例如高山,busybox或甚至是劃傷從一個空的基礎圖像開始
  3. 使用除root以外的用戶設置
  4. 仔細評估以進一步減少授予容器的已收縮內核功能集
  5. 考慮每個容器只有一個可執行二進制文件啟動您的進程,最好是靜態鏈接
  6. 那些想破壞你的系統以獲得shell訪問權限的人可能想知道他們是否發現你的容器禁用了所有的shell。
  7. 只在可能的地方裝載只讀卷

問題:還有什麽?

轉載註明原文: 在生產中運行docker時需要考慮哪些最佳和全面的實踐?

一共有 5 個回答:

容器運行的主機

Run the docker security bench on every node that runs docker containers https://github.com/docker/docker-bench-security

在運行docker容器的節點上運行以下命令:

docker run -it --net host --pid host --cap-add audit_control \
    -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
    -v /var/lib:/var/lib \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v /usr/lib/systemd:/usr/lib/systemd \
    -v /etc:/etc --label docker_bench_security \
    docker/docker-bench-security

返回檢查列表:

[INFO] 1 - Host Configuration

[WARN] 1.1  - Ensure a separate partition for containers has been created

[NOTE] 4.2  - Ensure that containers use trusted base images

[PASS] 4.6  - Ensure HEALTHCHECK instructions have been added to the container image

從存儲庫README中引用:

Docker Bench for Security是一個可以檢查數十個腳本的腳本   關於部署Docker容器的常見最佳實踐   生產。這些測試都是自動化的,並受到 CIS   Docker社區版基準測試   V1.1.0

安全基準報告的一些問題可以通過閱讀官方碼頭安全文章並將其與問題中定義的項目符號進行比較,以下事項也很重要:

  • 通過實施ssl
  • 來保護docker守護進程套接字
  • 使用公證書和 DOCKER_CONTENT_TRUST 變量的內容信任

Docker圖片本身

另外一個選擇是使用 Clair

Clair是一個靜態分析的開源項目   應用程序容器中的漏洞(目前包括appc   和碼頭工)。     

Clair定期從一組配置的源中獲取漏洞元數據並將其存儲在數據庫中。

     

客戶使用Clair API來索引他們的容器圖像;這會創建圖像中存在的功能列表並將其存儲在圖像中   數據庫中。

     客戶使用Clair API來查詢數據庫中特定圖像的漏洞;關聯漏洞和   功能是為每個請求完成的,避免了重新掃描圖像的需要。     

在發生漏洞元數據更新時,可以發送通知來警告發生更改的系統。

     

我們的目標是讓安全性更透明化   基於容器的基礎設施。因此,這個項目被命名為Clair   在法國術語之後,這個術語表達清晰,明亮,透明。

Docker仍在開發中。

與其他所有軟件發生錯誤的情況一樣,可能會添加不安全的功能,可能會導致安全漏洞的體系結構缺陷。不要低估這一點!你的系統今天可能是完全安全的,但是從下周開始補丁會有人發現一個bug,編寫一個漏洞利用程序,並且突然你的系統是開放的。

除非你必須,否則不要更新到最新版本。改為使用最新的經過充分測試的版本。

Docker不是虛擬化

如果有人從Docker容器中逃脫出來,那麽攻擊者會立即在真機上運行。沒有像虛擬化這樣可以防止違規的第二門。

像任何其他程序一樣對待Docker容器。以最低的用戶權限運行,阻止所有不需要的網絡流量,如果性能允許,虛擬化整個Docker主機。

Docker無法保護

無論Docker容器中運行的代碼是在沒有Docker問題的情況下運行。任何攻擊者都可以簡單地在容器中安裝他的軟件,Docker會像其他代碼一樣運行。

除了您在問題中提到的內容,請考慮使用度量標準和警報來獲取有關Docker映像是否正在做出奇怪事情的通知。是否突然出現CPU持續高峰?程序是否突然掃描網絡端口?有可疑的磁盤訪問?如果發生任何情況,您應該會收到通知。有很多工具可用來衡量這些事情,你應該使用它們。

除了這個主題中的要點之外,以下是我的建議:

  • Get control over Docker PID1 with dumb-init
  • Do not run docker in production without a container orchestration system
    • Take your pick from Kubernetes, Mesos, Swarm etc.
  • Use gosu for user control inside a docker image
  • Follow the 12 factor app paradigm, if you are running stateful apps in containers, change it up.
    • If you really need to run stateful apps (mysql, zookeeper, elasticsearch) in containers, leverage orchestrator paradigms like Kubernetes Statefulsets
  • Do robust secret/config management with tools like hashicorp vault/consul
  • Ship the same container built by the devs to prod through a CI pipeline that takes it through staging, integration-tests thoroughly.
  • Create notifications around CVEs and patches, trigger builds on patch-notify
  • Have extensive logging to get insight into the running container, you do not want to give the devs SSH access to either the host or the containers
    • recommendation: fluentd
  • Have both container and host metrics
    • recommendation: prometheus+node-exporter

如果您使用 sed 命令填充docker入口點,請考慮以下做法:

  • 使用諸如 confd 之類的工具管理您的docker images配置文件並保持更新
  • LI>

Confd will read data from many supported key-value stores and render configuration templates dynamically.