Automate creation of API tokens

[ONordander]

What problem are you facing?

I want to use provider-argocd for automatically adding provisioned clusters to ArgoCD.
However the provider needs the initial ArgoCD API-token to communicate with ArgoCD, I want to automate as much as possible, so I also want to automate the token creation and it should ultimately be stored in a Secret that the ProviderConfig can use.

How could Crossplane help solve your problem?

Make it possible to automate creation of API tokens to be used by the ProviderConfig.

[janwillies]

Hey Otto, thanks for opening this!

Currently provider-argocd needs a dedicated account at argocd (with scope: apiKey) and a corresponding account token (currently not very clear from the api docs, but stated in the readme).

If I understand correctly you are looking to automate the following initial account token creation for the user provider-argocd:

ARGOCD_ADMIN_SECRET=$(kubectl view-secret argocd-initial-admin-secret -n argocd -q)
ARGOCD_ADMIN_TOKEN=$(curl -s -X POST -k -H "Content-Type: application/json" --data '{"username":"admin","password":"'$ARGOCD_ADMIN_SECRET'"}' https://localhost:8443/api/v1/session | jq -r .token)
ARGOCD_TOKEN=$(curl -s -X POST -k -H "Authorization: Bearer $ARGOCD_ADMIN_TOKEN" -H "Content-Type: application/json" https://localhost:8443/api/v1/account/provider-argocd/token | jq -r .token)
kubectl create secret generic argocd-credentials -n crossplane-system --from-literal=authToken="$ARGOCD_TOKEN"

That means the starting point is the initial admin account with user/pass?

1. With the initial admin user/pass we can connect to /v1/session and get a session token.
2. With the session token we can connect to /v1/account/<name>/token and create an account token.
3. Everything else will be via this account token (like implemented today)

Did I get this right?

This probably means implementing the account API and making some changes to providerConfig so that it understands the initial admin user/pass and initiates a session based on that.

[ONordander]

Yes that sounds right to me.
I'll try to get some time to work on this and keep you posted.
For now, I'll leave it open if anyone else wants to work on this.

[github-actions]

Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 7 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.

[nabuskey]

This would be a great enhancement for this provider. My use case:

I want to spin up a local cluster with ArgoCD and Crossplane installed. Once they are available, I want to add an ArgoCD application that creates a non-local cluster through Crossplane. Once the cluster is ready and kubeconfig secret created, make the cluster one of destination clusters in ArgoCD.

It's not possible to do this without scripts right now. You either have to:

1. ArgoCD resource hook to invoke a scrip that obtains token from ArgoCD API server, then store it in a secret for this proivder to use.
2. Don't use this provider. Use ArgoCD resource hook and cron jobs to create and update the secret that ArgoCD expects.

I've opted to the second option for now but I think this is definitely something a controller should take on.

Ideally though, ArgoCD should accept kubeconfig. But it seems like it's not happening anytime soon.

@ONordander @janwillies If no one is working on this, I may be able to work on this.

[janwillies]

Hey @nabuskey,

Thanks for bringing this up again. I agree with your observation that Argo CD won't accept a plain kubeconfig anytime soon, unfortunately.
In the meantime, the next-best place would indeed be this provider. I would be very happy to review a PR for this.

[joebowbeer]

#66 provides support for kubeconfig authentication, but IIUC that is for ArgoCD to connect to the managed cluster, not for this provider to connect with ArgoCD

[github-actions]

Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 7 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.