Argo Workflowsのユーザー操作に必要な権限
これは何
組織でArgo Workflowsを利用するにあたって、ユーザー(のグループ)ごとに利用できる操作の種類を制御したい需要があったので、どの操作に何の権限が必要なのか調査しました。
例:Workflowを作成してもよいが削除してはならない、WorkflowTemplateの編集を許可・不許可、など
前提
"SSO RBAC"をセットアップ済みのArgo Workflow
ユーザーやユーザーグループは特定のServiceAccountに紐づけられ、Argo Workflows上ではそのServiceAccountの権限に基づいて操作が許可されます。

ここでは、Argo Workflows上での操作に対して、ServiceAccountにバインドするClusterRoleやRoleではどんな権限を許可すればいいのかを書きます。
※調べた範囲は、UIメニューでいうと上から4つ分(Workflows / Workflow Templates / Cluster Workflow Templates / Cron Workflows)

表の凡例
| resources | verbs |
|---|---|
| k8sリソース 例)pods replicasets deployments etc… |
k8s request verbs https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb |
Workflow

Submit / Resubmit

| resources | verbs |
|---|---|
| workflows | create |
cronworkflowssubmit --from cronworkflows/nameの場合 |
get |
workflowtemplatessubmit --from workflowtemplates/nameの場合 |
get |
clusterworkflowtemplatessubmit --from clusterworkflowtemplates/nameの場合 |
get |
Terminate

| resources | verbs |
|---|---|
| workflows | get / patch |
Stop

| resources | verbs |
|---|---|
| workflows | get / update / patch |
Delete

| resources | verbs |
|---|---|
| workflows | get / delete |
Retry

| resources | verbs |
|---|---|
| workflows | get / update |
| pods | delete |
Suspend

| resources | verbs |
|---|---|
| workflows | get / update |
Resume

| resources | verbs |
|---|---|
| workflows | get / update |
WorkflowTemplate

Submit

| resources | verbs |
|---|---|
| workflows | create |
| workflowtemplates | get |
Create

| resources | verbs |
|---|---|
| workflowtemplates | create |
Delete

| resources | verbs |
|---|---|
| workflowtemplates | get / delete |
Update
argoコマンドはない(UIから行うか、kubectl edit)

| resources | verbs |
|---|---|
| workflowtemplates | get / update |
ClusterWorkflowTemplate

Submit

| resources | verbs |
|---|---|
| workflows | create |
| clusterworkflowtemplates | get |
Create

| resources | verbs |
|---|---|
| clusterworkflowtemplates | create |
Delete

| resources | verbs |
|---|---|
| clusterworkflowtemplates | get / delete |
Update
argoコマンドはない(UIから行うか、kubectl edit)

| resources | verbs |
|---|---|
| clusterworkflowtemplates | get / update |
CronWorkflow

Submit

| resources | verbs |
|---|---|
| workflows | create |
| cronworkflows | get |
Create

| resources | verbs |
|---|---|
| workflowtemplates | get |
| clusterworkflowtemplates | get |
| cronworkflows | create |
Delete

| resources | verbs |
|---|---|
| cronworkflows | get / delete |
Update
argoコマンドはない(UIから行うか、kubectl edit)

| resources | verbs |
|---|---|
| workflowtemplates | get |
| clusterworkflowtemplates | get |
| cronworkflows | get / update |
Suspend

| resources | verbs |
|---|---|
| cronworkflows | patch |
Resume

| resources | verbs |
|---|---|
| cronworkflows | patch |
終わりに
まとめた後でもう一度見ると大半が「それはそうだろう」という感じですが、当初はWorkflow<=>(Cluster)WorkflowTemplate, Workflow<=>CronWorkflowの関係もよくわかっておらず何を許可すれば何ができるのか謎に包まれていたので洗い出してすっきりしました。
あまり細かく制御しようとしても管理が煩雑になるので「特定のチームに所有権のあるNamespace内ではメンバーは自由に操作できる(操作の結果も含めて所有する)」くらいでもいいのかもしれません。
また「WorkflowのStopは許可したいが、Terminateは不許可としたい」のような実現不可能なケースもあることがわかりました(Stopに必要な権限がTerminateに必要な権限を包含しているため)。
調査時 参照したもの
- https://github.com/argoproj/argo-workflows/blob/v3.2.4/server/workflow/workflow_server.go
- https://github.com/argoproj/argo-workflows/blob/v3.2.4/server/workflowtemplate/workflow_template_server.go
- https://github.com/argoproj/argo-workflows/blob/v3.2.4/server/clusterworkflowtemplate/cluster_workflow_template_server.go
- https://github.com/argoproj/argo-workflows/blob/v3.2.4/server/cronworkflow/cron_workflow_server.go
Discussion