GitOpsを利用するにおいて、メジャーとなっているArgo CD。ここではArgo CDにおける認可設定はどのように出来るのかについて記述する。
なお、本記事は Argo CD v2.2.3 時点の認可設定について記載しているため、将来における設定方法については保証しない。 また、認証方法については記述をしない。誰がどのような操作を出来るのか、といった認可についてのみの記述をする。
三行でまとめると
この三行の内容を理解している人は読まなくていい。
- argocd-rbac-cd ConfigMapでArgo CD全体に対する policy.default と policy.csvを記述する
- policy.csvでAppProjectに対する設定を記述出来るが、AppProject側の設定でRBACすることも出来る
- Argo CDのUI上からk8s resourceを操作する際には、そのApplicationを操作する権限があれば操作可能
ざっくり認可設定
Argo CDにおける認可設定は、argcd全般で利用する argocd-rbac-cm ConfigMap に記述設定と、AppProjectにおける設定が存在する。
- RBAC Configuration - Argo CD - Declarative GitOps CD for Kubernetes
argocd-rbac-cmConfigMap におけるRBAC設定方法の記述について- ここでは
policy.default及びpolicy.csvを記述する
- Projects - Argo CD - Declarative GitOps CD for Kubernetes
- AppProjectにおけるRBAC設定の記述 roles について
上記 policy.default, policy.csv, AppProject の3箇所でRBACを記述出来るが、まず初めに理解しなくてはならないこととして以下のことがある
- Allow条件については、この3箇所の OR条件 で権限が付与され、リソースが利用出来るようになる
- Deny条件については、この3箇所のいずれかにdenyがあれば、リソースが利用出来なくなる
各認可設定について
argocd-rbac-cm ConfigMap policy.default
argocd-rbac-cm ConfigMap はArgo CDの管理者が設定すべきものであり、その中でも policy.default は認証された人全員に適用される設定となる。ここで role:admin などをつけようものなら、認証出来る人は皆ありとあらゆる全ての操作がArgo CD上で可能となる。
RBAC Configuration - Argo CD - Declarative GitOps CD for Kubernetes にある通り、 role:admin と role:readonly は予めArgo CD側で用意してくれているpolicyであり、取り敢えずWRITE権限は考えずに、認証できた人は全てREADする権限を付与したいなら、ここに role:readonly を記述すれば良い。
argocd-rbac-cm ConfigMap policy.csv
上述のとおり、argocd-rbac-cm ConfigMap はArgo CDの管理者が設定すべきものであり、 policy.csv も管理者が設定すべきものである。ここには認証できた人/groupに対して、Argo CD上のどのリソースを操作出来るのかをきめ細かく全て設定することが可能である。一方で個別のApplicationへの操作権限等を付与する場合は、ここで設定するよりかは後述する AppProject roles で設定を行う方が望ましい。
built-in policyである role:readonly しかり、 policy.csv しかり、ここで記述するのはcasbinによるpolicyの定義だ。
以下のような記述をした場合には、 your-authenticated-group-id が任意のアプリケーション/クラスタ/レポジトリに対する更新権限が付与される。
p, role:some-editor, applications, update, */*, allow
p, role:some-editor, clusters, update, *, allow
p, role:other-editor, repositories, update, *, allow
g, your-authenticated-group-id, some-editor
g, your-authenticated-group-id, other-editor
ポイントとしては、applicationsの設定が */* となっている点である。ApplicationはいずれかのAppProjectに属させることが出来るのだが、仮にここを some-app-project/* とした場合には、 some-app-project というAppProjectに属するApplicationのみに対して更新が出来る状態となる。
AppProject roles
policy.csv できめ細かな設定が出来る事はわかったが、AppProjectでも同様の設定ができる。この主な違いは、 policy.csv はArgo CDの管理者が設定するものである一方で、AppProject rolesの設定は AppProject という Argo CD 上の1つのリソース定義上にRBAC設定が出来ることにある。AppProjectにはRBAC設定以外にも、どのようなk8s resourceを定義出来るのかといったことなども記述出来るが、今回は話さない。
Projects - Argo CD - Declarative GitOps CD for Kubernetes にあるように、以下のようなrolesの設定をAppProjectに記載すると、 your-authenticated-group-id は、 other-editor 経由でこのAppProjectに属するApplicationの更新権限を持つ
spec: roles: - name: blah # ここは下のpoliciesに記述される値と一致していれば何でも良い policies: - p, proj:your-app-project-name:blah, applications, update, your-app-project-name/*, allow groups: - other-editor
本節の最初に書いた通り、policy.csvと同等の設定を、AppProject単位に対して設定出来る機能となっている。
Argo CDのUI上でk8s resourcesを操作する際の認可
さて、ここまで読んだ人は、Argo CDが提供するk8s resourceに対する認可設定について完全に理解出来たはずである。一方で、Argo CDの認可を完全理解するためには、まだ考えなければならないことがある。
Argo CDでは、ApplicationのUI上で、Argo CD以外のk8s resourceを操作することが出来る。以下の画像は https://cd.apps.argoproj.io/ の例だが、Argo CDのUI上から Deployment の削除 / Restart / Logsの閲覧等が行える。この認可の仕組みはどのようになっているのか？
結論から言うと、現時点においてはApplicationの権限を持っている人は、そのApplicationに属するk8s resourceを操作することが出来る。この操作については application get や applciation action といった操作で行われ、その人がそのapplicationを操作出来る権限を持っているのかの確認が行われ、持っていた場合にはArgo CDがproxyとなり直接k8sのapiを操作することとなる。実際にArgo CDに対してapplicationのどのverbが使われているかは、Permission deniedとなった際にdeveloper toolsでapi responseを確認すると中身が見れる。
まぁ、applicationに対する権限があれば、それに属するリソースの操作がすべて出来るなんて、そんな大雑把な設定で良いのか？と思った人は以下のようなIssueをtrackするのが良さそうではある。
終わりに
Argo CDにおける認可設定について、まとまった日本語記事等があまり見受けられなかったので書いた。Argo CDできめ細かな認可設定をしたい人の助けになれば幸いである。
