Closed slawekww closed 1 week ago
It maybe a bit more gitops friendly to be able to manage local users without resorting to a cli tool.
I would like to have this feature too
my team's use-case: automate creation of local service accounts for certain specific tasks
+1, it would be really awesome if we can automate creation of local accounts along with setting up their passwords
You can set the password of the user in secretargocd-secrets
. Is that what you need?
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.
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
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.
Thank you. In this case, lets close this feature request.
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 asadmin
to argocd CLI and update-password. Onceadmin
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"