Argo CD 權限管控解決自動化部署安全難題

在 Argo CD 管理存取權限：利用 Projects 與 RBAC 為 Dev、Test 及 Prod 環境強化安全性

## Argo CD 中的權限控管挑戰

唉，其實這個問題我一直有點頭痛。隨著你基礎設施慢慢擴大，Dev、Test 還有 Prod 這幾個環境裡面，應用程式數量一不小心就變多了——嗯，我常常會搞混自己到底加了多少服務進去。結果，新的麻煩也跟著來了：到底要怎麼分清楚誰能看、誰能動（像同步或刪掉）這些應用？這不是在開玩笑欸，萬一給錯權限，那真的慘。

有時候我會想，是不是大家都太樂觀？其實只要沒做好存取管理，任何拿到門票的人都有可能直接影響生產環境，不然就是莫名冒出一些奇怪的變更。我現在其實很怕看到 alert 跳出來。啊對啦，本篇內容就是想談談——Argo CD 裡面怎麼靠 **Projects** 加上 **角色型存取控制（RBAC）** 來讓團隊比較不會亂套，把多環境部署稍微安頓好一點。

---

如果你覺得光看文字還是不夠明白，可以順便瞄一下我的 [Github 程式碼] 或是 [YouTube 影片] 啦，有些細節懶得寫太細就在那邊補充。

## 基礎介紹：什麼是 Argo CD Projects？

說老實話，每次講到 Project 我就會想到高中分組報告，但回過神才發現自己又岔題了。總之，在 Argo CD 裡，「Project」是一種把相關應用歸類的方法，大致上可以把它當成是在不同團隊或不同環境間拉起一道界線，例如你可以依照 Dev、Test 或 Prod 各自切出專屬的 Project。

突然想到，上次忘記命名規則差點搞亂配置檔……嗯，好吧，再拉回主題。設定好的 Project 不只是分類而已，它還能限制哪些資源和目標叢集可以被操作，所以某種程度算是替每個區塊畫好範圍。不然大家一起亂插手，那場面肯定失控。不知道是不是只有我覺得這樣比較安心，大概吧。

Argo CD 裡面的專案（Projects），說真的，就是用來幫應用程式做個邏輯上的分組啦。反正，你就當它是一道無形的界線，欸我常常在想，這麼多界線最後會不會自己也搞混。嗯——不管怎樣，它確實可以幫助大家根據團隊或環境去把應用程式分一分。像是什麼 Dev、Test 跟 Prod 這些不同的環境，各自弄個專案就行了嘛。

有時候你看著那些專案，還真有種「整理抽屜」的快感，但其實背後原因也沒那麼單純啦。因為每個專案都可以設不同存取權限，所以…唉，有的人就是喜歡搞得很細緻。我也是受夠了，每次換環境就要再調整一次存取層級，可又不得不做，因為環境需求就是卡那裡。有時我甚至懷疑到底誰真的記得每個權限開到哪。

然後喔，如果你在 Argo CD 要新建一個應用程式，那可不是隨便丟在哪，它必須要被歸在某個專案下頭才行。好吧，其實這規定還算合理，不然所有東西亂成一鍋粥，誰還受得了？有時候突然想到別的事會忘記回來講重點——呃對，就是說這種強制分類，其實是在管理上蠻方便啦，不過偶爾也讓人喘不過氣。

總之（但其實沒有結論），Argo CD 的專案大概就是幫你把應用程式照環境和存取需求理出點頭緒……如果能一直記住自己放哪就好了。不知道有沒有人跟我一樣老是找不到東西？

預設情況下嘛，系統就會有個叫作 default 的專案，這名字老實說也沒什麼想像力，但反正就是它啦。然後它還直接給你全部存取權限，聽起來是不是很方便？嗯，初期測試的時候確實輕鬆很多，不過想一想，如果是在生產環境裡面——唉，有點危險喔。

因為，只要誰有了這個 default 專案的權限，他基本上可以改掉所有應用程式，連我自己都覺得不太妙。剛剛突然想到昨天那杯咖啡忘記喝完，好吧、拉回來。要讓安全性好一點，其實可以考慮幾件事：像是限制 default 專案的權限，不然真的容易出包；還有啊，可以另外建立分別針對 Dev、Test、Prod 這些不同環境的專案。

欸對了，其實大家常常忽略這種細節，大概是覺得麻煩或懶得弄。但總之，如果你能夠把不同環境分開管，再加上一開始就不要讓 default 太全能，那風險大概會少掉不少吧。

嗯，先說，這部分其實很瑣碎，腦袋有點混亂。好啦，我還是來寫正事。依據這些專案，其實就是要把應用程式分配到對應的專案裡面——啊，不知道你有沒有那種在找東西結果手上就拿著的經驗？總之，反正每個專案都該有自己的歸屬。

說到專案怎麼限制存取，有點頭疼。其實它們讓你能夠掌握：比如**允許的目標位置**，欸，就是你可以自己界定哪些 Kubernetes 叢集跟命名空間能被拿來部署某個專案下的應用程式。我剛剛差點忘了講例子，比如 Dev 專案就只能部署到名稱前綴是 `dev-` 的那些命名空間。然後咧，另外還有**資源白名單設定**這件事，就是你得指定哪些 Kubernetes 資源才可以在那個專案所屬命名空間裡新建或改動。嗯，有時候覺得規定好多，但沒辦法，這樣才能避免有人在那堆命名空間搞出一些大家根本不想看到的資源類型吧。

.- **原始碼庫限制：** 專案可以強制被綁到某個特定的 Git 原始碼庫，反正這樣設計後，也就只有這個指定倉庫變動時應用程式才會跟著同步。嗯，有時候會想，如果哪天誤連到其他倉庫怎辦啊，不過大多數情況下好像也沒人在意細節，現實裡大家都偷懶。

.- **基於角色的存取控制：** 其實也能針對專案內設定不同的角色權限，比方說，可以讓某些人只能同步，別人卻有刪除應用的權力。唉，光想到要管理這麼細碎，好累，但安全還是得做吧，大概。

## 步驟指引：透過專案強化環境安全

<pre><code class="language-html">1. **停用預設專案的權限：** 把預設專案改一改，把所有權限清空了，結果就是沒有應用程式可以再碰它啦。yaml

apiVersion: argoproj.io/v1alpha1

kind: AppProject

metadata:

  name: default

  namespace: argocd

spec:

  sourceRepos: []

  sourceNamespaces: []

  destinations: []

  namespaceResourceBlacklist:

  - group: '*'

    kind: '*'

<pre><code>

**2. 建立特定環境的專案：** 其實這個部分，我有時候都會想，為什麼每次都得搞三個專案？不過現實就是如此，你大致上還是得把 `dev`、`test` 跟 `prod` 拆開來做。每一個專案只能動自己那片命名空間跟倉庫，沒辦法偷吃步。嗯，有點煩，但也安全啦。

yaml

apiVersion: argoproj.io/v1alpha1

kind: AppProject

metadata:

  name: dev-project

  namespace: argocd

spec:

  description: "Development environment"

  sourceRepos:

    - '*'

  destinations:

    - namespace: 'dev*'

      server: https://kubernetes.default.svc

  clusterResourceWhitelist:

    - group: '*'

      kind: '*' 

欸我剛才差點忘了 test 環境也是要這樣搞——真的很容易出神，總之下面是測試環境專案：

yaml

apiVersion: argoproj.io/v1alpha1

kind: AppProject

metadata:

  name: test-project

  namespace: argocd

spec:

  description: "Testing environment"

  sourceRepos:

    - '*'

  destinations:

    - namespace: 'test*'

      server: https://kubernetes.default.svc

  clusterResourceWhitelist:

    - group: '*'

      kind: '*' 

然後正式環境嘛，就是 prod，那一套流程根本沒啥變化，只是名字不一樣罷了。有時候會懷疑自己是不是在複製貼上人生，好吧。

yaml

apiVersion: argoproj.io/v1alpha1

kind: AppProject

metadata:

  name: prod-project

  namespace: argocd

spec:

  description: "Production environment"

  sourceRepos:

    - '*'

  destinations:

    - namespace: 'prod*'

      server: https://kubernetes.default.svc

  clusterResourceWhitelist:

    - group: '*'

      kind: '*' 

**指派應用程式到專案中：** 呃，其實這裡就是建立應用程式的時候記得指定對應的 project 還有命名空間就好，沒有太多花招可玩啦。

開發環境應用程式

yaml

apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

  name: springboot-dev

  namespace: argocd

spec:

  project：dev-project 

  destination：

    server：https://kubernetes.default.svc 

    namespace：dev-1 

  syncPolicy：

    automated：

      prune：true 

      selfHeal：true 

    syncOptions：

      - CreateNamespace=true 

  sources：

   - repoURL：https://github.com/devops4solutions/deploy-argocd-app.git 

     targetRevision：main 

     ref：values  

yaml

# 第二個來源就比較妙，是 Git 倉庫裡面的 Helm chart（啊突然想到昨天還有人問 Helm 到底怎麼寫…），反正你看下面就懂。

   - repoURL：https://devops4solutions.github.io/springboot-helm-chart/

     chart：springboot 

     targetRevision：0.1.5 

     helm：

        valueFiles：

          - $values/deploy/dev/values.yaml   

# PostSync Hook 範例（可視情況啟用）
# - repoURL：https://github.com/devops4solutions/deploy-argocd-app.git
# targetRevision：main
# path：deploy/dev/post-sync
有些人會問「test 跟 prod 要不要再寫一次？」唉，就是照搬啦，不要偷懶。今天腦袋糊掉了一半，不小心打太多廢話，拉回主線。同樣的方法可以搞定 test 和 prod 環境的 application 配置。

## 在 Argo CD 中建立與管理本地使用者

剛剛已經把那些專案都建好了嘛，像是 `dev`、`test` 跟 `prod`，然後也順手把應用程式分別塞進去了。嗯，有時候真想放空，不過還是得繼續講。之前一直就只靠那個預設的 `admin` 帳號在搞，其實有點懶，可是總不能一直都這麼混下去吧？現在輪到要新增幾個**單獨的使用者**，順便幫每個人規定一下他們可以摸到哪些內容。

Argo CD 其實預設就是只有一個那種 `admin` 的帳號而已，說真的蠻陽春的——常常讓我有「怎麼會這樣」的吐槽慾。不過，如果你想再加上更多不同的人來管權限，那就必須動用**`argocd-rbac-cm` 還有 `argocd-cm`**這兩份 config map 才行。不知道為什麼每次設定 config map 時腦袋總會恍神，大概是因為名字太像了吧，但反正拉回來，你要控管存取權限，就是得從這裡下手。

（其實剛才差點忘記提醒自己不要跳出主題，不然又開始碎念 config map 的命名學了…好啦。）簡單說——確保你的管理需求都扔進上面那兩份 config map 裏頭，仔細寫清楚誰能看什麼誰該被擋掉，要不等系統一亂起來可沒人會替你擦屁股呀。唉，看著文件發愣，也只能慢慢修吧。

說到 Argo CD 嘛，關於怎麼管理那些使用者還有角色，其實……唉，這東西有時候真的讓人頭大。不過不管怎樣，Argo CD 的確是支援本地使用者的設定啦，如果你懶得搞什麼外部認證系統（像 SSO 之類的），其實直接用本地帳號也沒什麼大不了。嗯，不過我常常忘記密碼欸，每次重設都超煩。

然後啊，你如果選擇用本地使用者，就可以做不少事情，比如建立一個新的帳號，給它指定某個特定的角色——這種感覺就像在玩分配職位那樣，有點權力下放的味道。還有就是，你可以直接給那個人設定密碼，或者乾脆生成 API 金鑰，不知道為什麼，我每次想到金鑰就會想起上次丟失 U 盾的糗事。咳，好像離題了。

再拉回來說，除了這些基本操作之外，其實你還能細緻一點——比如在全域層級或者專案層級去定義存取權限。每次要調整權限的時候我都會卡很久，但據說只要搞懂規則其實蠻容易的，只是我老是把全域和專案搞混。總之啦，不論你是偏好哪種方式，該有的彈性 Argo CD 基本上都有提供，好吧，就先講到這邊吧。

## 步驟 1：啟用本地使用者
先說，這個流程其實蠻容易搞混的，尤其你如果昨天沒睡飽的話更糟。嗯，總之，要設置本地使用者，你得去編輯那個 `argocd-cm` 的 ConfigMap，在 `accounts` 那一區加進新用戶。咦，我突然想到上次 YAML 排版縮排又弄錯，搞得我重來兩次，好累。拉回來——格式就跟下面這樣：

yaml

apiVersion: v1

kind: ConfigMap

metadata:

  name: argocd-cm

  namespace: argocd

  labels:

    app.kubernetes.io/name: argocd-cm

    app.kubernetes.io/part-of: argocd

data:

  # 新增一位具有 apiKey 和 login 能力的本地使用者

  #   apiKey - 可產生 API 金鑰

  #   login - 可透過 UI 登入

  accounts.developer: apiKey, login

  accounts.devops: apiKey, login

  accounts.tester: apiKey, login

# 停用某個使用者。預設情況下，使用者會是啟用狀態。

其實有時候想直接把誰關掉省事，但註解要記得拿掉，不然無效。

#ßadmin.enabled: "false"

---

## 步驟 2：為使用者設定密碼
唉，每次設定密碼都懶得打，但偏偏還是得做。方法就是用 Argo CD CLI 給帳號設密碼，一開始要先拿到 admin 現有的密碼喔，不然等等卡住就想砸鍵盤了。

shell

argocd admin initial-password -n argocd

argocd account update-password \

  --account developer \

  --current-password "xxxxxxxxxxxx" \

  --new-password developer123



（對，密碼自己改成你家狗狗名字也行啦。）

---

## 步驟3：為所有使用者分配角色
欸，其實大家最常問就是權限怎麼分。初期嘛，大多建議都讓人先走唯讀，不然改壞很麻煩。我之前遇過 tester 不小心按到什麼東西，一堆服務全炸開…不提了，好吧。我們會給 devops 用戶最高權限，可以看全部專案、管理操作；developer 就只能動 dev-project，而且只准執行同步操作，不給他其他特權。

yaml

apiVersion: v1

kind: ConfigMap

metadata:

  name: argocd-rbac-cm

  namespace: argocd

  labels:

    app.kubernetes.io/name: argocd-rbac-cm

    app.kubernetes.io/part-of: argocd

data:

  policy.csv: |

    g, devops, role:admin 

    p, developer, applications, sync, dev-project/*, allow 

  policy.default: role:readonly # 若有未在 policy.csv 中明確定義政策的登入帳號，將被賦予 readonly 的角色。

---

## 結論
講到這邊，其實 Argo CD 那套 Projects 跟 RBAC 還算彈性滿滿，只是文件真的是越看越暈，有時候還會忘記我剛剛在哪一段。不過大致上，就是根據團隊需求，把應用程式照邏輯分組、加上適合的基於角色限制，就能協同合作，比較不用怕誰一不小心手滑亂改。唉，有時候真的希望大家都不要亂點啊…大概就醬吧。

嗯，怎麼說呢，這種方式讓 Argo CD 在那種有很多團隊、各自還分著好幾個環境的大型企業裡，聽起來就特別合適。你也知道，有時候權限一亂，就什麼都亂了。唉，我突然想到前幾天有人又把測試環境搞壞——欸，不對，扯遠了。拉回來。

重點是它可以幫你很細緻地控管不同角色的操作權限，所以，即使有人手癢想多動點什麼，也比較不會出什麼岔子，大概吧。而且啊，這樣一來 CI/CD 流程的安全性和可靠性都能提升不少。我其實有時候覺得，太過嚴謹反而怕失誤，但考慮到企業需求，好像也只能認命了。