nebari-dev / nebari-workflow-controller

A WIP kubernetes admission controller to control what workflows can be deployed by which users
BSD 3-Clause "New" or "Revised" License
0 stars 2 forks source link

Resubmitted Workflow that was originally submitted by Kubectl #11

Closed Adam-D-Lewis closed 1 year ago

Adam-D-Lewis commented 1 year ago

I'm hitting a problem where when a user resubmits (Argo UI) a workflow that was originally started by kubectl apply -f workflow_file.yaml, I don't know whether or not the volumeMounts are okay b/c I don't know who originally submitted the kubectl workflow b/c the userInfo only comes as part of the ValidationRequest, but not part of the workflow. So I can see who submitted the resubmission request, but not who originally submitted the kubectl applied workflow.

There are a few possible ways to deal with this:

  1. Disallow any workflows that are submitted or resubmitted based on a workflow that was originally submitted via kubectl.
  2. Only verify workflows that are submitted by service accounts used by nebari argo users (argo-view, argo-edit, argo-admin). (Allow all kubectl workflows)
  3. Add my own label or annotation to kubectl submitted argo workflows to preserve the userInfo in the workflow yaml.
Adam-D-Lewis commented 1 year ago

I lean towards option 2 since I feel like nebari-workflow-controller's purpose is to prevent nebari users from mounting volumes in Argo Workflows improperly. Nebari doesn't give users the credentials to submit resources via kubectl. Nebari admins have them since they are needed to deploy Nebari so submitting workflows via kubectl feels like activity outside of Nebari and something nebari-workflow-controller doesn't need to validate. Option 2 has less chance of interfering with other ways Argo Workflows might be used (e.g. Nebari admin adds on some service which also uses Argo Workflows)

Adam-D-Lewis commented 1 year ago

Actually, I think the allowed volume mounts should just be based on who is trying to run the resubmitted workflow, not the original workflow. However, this is not possible for resubmitted workflows b/c they don't have the creator label. They do have creator email and preferred username label, but you can't always go back to the actual username b/c "Labels only contain [-_.0-9a-zA-Z], so any other characters will be turned into -)" so not a 1 to 1 mapping. I think it's best not to support resubmitting workflows then.

Adam-D-Lewis commented 1 year ago

What about Cron workflow submitted by Kubectl? In that case we should only verify workflows that were originally submitted by Nebari Argo users. We can't know who submitted it b/c the creator label won't be there. Do we just assume it's fine? Okay, I'm just not going to support Kubectl submitting things for now.