Closed Adam-D-Lewis closed 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)
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.
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.
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: