ref: https://blog.sigstore.dev/verify-oci-container-image-signatures-in-kubernetes-33663a9ec7d8
本篇文章要探討的也是跟 security 有關的一個概念,一樣也是基於 Software Supple Chain 這個概念去探討到底環境中用到的相關軟體是否都是安全且被信任的。
本文章分享的是一個基於 Kubernetes Admission Controller 實作的解決方案 Connaisseur,該解決方案的概念很簡單
1. 透過 Admission Controller 去監聽系統上所有 Container 的部署請求
2. 如果部署的 Container Image 是符合事先設定規則的,則允予通過
3. 如果不符合,該次部署就直接失敗
所謂的規則比較簡易的說法就是簽章,只有包含了可信賴簽章的 Container Image 才會被 Connaisseur 給允許通過
有了這個基本概念之後,下一個問題則是到底什麼是可信賴簽章?以及要如何讓想要使用的 Container Image 獲得一個可信賴的簽章?
文章內介紹了關於 Container Signatures 的一些演變,包含了 Docker Content Trust, Notary(V1) 以及 The Update Framework 早期的使用方式
到後來因為 OCI(Open Container Initiative) 的發展與調整,目前可以直接於 OCI Image Spec 一同夾帶該 Image 相關的簽章。
這意味者任何支援該 OCI 標準的 Container Registry 不但可以存放該 Container Image 同時也可以存放該 Image 的簽章。
這個使用方式的變更也促使了 Notary 這個開源專案(v2)的演進。
與此同時, Linux 基金會底下的 Sigstore 專案也再努力地針對開源專案的簽章方面努力著,期望能夠透過簽署與驗證功能來提升開源專案簽署方面的應用。
Sigstore 專案底下的 Cosign 小專案則是專門處理 OCI Image 相關的簽章事項,包含簽署,儲存以及驗證。
而本文所開頭所提及的 Connaisseur 專案則是可以基於 Cosign 所簽署的內容去進行驗證,透過兩者的配合可以用來確保部署到 Kubernetes 的所有 Image 都需要被 Cosign 給簽署過
作者特別強調,目前 Sigsotre 以及 Cosign 這些專案都還是屬於開發階段,所以 Connaisseur 本身對於這項功能的整合也是屬於一個開發實驗階段,很多東西都會不穩定
隨者資安意識以及相關事件 Solarwinds hack 等的出現,當各團隊基本的 DevOps, CI/CD 文化與流程都逐漸成型後, DevSecOps 的東西就會是下一個各團隊要開始煩惱的地方了
特別是所謂的 Software Supply Chain 上的各種潛在危險。
「docker in linux」的推薦目錄:
- 關於docker in linux 在 矽谷牛的耕田筆記 Facebook 的最佳解答
- 關於docker in linux 在 矽谷牛的耕田筆記 Facebook 的精選貼文
- 關於docker in linux 在 矽谷牛的耕田筆記 Facebook 的精選貼文
- 關於docker in linux 在 Docker for Linux - GitHub 的評價
- 關於docker in linux 在 Docker on Linux - AirSim - Microsoft Open Source 的評價
- 關於docker in linux 在 Why docker has ability to run different linux distribution? [closed] 的評價
docker in linux 在 矽谷牛的耕田筆記 Facebook 的精選貼文
本篇文章是個經驗分享文,作者分享使用 Docker 作為開發環境時值得注意的 Best practices,透過這些經驗分享希望能夠讓開發者少走一些冤枉路。
原文提出了 15 個經驗談,這邊幫大家節錄幾個,有興趣的可以點選原文瞭解更多!
1. One thing at a time
2. Be ephemeral
3. Utilize .dockerignore
4. Less is more
5. Secrets should be secret
6. PID 1 is your birth right
7. Share and Care
8. Vulnerability Scan
9. Tag like you mean it
10. Permissions are costly
11. Source of Truth
12. Always official
13. Don’t include debug
14. Use entry point script smartly
15. Size does matter
One thing at a time
建置 Image 的時候專注做好一件事情,每個 Image 應該有一個專心要解決的問題,譬如一個應用程式,一個小工具等。對於 Nginx 這類型的 Image 來說,應該沒有人會期望於裡面看到有 Apache 的應用程式吧?
Be ephemeral
這個主要探討的是該 Image 本身建置時應該要以 stateless 的概念去處理,未來不論是透過 docker 或是 Kubernetes 來管理部署時,Contaienr 都很有機會被重啟,每次的重啟都意味該容器是重新啟動。所以千萬不要讓你的 Image 變成多次重啟會導致應用程式出問題的形式,任何的這類型資料應該都要透過外部取得,不要塞到你的 Image 內
Utilize .dockerignore
善用 .dockerignore 這個檔案來將不必要的檔案從 build 過程給排除,使用方法與 .gitignore 類似。透過這個檔案的設定可以避免 docker build 的時候不會把一些過大或是完全不需要的檔案都送給 docker daemon,不當浪費時間也浪費空間。
Less is more
避免安裝任何無關或是非必要的套件到你的 image 中,特別是那些 "nice to have" 的理由。
註: 我個人是滿討厭把 Image 弄得很乾淨的,除錯什麼工具都沒有,連 ash/sh/busybox/bash 都沒有的 image 更是我討厭中的排行榜冠軍
Secrets should be secret
任何機密資訊都應該要於運行期間動態載入,而不是建置期間塞入。請使用其他工具譬如 Vault 來管理這些機密資訊,並且執行期間讓 Container 能夠存取到正確的值。
PID 1 is your birth right
Linux 環境下會使用 SIGTERN, SIGKILL 等相關的 Singal 來戳你的應用程式,請確保你運行的應用程式要能夠攔截這些訊號來處理並完成有效的 Graceful shutdown.
Share and Care
如果環境中有多個 Image 彼此有共享相同的工具與功能,與其每個 Image 都單獨建置維護不如建置一個 Base Image,接者讓所有要使用的 image 去載入使用即可。
透過這種方式可以讓整體的維護性與管理性更為簡單,每個 image 可以減少重複的程式碼,同時要升級時只要針對 base Image 處理即可。
https://medium.com/pradpoddar/avoid-costly-mistakes-using-advanced-docker-development-best-practices-acd812784109
docker in linux 在 矽谷牛的耕田筆記 Facebook 的精選貼文
本文是一篇 2017 年的文章,雖然已經四年之久,但是我認為本篇文章值得一讀。
作者團隊於 2017 年時正在經歷如何將 VM 上的各種 Java 應用程式轉移到 Kubernetes 內的 Container,而本篇文章則是探討到底 Container 是如何透過 Linux Control Group 以及 namespace 實作的,透過對這些底層實作的瞭解,才有辦法針對 Container 效能部分去除錯與提升。
這種文章探討的都是很底層的概念,建議所有人都閱讀一遍,好好複習關於 cgroups/namespace 的概念,透過對這些概念的理解與掌握,能夠更有系統的去解釋何謂Docker Container,何謂輕量級虛擬化。
以下幫大家節錄一些重點,還是推薦自行閱讀全文
1. cgroup 用來隔離與限制 CPU,Memory,Disk,Network Bandwidth 等資源的用量
2. namespace 則是用來限制 ipc, pid, mount ,network, utc 等資訊的可視性,不同 namespace 內看到的資訊是獨立的,但是最終彼此還是屬於同一個 Kernel。
3. 任何沒有被 cgroup 規範的應用程式都會被自動包含到 root cgroup 的規範,不同發行版其位置不同,譬如 /sys/fs/cgropu.
假設今天透過 docker run 去運行一個 java 應用程式
a. Docker 會創建一個 pid namespace,接者運行 Java 前先把該應用程式給掛到新的 pid namespace 上並且賦予該 java 應用程式 PID 1
註: Host 上還是可以觀察到該 Java 應用程式,因為除了 Host 本身外,每個 pid namespace 都有自己的老爸,而老爸是可以看到小孩資訊的,這意味 docker dameon 雖然創建新的 pid namespace,但是host的pid namespace 實際是新 namespace 的老爸
b. 從老爸的視角來看,可以看到該 Java 應用程式也會有一個不同的 PID,而這個 PID 也會於 cgroup 系統中有自己的設定
4. CPU Cgroup 則是會用 share 為單位來定義每個 task 可以獲得多少相對的 CPU 時間,相對的算法是去計算 task 擁有的 share 數量佔了整個 cgroup 階層元件中的多少百分比。
舉例: 捨去其他服務單純考慮運行三個 Container 且有 4 Core CPU 的環境,三個 Container Task 分別給予 2048,1024,1024 share 的話,第一個 Container 大致是會被分配到兩個 CPU Time
5. CPU shares 沒有辦法去保證每個 task 最小用量是多少,所以需要透過 CPU Quotas 的概念來設定 CPU.cfs_quota_us(假設使用 CFS 這個排成演算法)以及 CPU.cfs_period_us(預設100ms)。
概念大概就是 cfs_period_us 定義的時間內,你最小可以使用多少時間,所以假如設定 cfs_quota_us 為 100ms,則預設情況下該 process 可以使用的量就是 100ms/100ms = 1 ~= 1 Core CPU
k8s 與上述的相關bug 可參考下列 issue
https://github.com/kubernetes/kubernetes/issues/67577
6. JVM 看到的是系統上全部的 CPU 資源,但是 Contaienr 本身當被限制 CPU 用量時,會有資訊落差,造成 GC 運行的效果不如預期,因為其認為系統有超多 CPU,而不知道自己其實被限制的CPU很少。
原文滿精彩的,推薦閱讀
https://engineering.squarespace.com/blog/2017/understanding-linux-container-scheduling
docker in linux 在 Docker on Linux - AirSim - Microsoft Open Source 的推薦與評價
AirSim on Docker in Linux#. We've two options for docker. You can either build an image for running airsim linux binaries, or for compiling Unreal Engine + ... ... <看更多>
docker in linux 在 Why docker has ability to run different linux distribution? [closed] 的推薦與評價
... <看更多>
docker in linux 在 Docker for Linux - GitHub 的推薦與評價
"Docker CE for Linux" is specialized packages for common Linux distributions which are free to download. Documentation. If you don't understand something about ... ... <看更多>