RFD - Ways to Limit Argo Workflows Permissions - Mounting Volumes [Draft]

[Adam-D-Lewis]

Status	Draft 🚧
Author(s)	Adam-D-Lewis
Date Created	03-31-2023
Date Last updated	03-31-2023
Decision deadline	?

In Argo Workflows users with permissions to use Argo Workflows can mount any other users home directory. This is not acceptable. I discuss some options to limit this behavior. Some options include:

1. Use a Kubernetes operator to limit what subpaths can be mounted by particular pods (or put users in their own namespaces then limit which subPaths can be mounted in that namespace with a CRD and an Operator)
   • The Problem with this is that we could only kill the Workflow after it's created, potentially allowing for something bad to happen in the meantime. (Delete all users files, etc.)
2. Limit users to running particular Argo Workflow templates
   • This prevents users from using hera, argo CLI, create workflows with multiple steps, etc.
   • https://argoproj.github.io/argo-workflows/workflow-restrictions/
3. Argo Workflows has plugins which could allow us to crash any workflows with wrong volumes mounted.
   • We'd have to use this with restricting users to use templates which has the same disadvantages as above.
4. Create Nebargo, a fastapi server that all users submit workflows to. It examines the workflow to see if the user is mounting volumes they shouldn't and forwards the request to argo-server or not accordingly.
   • this limits what tools you can use - no hera, no argo CLI :(
5. AdmissionController
   • Write an AdmissionController that rejects Workflows that try to mount Volumes they shouldn't
   • The AdmissionController will be a fastapi server that has access to look up a user's groups from keycloak. It can then validate only volumes the user has permission to access are included.
   • The AdmissionController gets the name of the user who submitted the Workflow from the workflows.argoproj.io/creator=452fcf19-d3ca-4813-a250-2b2e1bb7bd9d tag on the workflow (keycloak user ID).
   • Links
     1. https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
     2. https://docs.giantswarm.io/advanced/custom-admission-controller/ (this is the best link)
     3. https://github.com/open-policy-agent/gatekeeper
6. Pod Security Admission/Pod Security Standards
   1. https://kubernetes.io/docs/concepts/security/pod-security-policy/
   2. Might work, but I'm not sure it's flexible enough
7. Limit users to their own namespace
   • Because PVs are cluster wide, I don't think this would help with preventing users from mounting volumes to pods that they shouldn't.

I think the AdmissionController is the best way forward at the moment.

[Adam-D-Lewis]

I put some rough work in progress on an admission controller in https://github.com/nebari-dev/argowf-admission-controller repo that nebari maintainers can access if needed.