本篇文章是一個入門文章,主要探討 GitOps 相關的起源與概念,同時介紹不少關於 GitOps 的工具
起源: Weaveworks 於 2017 年針對 Kubernetes 的工作環境產生了不同的部署方式,而 GitOps 這個詞也就那時開始萌芽發展
概念: 透過 Git PR 的方式來驗證與自動的部署所有與系統有關的修改。今天有任何部署的需求時,團隊要做的事情就是 1) 產生 Git PR 2)進行 Review 3) 合併 接者就是等任何修改被自動部署
Git 於整個環節中扮演者 Single Source of Truth 的角色,所有的修改都必須發生於 Git 本身,也因為是基於 Git 來使用,所以不論是 GitHub, Gitlab, Bitbucket, Gerrit 等系統都可以使用。
註: Bitbucket 還針對 GitOps 這種形式取了一個名為 BDDA 的名稱,意義為 Build-Diff-Deploy-Apply
好處:
1. 稽核性: 透過 Git 可以針對所有的修改去查閱,知道誰於什麼時間點進行什麼修改
2. 由於不需要將 Kubeconfig 等資源放到外部叢集,資安方面會比傳統外部直接Push/Apply 來得更好
3. 開發人員可以更容易地去部署應用,不需要仰賴Ops幫忙
4. ...etc
註: GitOps 並不是只能適用於 Kubernetes 本身,事實上整個系統架構都可以套用這種方式,譬如搭配 Terraform 等相關的 IaC 工具時,就可以透過 GitOps 來搭建整個系統,包含底層架構,k8s叢集以及最重要的應用程式
相關工具(文章列出滿多工具):
1. ArgoCD
2. Atlantis: Terraform PR 的自動化工具
3. Autoapply
4. CloudBees Rollout
5. FlexCD
6. Helm Operator
7. Flagger
8. Ignite
9. Faros
10. Gitkube
11. Jenkins X
12. KubeStack
13. Weave Cloud
14. Werf
15. PipeCD
https://medium.com/searce/gitops-the-next-big-thing-for-devops-and-automation-2a9597e51559
「git diff」的推薦目錄:
- 關於git diff 在 矽谷牛的耕田筆記 Facebook 的精選貼文
- 關於git diff 在 矽谷牛的耕田筆記 Facebook 的精選貼文
- 關於git diff 在 91 敏捷開發之路 Facebook 的最讚貼文
- 關於git diff 在 Git 版本控制系統- 比對檔案版本差異與標示說明 - Roya's Blog 的評價
- 關於git diff 在 Order of commit arguments in git diff - Stack Overflow 的評價
- 關於git diff 在 atom/git-diff: Diff markers in Atom's gutter - GitHub 的評價
- 關於git diff 在 git diff command usage with examples - YouTube 的評價
- 關於git diff 在 How we made diff pages three times faster | The GitHub Blog 的評價
- 關於git diff 在 How to Get GitHub-like Diff Support in Git on the Command-Line 的評價
- 關於git diff 在 顯示特定檔案或目錄的差異- git-diff - 他山教程 的評價
git diff 在 矽谷牛的耕田筆記 Facebook 的精選貼文
本篇文章探討的也是資安系列問題,而這次的目標主角則是 MAC 系統上廣為流傳的 Homebrew 系統。
結論:
作者透過觀察 Homebrew 的 Github Action 流程,成功得上傳一個會列印一行的程式碼到 iterm2 套件中,讓所有安裝的使用者都會於 Terminal 上看到一行作者客製化的訊息。
本次的漏洞是作者刻意從 Homebrew 的 Vulnerability Disclosure Program 專案中去嘗試尋找可能的問題,所有的操作都有跟官方專案的人探討過流程,並且一切的 PoC 都是單純證明該攻擊的可行性,所以有興趣研究的人請遵循一樣的想法去做,不要認真的想攻擊。
原因:
1. Homebrew 透過 Github Action 執行 CI/CD 動作
2. Homebrew 撰寫了一個自動合併 Pull Request 的 Action
3. CI 內會透過一個Ruby的 Git Diff 第三方函式庫來驗證,只要符合下列條件就可以自動合併
- Modifying only 1 file
- Not moving/creating/deleting file
- Target filepath matches \ACasks/[^/]+\.rb\Z
- Line count of deletions/additions are same
- All deletions/additions matches /\A[+-]\s*version "([^"]+)"\Z/ or - -\A[+-]\s*sha256 "[0-9a-f]{64}"\Z
- No changes to format of versions (e.g. 1.2.3 => 2.3.4)
作者一開始想要從該規則下手,找尋有沒有可能塞入惡意攻擊並且騙過系統讓其自動合併,然而這些規則看起來沒有什麼太多問題,於是作者轉往其他領域去找尋問題,其中一個想法就是到底該 Ruby 的 Git Diff 是如何實作,也許從實作下手更有辦法去欺騙這一切。
很順利的是,作者真的於該函式庫中找到問題,對於一個 Git Diff 的結果來說,該函式庫會透過 +++ "?b/(.*) 這樣的正規表達式來判別檔案路徑的資訊而並非程式修改內容,譬如下列 diff
```
diff --git a/source file path b/destination file path
index parent commit hash..current commit hash filemode
--- a/source file path
+++ b/destination file path
@@ line information @@
Details of changes (e.g.: `+asdf`,`-zxcv`)
```
作者就開始思考,如果讓程式碼可以符合 +++ "?b/(.*) 的規則,是否有辦法讓程式碼不被視為一個檔案的修改,因此就可以修改多行程式碼但是讓 CI 系統認為只有一行程式碼於是進行自動合併
作者最初的想法如下,第一行用來放惡意程式碼,第二行用來偽裝檔案路徑,經過一番嘗試後作者真的成功塞入了類似 PRINTF 的程式碼到環境中並觸發自動合併。接者各地使用者透過 brew 安裝 iterm 版本都會看到使用者塞入的程式碼。
```
++ "b/#{Arbitrary codes here}"
++ b/Casks/cask.rb
```
原文還有更多作者的思路過程,有興趣的不要錯過
原文:
https://blog.ryotak.me/post/homebrew-security-incident-en/#fn:7
測試用PR:
https://github.com/Homebrew/homebrew-cask/pull/104191
git diff 在 91 敏捷開發之路 Facebook 的最讚貼文
上次小弟在公司內部舉辦 Tech Talk 活動時,一位講者分享一個很酷頗完整的工具: #phabricator ,讓我覺得挺驚艷的。
它的功能包含了:
⑴ Pre-Commit Code Review(當然含 code diff, 類似 github code review 的功能)
⑵ 版本控管 support: Git, Mercurial, and SVN
⑶ Task Management (可以自訂 feature/ticket 的 form, 還有漂亮的 task graph)
⑷ 文件紀錄 (document wiki, support markdown)
⑸ Workboards and Sprints (電子看板, 類似 trello)
⑹ Chat Channels (提供即時通訊的功能,但官方也建議你用 slack 比較好)
⑺ Notification 設定
⑻ Command line & API (能結合更多自動化和外掛工具)
傳送門:https://www.phacility.com/phabricator/
重點:phabricator 可以自己 host, 免費使用。如果你懶得裝,也可以直接購買 Phacility Hosted 的服務($20 per user / per month)
#東森信息科技 的同事是自己裝,他們團隊有在試用,據說用起來速度還不錯。有興趣的朋友可以參考看看。
git diff 在 atom/git-diff: Diff markers in Atom's gutter - GitHub 的推薦與評價
Diff markers in Atom's gutter. Contribute to atom/git-diff development by creating an account on GitHub. ... <看更多>
git diff 在 Git 版本控制系統- 比對檔案版本差異與標示說明 - Roya's Blog 的推薦與評價
在添加指定版本的git diff 指令中,預設比對的是HEAD (這指最新commit 紀錄),但你會發現它連同uncommitted 的內容也進行了比對,我個人建議,如果你 ... ... <看更多>