RBAC 功能可以限制對 Argo CD 資源的存取。Argo CD 本身設計沒有使用者管理系統，只有一個內建的 admin 超級使用者。另外 RBAC 需要搭配 SSO 或是地端使用者設定，這樣才能使得使用者綁定到 RBAC 角色。可以定義 RBAC 配置的兩個主要組件：
當使用這被 Argo CD 通過身分驗證時將被賦予 policy.default 中指定的角色。對於匿名存取即無須被驗證，對於是否可匿名存取可針對參數 users.anonymous.enabled 進行設定。當然 policy.default 絕對不是最佳實踐，而是要而外設計角色並附加於 policy.default 上。
Argo CD 有兩個預先定義的角色
role:readonly 對所有資源的存取權限是唯讀role:admin- 不受限制存取所有資源而 RBAC 配置允許定義角色(role)、群組(group)和 Policy。
group 允許將經過身份驗證的使用者或群組指派給內部角色結構:
g, <user/group>, <role>
<user/group> 被指派角色的實體。可以是本機的使用這或是 SSO 進行身分驗證的使用者。
<role> 實體被指派的內部角色。
結構:
p, <role/user/group>, <resource>, <action>, <object>, <effect>
<role/user/group> 指派權限至某個實體<resource> 要操作的資源類型<action> 對資源執行的操作<object> 表示資源的標識符，格式依資源類型而定<effect> 決定是否允許或拒絕對目標物件的存取，值為 allow 或 deny
下表總結了所有可能的資源以及對每個資源有效的操作。
| Resource Action | get | create | update | delete | sync | action | override | invoke |
|---|---|---|---|---|---|---|---|---|
| applications | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ |
| applicationsets | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| clusters | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| projects | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| repositories | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| accounts | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| certificates | ✅ | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ |
| gpgkeys | ✅ | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ |
| logs | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| exec | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| extensions | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ |
先以官方的範例來看
p, example-user, applications, delete/*/Pod/*, default/prod-app, allow
p, example-user, applications, update/*, default/prod-app, allow
p, example-user, applications, delete, default/prod-app, deny
p, example-user, applications, delete/*/Pod/*, default/prod-app, allow
p, my-local-user, applications, sync, my-project/*, allow
g, my-local-user, role:admin
<action> 欄位可以是 <action>/<group>/<kind>/<ns>/<name> 的設計。
前面的實驗有建置過下面的資源，接下來會基於此資源進行相關的 RBAC 設定。
# /developer/team-a/project/project.yaml
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a-project
namespace: argo
# Finalizer that ensures that project is not deleted until it is not referenced by any application
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
description: Project for team-a
sourceRepos:
- https://github.com/CCH0124/K8s-with-quarkus.git
destinations:
- namespace: team-a
name: stage-cluster
- namespace: team-a
name: k3d-dev-cluster
clusterResourceWhitelist:
- group: ''
kind: Namespace
namespaceResourceWhitelist:
- group: 'apps'
kind: Deployment
- group: 'apps'
kind: ReplicaSet
- group: '*'
kind: ServiceAccount
- group: '*'
kind: Service
- group: '*'
kind: Pod
- group: 'batch'
kind: Job
permitOnlyProjectScopedClusters: false
以下也許是地端使用者整合的場景
對於建置的帳號，該帳號可能有兩種類型的權限
apiKey 允許產生用於存取 API 的令牌login 允許從 UI 登入建立使用者帳號格式為 accounts.<username>: <capabilities>。
現在假設有 dev、pm 和 op 三種角色，每個角色都有自己對應的權限。
視為開發者，對於 team-a-project 下的 Application 資源可以進行任何操作，對於 AppProject、repositories 和 clusters 只有讀的權限，而 applicationsets 將被拒絕任何操作。
視為專案管理者，對任何訊應當都為讀取權限，像是 applications、projects 和 repositories。而 clusters 和 applicationsets 將被拒絕任何操作。
視為維運者，其權限相比 dev 或 pm 來的大因此權限基本上都放行像是 exec 和 accounts 等資源。
Argo CD 使用 Helm Chart 佈署，因此可以如下進行 User 和 RBAC 設定部分。
configs:
cm:
...
exec.enabled: true
admin.enabled: true
exec.shells: "bash,sh"
accounts.devuser: login
accounts.pmuser: login
accounts.opsuser: login
accounts.devuser1: login
accounts.devuser1.enabled: "false"
rbac:
create: true
policy.default: role:readonly
policy.csv: |
p, role:dev, applications, *, team-a-project/*, allow
p, role:dev, projects, get, team-a-project, allow
p, role:dev, repositories, get, *, allow
p, role:dev, clusters, get, *, allow
g, devuser, role:dev
p, role:pm, applications, get, */*, allow
p, role:pm, projects, get, *, allow
p, role:pm, repositories, get, *, allow
p, role:pm, clusters, get, *, allow
g, pmuser, role:pm
p, role:op, applications, *, */*, allow
p, role:op, projects, *, *, allow
p, role:op, repositories, *, *, allow
p, role:op, clusters, *, *, allow
p, role:op, accounts, *, *, allow
p, role:op, certificates, *, *, allow
p, role:op, gpgkeys, *, *, allow
p, role:op, exec, create, */*, allow
g, opsuser, role:op
比較特別的配置是 exec.enabled 預設是關閉，其用於可以針對 Pod 資源進行遠端連線操作。這邊將設定為 true 且只有 opuser 能夠操做。
基本上在 configs.cm 下透過 accounts.<username>: <capabilities> 格式設定使用者帳號後 Argo CD 會建置帳號，如下透過 argocd account list 可以列出當前有的使用者帳號。
$ argocd account list
NAME ENABLED CAPABILITIES
admin true login
devuser true login
devuser1 false login
opsuser true login
pmuser true login
這些建置的帳號預設沒有密碼，也無法正常登入因此藉由以下指令格式給予密碼。
argocd account update-password --account <new-username> --new-password <new-password>
如果是令牌，可以使用以下格式
argocd account generate-token --account <username>
devuser1 是無法被登入可以想像是離開專案的開發者，因此其登入帳號被進行控管。
accounts.devuser1: login
accounts.devuser1.enabled: "false"
從平台進行登入時理當會看到此訊息 Account devuser1 is disabled。
使用 CLI 方式使用 devuser 登入
argocd login argo.cch.com:8443 --grpc-web-root-path argocd --username devuser
對於 devuser1 其權限如下
p, role:dev, applications, *, team-a-project/*, allow
p, role:dev, projects, get, team-a-project, allow
p, role:dev, repositories, get, *, allow
p, role:dev, clusters, get, *, allow
g, devuser, role:dev
對於 team-a-project AppProject 資源下的 Application 資源都可以進行操作但被限制於 team-a-project 下；但對於 projects、repositories、clusters 都只能獲取，不能夠新增或更新。這邊對於應用程式佈署我們限制於 team-a-project 同時只有 dev/stage 叢集能佈署，只要是其它叢集都會被拒絕。而 exec 此功能也是被拒絕，因此在平台上是無法進行遠端操作。
使用 devuser 嘗試對 opuser 管理的 sre-project 資源下進行 sync 操作，會出現 PermissionDenied 訊息。
$ argocd app sync argo/sre-app
FATA[0000] rpc error: code = PermissionDenied desc = permission denied: applications, sync, sre-project/sre-app, sub: devuser, iat: 2024-08-11T04:49:48Z
同理對 repositories 進行新增時也會有權限問題。
$ argocd repo add --name app https://github.com/CCH0124/K8s-with-quarkus.git --type git --project default
FATA[0000] rpc error: code = PermissionDenied desc = permission denied: repositories, create, default/https://github.com/CCH0124/K8s-with-quarkus.git, sub: devuser, iat: 2024-08-11T04:49:48Z
但對 team-a-project 下的 simple-app Application 資源執行 sync 是放行，在權限設計上是允許。
$ argocd app sync argo/simple-app
當然最快驗證可以使用 can-i 方式類似於 Kubernetes kubectl auth can-i。
$ argocd account can-i sync applications 'team-a-project/*'
yes
$ argocd account can-i sync applications 'sre-project/*'
no
$ argocd account can-i delete applications 'sre-project/*'
no
$ argocd account can-i delete clusters '*'
no
$ argocd account can-i get clusters '*'
yes
$ argocd account can-i get exec 'team-a-project/*'
no
$ argocd account can-i create exec 'sre-project/*'
no
$ argocd account can-i create exec 'team-a-project/*'
no
pmuser 部分讀者可以嘗試驗證看看，對於 pmuser 可以讀取資源，但基本沒權限建立像是 AppProject、repositories、clusters 等資源。
接著針對 opsuser 進行驗證。
登出 devuser 並使用 opsuser 登入。
argocd logout argo.cch.com:8443 --grpc-web-root-path argocd
argocd login argo.cch.com:8443 --grpc-web-root-path argocd --username opsuser
對於 opsuser 可以對 account 資源進行變更密碼等操作；exec 可以對資源進行遠端，剩下資源也可以進行刪除、建立或更新等操作。
$ argocd account can-i sync applications 'team-a-project/*'
yes
$ argocd account can-i sync applications 'sre-project/*'
yes
$ argocd account can-i delete applications 'team-a-project/*'
yes
$ argocd account can-i create clusters '*'
yes
$ argocd account update-password --account pmuser --new-password a1234567890
*** Enter password of currently logged in user (opsuser):
Password updated
$ argocd account can-i create exec 'team-a-project/*'
yes
$ argocd account can-i create exec 'sre-project/*'
yes
Argo CD 可以讓登入功能串接第三方 SSO 平台或是對於簡單團隊可以使用地端簡易配置 RBAC 方式進行使用者管理。對於本篇分享是對於地端配置進行簡易的設計，並理解 Argo CD 平台 RBAC 的結構以及可以如何進行細粒度上的資源控管。對於第三方 SSO 平台整合會相較於地端管理方式前期配置較複雜，這部分可以參考官方使用者管理。
Argo CD 本身也可以針對登入失敗的政策進行配置像是，這些設定都是正向且是有好的配置
最後可以從本篇文章知道如何使用 can-i 對 RBAC 進行驗證。
iThome鐵人賽
看影片追技術