See parent epic for detials.

Description:

This story will allow users to create local Argo CD users via the ArgoCD CR within GitOps operator.

As discussed on Slack (https://redhat-internal.slack.com/archives/C01RQH8KQ87/p1732906140732299), to create those local Argo CD users, GitOps operator will need to create the user within the Argo CD configuration ConfigMap, and sign a JWT key with credentials, storing that in Argo CD's main Secret.

Also as discussed on Slack (https://redhat-internal.slack.com/archives/C01RQH8KQ87/p1733197275781139), we will not allow users to set their own passwords as part of this feature. We will generate a Secret token for them.

The goal of this story/epic is to make it easy for users to create their own local Argo CD users, primarily for the purpose of automation. Users are able to do this currently via other means, but this makes it easy to create users declaratively, and within the Argo CD operator ecosystem.

Brainstorming, I imagine the API might look something like this:

kind: ArgoCD
spec:
  # (...)
  localUsers:
    - name: alice
      enabled: true/false
      allowAPIKeyGeneration: true/false
      allowLogin: true/false
      tokenLifetime: # As part of the epic, Jann mentioned user should be able to set lifetime.
      autoRenewToken: true/false
	  
    - name: bob
      enabled: true
      allowAPIKeyGeneration: true
      allowLogin: false
      tokenLifetime: # As part of the epic, Jann mentioned user should be able to set lifetime.
      autoRenewToken: true
status:
  localUsers:
    - name: alice
      credentialsSecret: alice-local-user (reference to a secret containing the user's api token, we which we generated for them)
      tokenExpiration: # time at which the token expires
---
kind: Secret
metadata:
  name: alice-local-user
  ownerReferences:
    - (owned by parent ArgoCD, so we can clean it up when it's no longer needed)
data:
  apiToken: (...)

Note: When you've decided on the final API, I would suggest running it by #gitops-dev to verify it meet's everyones' needs.

Acceptance Criteria:

• Changes delivered to Argo CD operator
• Local ArgoCD users can be created and deleted by the Operator using reconciliation into argocd-cm ConfigMap
  • See Slack threads linked above, for Jann's suggestion
• When a user is created, a token is issued automatically. When the user is deleted, its token is deleted, too.
  • Tokens are generated directly within the Argo CD operator code. That is, we are NOT calling 'argocd' CLI, nor are we invoking the
• Define a new API within the ArgoCD CR, to allow users to add/remove users, and retrieve Secrets.
  • See above for example.
  • I highly recommend running the API by #gitops-dev, and Gerald and Jann, to see that it meets their needs/expectations.
• Important behaviour: if a user is added to the list, the user is created. If that user is later REMOVED from the list, they should be deleted. User should be removed even if it occured while the operator controller was offlline.
• Token lifetime can be specified by user
• As discussed in backlog refinement, a high level goal for us should be: Argo CD operator should not touch users it didn't create.
  • Owner of epic to figure out how to make sure that if there are already users defined with that name, that we don't affect them
  • Owner of epic to figure out how to make sure that, in the context of deletion, if we are trying to delete a previous user, but that user exists via some other mechanism (created outside the operator), that we don't delete/affect that.
  • Some investigation will be required as to how token lifetime works in Argo CD.

• We will NOT support the ability for users to set their own password: the only passwords we will provide will be the API tokens.
• Unit/E2E tests