fix(argo-workflows): Add access to be able to see pod information

[yorickdevries]

According to https://argo-workflows.readthedocs.io/en/latest/security/#ui-access UI users need access to pod(logs) to be properly displayed and updated in the argo workflows UI.
In this PR I added these to the view / edit / admin aggregate roles:

Replaces PR here: #3191

- apiGroups:
    - ""
  resources:
    - events
    - pods
    - pods/log
  verbs:
    - get
    - list
    - watch

Checklist:

• I have bumped the chart version according to versioning
• I have updated the documentation according to documentation
• I have updated the chart changelog with all the changes that come with this pull request according to changelog.
• Any new values are backwards compatible and/or have sensible default.
• I have signed off all my commits as required by DCO.
• My build is green (troubleshooting builds).

[tico24]

I'll repeat my comment from #3191

I have concerns with this.

Upstream does not include these permissions in their aggregate-to-* roles/clusterroles. So this should be addressed upstream first.

I asked around the Workflows team and these roles are intended for kubectl users. So someone who is admin at kubectl can admin the argo workflows CRs, view can see them etc. They aren't intended to be used directly, more in an aggregated-to role. So they are certainly not intended to be directly used by the argo server. https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles. To hammer this home, a kubectl user with view access to the cluster, should already be able to view pod logs independently of this aggregation rbac.

This is hopefully emphasised by the fact that these aggregated roles are in the controller directory, not the server one.

However, the argo server should be using the argo-server role/cluster role, which does already have these permissions anyway, so this PR shouldn't be required.

[yorickdevries]

@tico24 Thanks for the clarification. From the helm charts it wasn't clear where these aggregate roles were meant for. I am using the -view role for the service account associated with people logging in via SSO. These users can then view the workflows without being able to edit them. However, a live feed from the pods isn't available now as this access is not part of the aggregate roles. In this PR I therefore added this access on top of the argo-workflow resource access.
Is there another existing role I can use instead for the service account associated with people logging in via SSO? See also https://argo-workflows.readthedocs.io/en/latest/security/#ui-access .

[tico24]

I actually don't know... which is a bit embarrassing.

There doesn't seem to be anything in the codebase. The implication appears to be that you are supposed to roll your own. Hopefully one of the other helm team members knows.

[yorickdevries]

@tico24 Ok, I'd gladly hear whether they know more how to tackle this SSO role. And if nothing exists yet is it something that could be added to the helm chart?

[tico24]

Potentially but I think you'd struggle to make it nicely templatable.

Unrelated, but I have hopefully helped to clarify why aggregateRoles exist in this PR: #3193

[vladlosev]

I agree with @tico24 - these roles are not intended to be used that way. Their purpose is to have their permissions to be aggregated into the view, edit, and admin roles, respectively.

You should create a specific role for the SSO principal and give it the permissions required to see and change the workflows to the degree your users require. Here is a suggested set of permissions:

rules:
- apiGroups:
  - ""
  resources:
  - pods
  - pods/log
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - delete
- apiGroups:
  - argoproj.io
  resources:
  - workflows
  verbs:
  - create
  - get
  - list
  - watch
  - update
  - patch
  - delete
- apiGroups:
  - argoproj.io
  resources:
  - cronworkflows
  - workfloweventbindings
  - workflowtemplates
  verbs:
  - get
  - list
  - watch

You using the {{ template "argo-workflows.fullname" . }}-view role to access the cluster objects in a read-only mode is a non-standard approach, and it creates its own challenges. The chart shouldn't be adjusted in order to solve every particular use case. If you insist on using the -view role, you can add another cluster role with the specific permissions you lack and create either a role binding or a cluster role binding to bind that role to the service account you use for the SSO login.