Allow Namespaced ArgoCD/GitOps to create Projects

[eformat]

Is your feature request related to a problem? Please describe.
Allow a Namespaced GitOps deployment to self provision projects.

The feature is straight forward in summary:

• In OpenShift we created the project/namespace duality
• The default behaviour is to allow (system authenticated) Developers to self service projects out of the box i.e. call the ProjectRequest api

Can we also allow GitOps/ArgoCD to make similar project requests?

Currently, as a Developer using GitOps/ArgoCD in Namespaced mode, you must:

(1) create additional Projects to manage (which also creates the namespaces).
(2) annotate the Namespace(s) (requires cluster admin type privilege) with "argocd.argoproj.io/managed-by=" where the value is the name of your project that contains argocd.
(3) go to "Configuration" -> "Clusters", select the "in-cluster" cluster, click "Edit" and put the namespace(s) into the "Namespaces" field. This updates the secret labelled "argocd.argoproj.io/secret-type: cluster" (or declaratively do so)

Describe the solution you'd like
As a Cluster Admin, when installing the Operator, choose whether Namespaced GitOps/ArgoCD CR's can be allowed "self-provisioner" (if this is not disabled in the cluster already).

As a Developer, when creating a Namespaced ArgoCD CR, specify the project(s) this instance can manage. The GitOps/ArgoCD Service Account would be given "self-provisioner", something like:

oc adm policy add-cluster-role-to-user self-provisioner -z argocd-argocd-application-controller

That would allow the GitOps/ArgoCD ServiceAccount to admin projects. The namespace label/annotation solution would (ideally) then not be required.

Describe alternatives you've considered
(1) Using the default cluster gitops instance to bootstrap projects. This clearly works and is a good pattern for isolating cluster admin like privileged actions.

(2) The GitOps operator could use the (privileged) "update" api to create the namespace label. One example workaround for #3819 (as described below) is here - https://github.com/apache/camel-k/pull/1311/files

(3) The similar effort in upstream ArgoCD, it creates a separate service account - "support managing cluster resources in a namespaced mode" - argoproj/argo-cd#6581

Additional context
Its a complex issue. It seems to be related to choosing the (privileged) namespace annotation as a solution for Namespaced GItOps/ArgoCD. Unfortunately unprivileged users in OpenShift have never had permission to annotate namespaces or projects. There is a 7 year old issue upstream about it - openshift/origin#3819

So, it seems unlikely that is going to change anytime soon. Having said that, Clayton's comment seemed like a pretty elegant solution ! openshift/origin#3819 (comment)

Notes
The intent here is for self-provisioner type access. even though it cannot be given to service accounts.

the self-provisioner role is associated with system:authenticated:oauth group, that is assigned to all users who have identified using an oauth token issued by the embedded oauth server.

So for service accounts you will need to create a new role .

[sbose78]

Thank you for the detailed write-up, I will read up and respond!

[eformat]

@sbose78 i have a workaround, not ideal as it does not use namespaced argo but it works like this.

you can deploy multiple cluster scoped argocd's into your cluster using this environment variable ARGOCD_CLUSTER_CONFIG_NAMESPACES which is not really documented at all in the argocd operator - only in the e2e tests.

this lets you deploy privileged argocd instances, by specifying the namespaces they can go into on the Subscription e.g.

spec:
  channel: stable
  config:
    env:
      - name: DISABLE_DEFAULT_ARGOCD_INSTANCE
        value: 'true'
      - name: ARGOCD_CLUSTER_CONFIG_NAMESPACES
        value: 'labs-ci-cd,ateam-ci-cd'
  installPlanApproval: Automatic
  name: openshift-gitops-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  startingCSV: openshift-gitops-operator.v1.3.1

the RBAC is controlled and we can set up Namespaces using the Application CR:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: welcome
spec:
  destination:
    namespace: welcome
    server: 'https://kubernetes.default.svc'
    syncOptions:
    - CreateNamespace=true

i have a working example in OpenShift 4.9+ here https://github.com/eformat/openshift-gitops the RBAC is pretty wide open for now.

[sbose78]

you can deploy multiple cluster scoped argocd's into your cluster using this environment variable ARGOCD_CLUSTER_CONFIG_NAMESPACES which is not really documented at all in the argocd operator

We don't recommend that because it gets us pretty wide permissions :(

[jannfis]

I do not think this feature is viable. A namespace scoped instance is that: namespace scoped. Letting it create additional namespaces that it can itself scope into defeats the purpose, somehow.

I guess one proper way to have "self-serve" namespaces would be to have a cluster-scoped administrative instance (managed by the cluster admin team), with an Application that manages namespaces on the cluster. Let people send Pull Requests for the Git repository sourced by that Application to have their namespaces created.

I'm gonna close this enhancement request, because I do not believe that we'll implement it anytime soon.

[eformat]

thanks @jannfis for considering. i dont think it defeats the purpose - consider that a namespace admin RBAC user can today create other projects and namespace without issue. the "self-provisioner" role is not namespace scoped if you look at it that way - its a cluster type role.