decadence

個人のメモ帳

Argo CDにおける認可設定

GitOpsを利用するにおいて、メジャーとなっているArgo CD。ここではArgo CDにおける認可設定はどのように出来るのかについて記述する。

argo-cd.readthedocs.io

なお、本記事は 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における設定が存在する。

上記 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:adminrole: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の定義だ。

casbin.org

以下のような記述をした場合には、 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の閲覧等が行える。この認可の仕組みはどのようになっているのか?

f:id:krrrr:20220123200302p:plain

結論から言うと、現時点においてはApplicationの権限を持っている人は、そのApplicationに属するk8s resourceを操作することが出来る。この操作については application get や applciation action といった操作で行われ、その人がそのapplicationを操作出来る権限を持っているのかの確認が行われ、持っていた場合にはArgo CDがproxyとなり直接k8sapiを操作することとなる。実際にArgo CDに対してapplicationのどのverbが使われているかは、Permission deniedとなった際にdeveloper toolsでapi responseを確認すると中身が見れる。

まぁ、applicationに対する権限があれば、それに属するリソースの操作がすべて出来るなんて、そんな大雑把な設定で良いのか?と思った人は以下のようなIssueをtrackするのが良さそうではある。

RBAC should include separate permissions for deleting k8s resources · Issue #3593 · argoproj/argo-cd · GitHub

終わりに

Argo CDにおける認可設定について、まとまった日本語記事等があまり見受けられなかったので書いた。Argo CDできめ細かな認可設定をしたい人の助けになれば幸いである。