argoproj / argo-cd

Declarative Continuous Deployment for Kubernetes
https://argo-cd.readthedocs.io
Apache License 2.0
17.8k stars 5.43k forks source link

Create secrets with password for local users #15923

Closed slawekww closed 1 week ago

slawekww commented 1 year ago

Summary

ArgoCD supports local users even if SSO is enabled and it is great. Once admin user wants to be disabled and replaced by another user, it is not possible to retrieve initial password for custom user. The only option is to login as admin to argocd CLI and update-password. Once admin user is disabled, it is not possible to do it.

Motivation

Once admin user is replaced with another user, it should be possible to retrieve its password from secret like it is for admin user. It would improve security of ArgoCD, do not expose admin user and use custom admin user.

Proposal

Create secret like argocd-initial-${user}-secret with initial password. It could be optionally as parameter to account like: accounts.alice.secret: "true"

trexx commented 11 months ago

It maybe a bit more gitops friendly to be able to manage local users without resorting to a cli tool.

elouanKeryell-Even commented 10 months ago

I would like to have this feature too

my team's use-case: automate creation of local service accounts for certain specific tasks

talha-naeem1 commented 10 months ago

+1, it would be really awesome if we can automate creation of local accounts along with setting up their passwords

awx-fuyuanchu commented 7 months ago

You can set the password of the user in secretargocd-secrets. Is that what you need?

slawekww commented 7 months ago

I want to have it automated by adding accounts.alice.secret: "true" to config instead of modify k8s secret argocd-secret. Could modification of k8s secret argocd-secret be managed by argoCD itself?

Please note that goal is to replace default user admin with different name.

theblop commented 3 months ago

the oidc.config parameter in the argo-cm configmap actually allows specifying a custom secret name and key for the OIDC client secret in the form of $<SECRET_NAME>:<KEY>: https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/#alternative for example:

oidc.config:
  clientSecret: $another-secret:oidc.auth0.clientSecret

As a bonus, the argocd server still runs if the secret is missing, and it automatically loads it as soon as it's created (we use this feature to setup the argocd OIDC authentication when argocd bootstrap the cluster after it has installed the external-secrets operator and the secret has been synced from hashicorp vault)

It would be great if that could also be supported for local user accounts like this:

# example with a global `local-users-secrets` secret with a password key per user:
accounts.alice.secret: $local-users-secrets:alice-password

# or another example with separate secrets per user:
accounts.bob.secret: $user-bob-secret:password

Since there is some code already to support this for oidc.config, maybe it wouldn't be too hard to implement for local user accounts?

Or maybe it would be better to allow specifing a secret that would contain all the local users/passwords (and argo-server should still run if the secret is missing and reload it dynamically, to allow bootstrapping with argo itself), for example:

# argo-cm:
accounts_secret: user-accounts

# user-accounts secret:
stringData:
  alice: apiKey
  alice.password: foobar
crenshaw-dev commented 3 months ago

My understanding of the use cases:

I think the former is a bad idea and the latter is possible today.

Using Argo CD to generate the initial password and store it means Argo stores the password as plaintext. It's safer/better to generate the password in your own tool, save it in a password manager, store the hash with Argo, and discard your plaintext copy. If Argo CD generates the plaintext password, Argo CD can't discard it because it doesn't know when you've safely stored it elsewhere.

Disabling the admin account is possible, because you can grant a new account permissions to update passwords:

p, admin-with-a-different-name, accounts, update, *, allow

Argo CD isn't a password manager, and it shouldn't be used as such. Whenever possible, Argo should store a hash instead of a plaintext password.

slawekww commented 1 week ago

Thank you. In this case, lets close this feature request.