withnale commented 3 years ago

Summary

It would be good to be able to specify a namespace to the synchronization fields to allow the synchronization limits within the configmap to be shared across namespaces. We'd like to segregate workflows across multiple namespaces but work from the same limits. I'm aware of the global limit on argo-workflow itself but we are also going to have different types of jobs, so whilst that might help initially, we'll still hit that limit.

Use Cases

So using an sample in the argo-workflow docs, this might be the optional additional namespace field:

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: synchronization-wf-level-
spec:
  entrypoint: whalesay
  synchronization:
    semaphore:
      configMapKeyRef:
        name: my-config
        namespace: default
        key: workflow
  templates:
  - name: whalesay
    container:
      image: docker/whalesay:latest
      command: [cowsay]
      args: ["hello world"]

alexec commented 3 years ago

Interesting. Note - I think this may break the security model.

hamza3202 commented 2 years ago

I have a clusterWorkflowTemplate that is used by workflows in various namespaces. This clusterWorkflowTemplate wants to use semaphores but it isn't able to do it because it then needs the configmap in all of those namespaces.

@alexec Could we consider a feature that clusterWorkflowTemplates always look for configmap in the main argo workflow namespace?

agilgur5 commented 1 month ago

I think this may break the security model.

If you have Argo installed at the cluster-level, it will have access to read all ConfigMaps from all namespaces. Since the Controller accesses Semaphore ConfigMaps and not Executor Pods, that is within its RBAC scope.

But there could be a side-channel attack or similar possible with this -- e.g. you can detect whether a ConfigMap with those keys exists in another namespace, which you normally shouldn't be able to do. So this is probably a no-go ❌ from a security perspective.

Could we consider a feature that clusterWorkflowTemplates always look for configmap in the main argo workflow namespace?

I don't think that would make sense. The Workflow that references a ClusterWorkflowTemplate executes in a specific namespace. Similarly that namespace should not be able to access the Argo namespace.

There are various tools in the k8s ecosystem that allow you to replicate ConfigMaps across namespaces for purposes like this:

Those align much better with k8s's security model

argoproj / argo-workflows

Allow shared synchronization across namespaces #6421

Summary

Use Cases