argo-workflows: Viewing Archived Workflows when RBAC is Namespace Delegated - Bug?

Hi, I’m wondering if there’s a potential bug when when using namespace delegation for RBAC. I have a service account in a namespace that has permissions to view workflows in the namespace. I’m able to log in, and through a group, bind to the service account. This allows me to view workflows in the namespace.

From the logs, I see:

time="2022-04-26T20:53:26.926Z" level=info msg="selected SSO RBAC service account for user" email=<redacted> loginServiceAccount=user-default-login serviceAccount=default ssoDelegated=true ssoDelegationAllowed=true subject=<redacted>

However, when accessing archived workflows from the UI, I receive an error:

time="2022-04-26T17:54:01.366Z" level=info msg="finished unary call with code OK" grpc.code=OK grpc.method=GetInfo grpc.service=info.InfoService grpc.start_time="2022-04-26T17:54:01Z" grpc.time_ms=2.549 span.kind=server system=grpc
time="2022-04-26T17:54:01.376Z" level=warning msg="finished unary call with code PermissionDenied" error="rpc error: code = PermissionDenied desc = Permission denied, you are not allowed to list workflows in namespace \"<redacted>\". Maybe you want to specify a namespace with `listOptions.fieldSelector=metadata.namespace=your-ns`?" grpc.code=PermissionDenied grpc.method=ListArchivedWorkflows grpc.service=workflowarchive.ArchivedWorkflowService grpc.start_time="2022-04-26T17:54:01Z" grpc.time_ms=15.412 span.kind=server system=grpc

From the logs, I see:

time="2022-04-26T20:52:30.920Z" level=info msg="selected SSO RBAC service account for user" email=<redacted> loginServiceAccount=user-default-login serviceAccount=user-default-login ssoDelegated=false ssoDelegationAllowed=false subject=<redacted>

When I expected to see the same logs as regularly accessing the workflows page.

It seems like this function is returning false for archived workflows. Wondering if anyone else is seeing this/if this is a potential bug. Thanks!

_Originally posted by @BhavikaSharma in https://github.com/argoproj/argo-workflows/discussions/8497_

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 17
  • Comments: 31 (19 by maintainers)

Most upvoted comments

The current endpoints don’t container the namespace in the URL, so we cannot use GetNamespace to perform namespaced RBAC on them. The current endpoints don’t support directories. I’d like to consolidate them into a single endpoint to reduce the amount of code, the amount of bugs, the amount of security problems.

@alexec - if we mandate namespace as part of url fragment as a set of v2 endpoints, it also means we are removing the current ability to list archived workflows across namespaces:

Screen Shot 2022-12-02 at 12 07 09 PM

Therefore, to preserve this functionality, I think it is actually appropriate for namespace to be an optional query parameter to the URL.

So I propose the implementation would be @basanthjenuhb’s suggestion to enhance existing ListArchivedWorkflowsRequest with the following checks:

  • if incoming request does not have query parameter for a namespace, they are asking for workflows in all namespace. So then we check if they can have cluster scoped list workflows privileges
  • otherwise, if incoming request does have namespace query param, we can just check to see if they have workflow get privileges for that namespace.

This is no different than Kubernetes’s RBAC where it’s possible to either: (a) list all workflows in the cluster vs. (b) list workflows in a namespace.

@alexec @jessesuen @basanthjenuhb We are affected as well with our cluster-wide installation and RBAC Namespace Delegation. Could you please reopen the issue?

The current endpoints don’t container the namespace in the URL, so we cannot use GetNamespace to perform namespaced RBAC on them. The current endpoints don’t support directories. I’d like to consolidate them into a single endpoint to reduce the amount of code, the amount of bugs, the amount of security problems.

Also, generally issues are prioritized by 👍 count on the issue subject. This issue didn’t have any, probably why it got deprioritized. Would request people to add a 👍 on the issue subject at the top. This would help maintainers to prioritize.