Create default passwords when dev mode is set. #441#442
Create default passwords when dev mode is set. #441#442cmoulliard merged 43 commits intocnoe-io:mainfrom
Conversation
cmoulliard
commented
Nov 8, 2024
- Add new parameter to enable/disable: dev mode
- Set the default password for gitea
- [Feature] Have a --dev parameter able to configure gitea and argocd with default: username/password #441
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
…a new password. cnoe-io#441 Signed-off-by: cmoulliard <cmoulliard@redhat.com>
|
Question: Is it the best place to add the code able to generate a new password (= developer) when devMode is enabled - ? @nabuskey |
|
Yeah after install() comes back with no errors. |
… - developer. Create a kubeClient part of the k8s util package. cnoe-io#441 Signed-off-by: cmoulliard <cmoulliard@redhat.com>
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
This comment was marked as resolved.
This comment was marked as resolved.
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
|
If what I did cannot work, we have 2 options:
|
|
I am still not sure if the flag name is what we want to go with. Is proving static password the only thing needed for dev mode? Does it describe what it does? If we add more config changes for dev mode in the future, do we want to provide ways to control each change? If the names I proposed in the issue are too long, can we get away with a short flag? I do like the idea of having a static default passwords for sure. |
If we continue to develop idpbuilder, having a devMode help a lot as we do for quarkus |
Let's review that later when we have a PR which is working as |
I will make a try to see if that works |
This comment was marked as resolved.
This comment was marked as resolved.
I was able to play with a user RBAC ConfigMap As the following secret is created on the flight by argocd when Argocd Secret |
…veloper's password. cnoe-io#441 Signed-off-by: cmoulliard <cmoulliard@redhat.com>
|
The PR supports now to log on to the UI of Argocd using (developer/developer) with RBAC Can you please review it ? |
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
…oper Signed-off-by: cmoulliard <cmoulliard@redhat.com>
|
Apparently we cannot use for gitea I will then revert to the user |
… fails Signed-off-by: cmoulliard <cmoulliard@redhat.com>
…for argocd Signed-off-by: cmoulliard <cmoulliard@redhat.com>
nabuskey
left a comment
There was a problem hiding this comment.
If you are having problems setting passwords on install, we can change them through APIs after install.
| namespace: argocd | ||
| data: | ||
| policy.csv: | | ||
| p, role:developer, applications, *, *, allow |
There was a problem hiding this comment.
What's the purpose of having a separate account that has a very similar permissions as admin?
There was a problem hiding this comment.
This is an account for the developers and it only allows to handle applications
There was a problem hiding this comment.
Can you tell me if this is inline with what you are thinking?
- Use a random password for the developer and admin account if the dev password flag is unset.
- Use a static, known password for the developer and admin account if the dev password flag is set.
There was a problem hiding this comment.
Option 2 => Use a known password for the developer and admin account if the dev password flag is set
There was a problem hiding this comment.
Ok that sounds good to me. Looks like Gitea static password isn't working for some reason?
There was a problem hiding this comment.
Ok that sounds good to me. Looks like Gitea static password isn't working for some reason?
For gitea when using dev-mode, we should still use as user: giteaAdmin and password = developer
There was a problem hiding this comment.
Since you are adding a user called developer to argocd, we may as well add the developer user in Gitea.
pkg/controllers/localbuild/argo.go
Outdated
| return ctrl.Result{}, fmt.Errorf("Error marshalling patch data: %w", err) | ||
| } | ||
|
|
||
| kubeClient, err := k8s.GetKubeClient() |
There was a problem hiding this comment.
The reconciler has client already. You can just use that instead. e.g. r.Client.. You can also change passwords through ArgoCD api.
There was a problem hiding this comment.
You can also change passwords through ArgoCD api.
That will require to be done in a 2nd step while here the idea is to have the account developer/developer available when packages are installed too
There was a problem hiding this comment.
You can also change passwords through ArgoCD api.
That will require to be done in a 2nd step while here the idea is to have the account developer/developer available when packages are installed too
Yeah I am starting to think we should set them through API for both Gitea and ArgoCD in every invocation of idpbuilder. Instead of relying on manifests.
There was a problem hiding this comment.
We should then (maybe) create some job(s) which are applied post installation of the core package like gitea or argocd and able to execute some additional steps based on parameters passed.
Until now, the first action could be to create a new user: developer able to log on using as user/pwd => developer/developer or idpbuilder/developer if the parameter passed is --dev-mode.
A second job could also patch existing resources if by example we pass a different DNS domain = --host
etc
There was a problem hiding this comment.
flag renamed from "dev" to "dev-mode". See: a8c3016
pkg/controllers/localbuild/argo.go
Outdated
| err = kubeClient.Get(ctx, client.ObjectKey{Name: argocdAdminSecretName, Namespace: argocdNamespace}, &s) | ||
| if err != nil { | ||
| return ctrl.Result{}, fmt.Errorf("getting argocd secret: %w", err) | ||
| } | ||
|
|
||
| // Patching the argocd-secret with the user's hashed password | ||
| err = kubeClient.Patch(ctx, &s, client.RawPatch(types.StrategicMergePatchType, patchBytes)) | ||
| if err != nil { | ||
| return ctrl.Result{}, fmt.Errorf("Error patching the Secret: %w", err) | ||
| } |
There was a problem hiding this comment.
You can use server side apply instead here to simplify this process.
There was a problem hiding this comment.
Ok. I will review
There was a problem hiding this comment.
What do you mean by "server side" ? My code is similar to what we do here with the Gitea -
...There was a problem hiding this comment.
The way it's done in Gitea is server side apply. If you look further up, you'll see it's working with unstructured object to avoid having ownership of fields we do not care about. Sometimes we see errors like "object has been updated and version doesn't match". Server side apply avoids that.
This talks about it: https://eng.d2iq.com/blog/conflict-resolution-kubernetes-server-side-apply/
Here's where unstructured object is used:
idpbuilder/pkg/controllers/localbuild/gitea.go
Lines 163 to 166 in f31a08e
Here's another example:
Lines 78 to 86 in d14289a
pkg/controllers/localbuild/argo.go
Outdated
| argocdDevModePassword = "developer" | ||
| argocdAdminSecretName = "argocd-secret" | ||
| argocdInitialAdminSecretName = "argocd-initial-admin-secret" | ||
| argocdInitialAdminPasswordKey = "argocd-initial-admin-secret" | ||
| argocdNamespace = "argocd" |
There was a problem hiding this comment.
These are already defined in other packages I think. Either export them or move them to globals or APIs
There was a problem hiding this comment.
Ok. I will review
There was a problem hiding this comment.
I removed 2 non used constants and others are non declared in another go file or package. See: 78e1e40
pkg/cmd/create/root.go
Outdated
| const ( | ||
| recreateClusterUsage = "Delete cluster first if it already exists." | ||
| buildNameUsage = "Name for build (Prefix for kind cluster name, pod names, etc)." | ||
| devModeUsage = "When enabled, the platform will run the core packages with developer password." |
There was a problem hiding this comment.
- I am just not sold on the name
dev mode. idpbuilder is primary used for development and testing purposes already. I think we should use more explicit name with a short flag. - Even if we accept dev mode, we shouldn't limit the flag name to just passwords. dev mode could mean a lot of different things. This should be a meta flag.
There was a problem hiding this comment.
- idpbuilder is primary used for development and testing purposes already. I think we should use more explicit name with a short flag.
If this is the case, then we should install gitea and argocd using a non generated password ;-)
There was a problem hiding this comment.
2. Even if we accept dev mode, we shouldn't limit the flag name to just passwords. dev mode could mean a lot of different things. This should be a meta flag.
What about using the the parameter: --devPwd or --devPassword as boolean @nabuskey
There was a problem hiding this comment.
I am ok with dev-pwd or dev-password since we use snake case for our flags. We can also have --dev-mode flag that is essentially a convenient flag that enables dev passwords and any other QOL stuff for dev purposes.
There was a problem hiding this comment.
Finally we aligned our paths => I will then use --dev-mode
There was a problem hiding this comment.
To be clear, I meant to have two flags. (--dev-password OR --dev-pwd ) AND --dev-mode because we could enable other QOL features under --dev-mode other than static passwords.
There was a problem hiding this comment.
To be fair is the --dev- prefix needed? I would imagine we could just have a --static-creds parameter or --static-credentials to set the password statically rather then dynamically? Unless there's a reason why we feel --dev- prefix is valuable?
The only argument I could maybe gather is that since it is no longer than admin credentials and it is developer credentials that --dev- prefix gives clarity to that but I think a good description here could explain that.
There was a problem hiding this comment.
--dev-mode is a pretty common parameter used by many developer's tools and CLI which could also be used to support different additional features in the future. On the opposite --static-creds or --static-credentials parameters are probably too restrictive, don't help the users as they have no idea about what static word means
There was a problem hiding this comment.
To be clear, I meant to have two flags. (
--dev-passwordOR--dev-pwd) AND--dev-modebecause we could enable other QOL features under--dev-modeother than static passwords.
I still think this needs to be the case.
pkg/k8s/util.go
Outdated
| ) | ||
|
|
||
| var ( | ||
| setupLog = ctrl.Log.WithName("k8s") |
There was a problem hiding this comment.
I would rather not produce log messages in utility functions. Let's wrap the error instead. e.g. fmt.Errorf("Error creating kubernetes client: %w"
…orf() Signed-off-by: cmoulliard <cmoulliard@redhat.com>
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
…ion(s) Signed-off-by: cmoulliard <cmoulliard@redhat.com>
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
…gocd Signed-off-by: cmoulliard <cmoulliard@redhat.com>
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
…ssword which is only used internally Signed-off-by: cmoulliard <cmoulliard@redhat.com>
nabuskey
left a comment
There was a problem hiding this comment.
It's fine to have the dev-mode and dev-password flags. It needs to be represented with clear intent internally in code. The flag names are user friendly but it isn't really descriptive of what it does when referring to the option internally.
When we think about the name dev-password or dev-mode, it's not clear what that means internally. Does dev-password mean we are relaxing password rules? e.g. no special char requirements. Does dev-mode mean we disable TLS?
What we want is to set a static password for all core packages. So we should make this intent clear in code.
pkg/build/build.go
Outdated
|
|
||
| type Build struct { | ||
| name string | ||
| devMode bool |
There was a problem hiding this comment.
This is still set as devMode
pkg/cmd/create/root.go
Outdated
| CreateCmd.PersistentFlags().StringVar(&buildName, "build-name", "localdev", buildNameUsage) | ||
| CreateCmd.PersistentFlags().MarkDeprecated("build-name", "use --name instead.") | ||
| CreateCmd.PersistentFlags().StringVar(&buildName, "name", "localdev", buildNameUsage) | ||
| CreateCmd.PersistentFlags().BoolVar(&devMode, "dev-mode", false, devModeUsage) |
There was a problem hiding this comment.
add another flag here with the name dev-password.
There was a problem hiding this comment.
ok but then what will be the purpose of the flag dev-mode if now we have 2 flags: dev-mode and dev-password ? @nabuskey
There was a problem hiding this comment.
Removed devMode from build.go as non used: 1cd1773
| } | ||
|
|
||
| if r.Config.StaticPassword { | ||
| creds.password = "developer" |
There was a problem hiding this comment.
We use the string developer in different places. We should define it somewhere and reference it from everywhere it's used.
pkg/controllers/localbuild/argo.go
Outdated
| return ctrl.Result{}, nil | ||
| } | ||
|
|
||
| func (r *LocalbuildReconciler) ArgocdInitialAdminSecretObject() corev1.Secret { |
There was a problem hiding this comment.
This needs to be moved to utils.
| return nil, "succeeded" | ||
| } | ||
|
|
||
| func (r *LocalbuildReconciler) updateArgocdDevPassword(ctx context.Context, adminPassword string) (error, string) { |
There was a problem hiding this comment.
Change the signature to (ctx context.Context, adminPassword string) error. If it tails for some reason, return an error. If there's an error while updating the password, we should not continue.
| return nil, "succeeded" | ||
| } | ||
|
|
||
| func (r *LocalbuildReconciler) updateArgocdDevPassword(ctx context.Context, adminPassword string) (error, string) { |
There was a problem hiding this comment.
Change the name to updateArgocdPassword. The word dev doesn't mean much internally.
| return string(sec.Data["password"]), nil | ||
| } | ||
|
|
||
| func (r *LocalbuildReconciler) updateGiteaDevPassword(ctx context.Context, adminPassword string) (error, string) { |
There was a problem hiding this comment.
| func (r *LocalbuildReconciler) updateGiteaDevPassword(ctx context.Context, adminPassword string) (error, string) { | |
| func (r *LocalbuildReconciler) updateGiteaPassword(ctx context.Context, adminPassword string) error { |
| // Gitea admin secret is not yet available ... | ||
| return ctrl.Result{RequeueAfter: defaultRequeueTime}, nil | ||
| } | ||
| logger.Info("Gitea admin secret found ...") |
There was a problem hiding this comment.
Let's make this a debug message. It's not useful for normal operations.
| } | ||
|
|
||
| if r.Config.StaticPassword { | ||
| logger.V(1).Info("Dev mode is enabled") |
There was a problem hiding this comment.
| logger.V(1).Info("Dev mode is enabled") | |
| logger.V(1).Info("static passwords enabled") |
pkg/util/argocd.go
Outdated
| ) | ||
|
|
||
| const ( | ||
| ArgocdDevModePassword = "developer" |
There was a problem hiding this comment.
| ArgocdDevModePassword = "developer" | |
| ArgocdStaticPassword = "developer" |
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
…ile of the util package Signed-off-by: cmoulliard <cmoulliard@redhat.com>
…e of the functions using it. Convert some messages to log debug messages Signed-off-by: cmoulliard <cmoulliard@redhat.com>
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
|
/e2e |
|
E2E is failing but it's unrelated to changes. We need to make issues for:
|
I agree. I will create 2 separate issues to improve the testing coverage and documentation |
Signed-off-by: cmoulliard <cmoulliard@redhat.com>
|
/e2e |
|
e2e succeeded. I propose to merge it then |