Send user's groups to the pod when a workflow is created from workflow template via UI

[piby180]

Hi,

When a user creates a workflow from workflow template from Argo UI, we want to get current logged in user's groups so that we can validate if the user is allowed to run the script.

We also want to ensure that this label can't be overrriden.

There was some work on protecting reserved labels here but it was not finished since last 3 years,
#7222

Is this something that can be achieved in the near future or is there any alternative way to do user validation?

[agilgur5]

We also want to ensure that this label can't be overrriden.

There was some work on protecting reserved labels here but it was not finished since last 3 years, #7222

A label can always be overridden by a user with sufficient permissions in k8s, so I'm not sure that #7222 is the right approach or that #7215's ask is even possible. It's definitely not the right approach, permission-wise.

we want to get current logged in user's groups so that we can validate if the user is allowed to run the script.

Is this something that can be achieved in the near future or is there any alternative way to do user validation?

You can use SSO RBAC for this: only grant an SA with the appropriate permissions to users who are part of the groups. SAs are part of the k8s RBAC model and so are a more appropriate approach.

[piby180]

@agilgur5 Thanks for your comment.

1. We are already using SSO RBAC. We use AWS Cognito for Argo UI authentication,
2. We have three groups on Cognito (let's say group1, group2, group3). We have three service accounts and the corresponding three RBAC roles on k8s. The RBAC roles are bound to these three service accounts via rolebindings. All argo resources are deployed to a single namespace.
3. When a user logs in to the UI, an appropriate group and service account is allocated to it and he can only perform the operations allowed in the corresponding rbac role. ( see screenshot below)
4. We would like to maintain a "library" of workflow templates. A user can simply select a workflow template, provide his own parameters in the UI and trigger the workflow on our cluster. This would give our users ability to run "predefined" workflows from the UI using custom parameters.
5. We want people from group1 to be able to trigger only the workflow templates which are meant for group1. So for example only people from "admin" group should be able to trigger admin level workflows. We thought if our container image can receive the user's group as input parameter, it can first validate if the user has permission to run this workflow or not.

I don't know if this is possible currently somehow.

[piby180]

I believe there's three main ways you can go about this:

1. Use resourceNames to allowlist your WorkflowTemplates in your Roles

resourceNames could be a good solution if there are only a couple of workflow templates. With a large "library" of workflow templates, it will be difficult to manage "allowed list" inside Role resource. Pattern matching using wildcards is not supported for resourceNames
kubernetes/kubernetes#93845

2. Use namespaces to divide your WorkflowTemplates and permissions -- this was recommended in kubernetes/kubernetes#56582 as opposed to making resourceNames more powerful

That would be a good solution but since we have already deployed everything related to argo in a single namespace, converting it to multi namespace setup would not be so trivial I presume.

3. Validate the SA/its token, not a label

The SAs for the workflow templates would be different from the logged in user's SA in the UI. Even if we have access to the "workflow creator"'s service account name, we can maybe use conditionals within the workflow template to allow conditional execution
https://argo-workflows.readthedocs.io/en/latest/walk-through/conditionals/

I will discuss with my colleagues and will ask again if I need additional help. Thanks for your response.

[agilgur5]

Pattern matching using wildcards is not supported for resourceNames
kubernetes/kubernetes#93845

Yes that issue was closed as a duplicate of the one I linked, kubernetes/kubernetes#56582, which suggests using namespaces to properly divide up resources instead of supporting wildcard resourceNames.
That's the suggestion from upstream k8s maintainers if you're facing limitations with plain lists with resourceNames.

With a large "library" of workflow templates, it will be difficult to manage "allowed list" inside Role resource.

Though if you're using a templating tool like Helm, you can automate this

The SAs for the workflow templates would be different from the logged in user's SA in the UI.

In the CLI at least (I'm not sure if this is available in the UI), you can submit a Workflow with your own SA.

This is making me think if having the user as an Argo variable may be a good feature. A user cannot override those, although those aren't necessarily the most secure to rely on either 🤔
E.g. if you used it as an input, someone could edit the Workflow to have a raw string with someone else's user instead of the variable. But that potentially suffices if you use templateReferencing: Secure

[piby180]

This is making me think if having the user as an Argo variable may be a good feature. A user cannot override those, although those aren't necessarily the most secure to rely on either 🤔

E.g. if you used it as an input, someone could edit the Workflow to have a raw string with someone else's user instead of the variable. But that potentially suffices if you use templateReferencing: Secure

That is exactly what I need :)
I can put something like {{user.group}} or {{user.email}} in the workflow template and Argo substitutes it with the values from logged in user.

Most of our end users are non technical business users who will just log into Argo UI and trigger and monitor workflows. They don't have kubectl and hence no argo cli access.

[agilgur5]

Most of our end users are non technical business users who will just log into Argo UI and trigger and monitor workflows. They don't have kubectl and hence no argo cli access.

For that a label could suffice, you wouldn't even need this whole feature as you wouldn't need the same level of security for users lacking much of any permissions.

I can put something like {{user.group}} or {{user.email}} in the workflow template and Argo substitutes it with the values from logged in user.

I was thinking about this and it is substantially easier said than done unfortunately.
At the very top level, the Controller is responsible for templating while the Server is responsible for SSO. They do not directly communicate with each other either, only via k8s resources. So the existing labels are one of few ways that information is communicated and it is not a secure method. The Controller otherwise has no access to SSO token data what-so-ever.
A validating webhook (combined with #12049) has some access to OIDC information, but only at the time of admission of the resource (i.e. the request object). The resource itself doesn't contain that information.

So while I like this approach, it needs a lot more thought put into it, without even getting into the potential complexity of implementation. As such I don't think it would happen any time soon.

The only method I'm thinking of right now that might partially suffice here (and would still require a boat load of implementation and maintenance) is new CR that the Server can submit, linked to a Workflow, that contains user metadata. That CR should only have write RBAC for the Server and read-only for the Controller / everywhere else. This would be similar to the approach I described in #6490 (comment).
That's still not an immutable audit log and can be overwritten with sufficient RBAC (e.g. a cluster admin or attacker manipulating the CR to make it seem like it came from someone else. Cryptographic signing can help with that to an extent, but the key may also be accessible), but it might "good enough" for many use-cases. It still does not seem ideal from a security perspective though. And it wouldn't work with kubectl access either; requires the Server to authenticate and record the user metadata. So even that idea I think still needs more elbow grease. I might see what SIG Security folks think about it as a general approach though

[piby180]

We eventually decided to use Gitlab Pipelines to create workflows. We do have gitlab username in gitlab cicd variables which we inject as a label to the workflow. We can also control exactly which user have access to trigger workflow.

So for now, we have disabled triggering workflows from argo UI and made it read only by restrictions rbac permissions for the UI.