[Feature Request] Add must-change-password possibility #137

New Issue

steled · 2021-04-02T16:48:32Z

steled commented

2021-04-02 16:48:32 +00:00

It would be great to have the must-change-password parameter in the values.yaml file so the password at the file is only for first startup.

Example:

values.yaml

gitea:
  admin:
    password: "defineYourTempPassword"
    must-change-password: true

It would be great to have the must-change-password parameter in the values.yaml file so the password at the file is only for first startup. Example: values.yaml ``` gitea: admin: password: "defineYourTempPassword" must-change-password: true ```

justusbunsi referenced this issue

2021-06-17 05:28:24 +00:00

Creating or changing a user's password is always done #153

justusbunsi commented

2021-06-26 09:21:37 +00:00

I got your point on this; it's not necessary to update the admin user if nothing changes.

Do you have any problems caused by always updating the account? Would be good to know.

I got your point on this; it's not necessary to update the admin user if nothing changes. Do you have any problems caused by always updating the account? Would be good to know.

justusbunsi added the

kind

question

label 2021-06-29 12:04:11 +00:00

steled commented

2021-06-29 17:29:20 +00:00

I have no problems but thought that it qould be good, for security reason, that there is a prompt that you need to change the admin password after first start bracuse it is written in plain text at the values.yaml file.

justusbunsi commented

2021-06-29 18:00:56 +00:00

You can reference an existing Kubernetes secret that stores password and username instead of inline values. https://gitea.com/gitea/helm-chart#admin-user

that there is a prompt that you need to change the admin password after first start

? So you mean passing this option to the cli when creating the admin account. Thought you meant an indicator for the chart to not run gitea admin user change-password. Although this should be skipped with that option enabled.

You can reference an existing Kubernetes secret that stores `password` and `username` instead of inline values. https://gitea.com/gitea/helm-chart#admin-user > that there is a prompt that you need to change the admin password after first start ? So you mean passing this option to the cli when creating the admin account. Thought you meant an indicator for the chart to not run `gitea admin user change-password`. Although this should be skipped with that option enabled.

justusbunsi added

and removed

labels 2021-06-29 18:01:25 +00:00

steled commented

2021-06-29 18:19:32 +00:00

The hint with the secret is correct but I'm using Terraform as IaC and the therefore the password would be in plain text in the repo too :-D but will have a look at this.

For the function I thought more about like the normal cli version: https://docs.gitea.io/en-us/command-line/#:~:text=--must-change-password%3A%20If%20provided%2C%20the%20created%20user%20will%20be%20required%20to%20choose%20a%20newer%20password%20after%20the%20initial%20login

The hint with the secret is correct but I'm using Terraform as IaC and the therefore the password would be in plain text in the repo too :-D but will have a look at this. For the function I thought more about like the normal cli version: https://docs.gitea.io/en-us/command-line/#:~:text=--must-change-password%3A%20If%20provided%2C%20the%20created%20user%20will%20be%20required%20to%20choose%20a%20newer%20password%20after%20the%20initial%20login

justusbunsi commented

2021-06-29 18:31:50 +00:00

I'm not familiar with Terraform. For other IaC solutions like Flux (for GitOps) there are ways to store the Kubernetes secret resource encrypted inside the repo and decrypt them in the cluster on creation to have them as "common" secrets.

For the function I thought more about like the normal cli version

Let me think about your idea. This could lead us to something improvements where we probably could get rid of the default password in values.yaml.?

I'm not familiar with Terraform. For other IaC solutions like Flux (for GitOps) there are ways to store the Kubernetes secret resource encrypted inside the repo and decrypt them in the cluster on creation to have them as "common" secrets. > For the function I thought more about like the normal cli version Let me think about your idea. This could lead us to something improvements where we probably could get rid of the default password in values.yaml.?

safaG commented

2021-06-29 18:38:08 +00:00

@justusbunsi @steled this was implemented with 169. We can now create secrets in kubernetes and use that secret on values.yaml file here

@justusbunsi @steled this was implemented with [169](https://gitea.com/gitea/helm-chart/issues/169). We can now create secrets in kubernetes and use that secret on values.yaml file [here](https://gitea.com/gitea/helm-chart/src/commit/0e191bfc7a2ae339b54abfd2aa9fa21843f69cb4/values.yaml#L133)

👍 1

steled commented

2021-06-29 18:45:53 +00:00

Ah, nice... I like the approach with the existingSecret.
The must-change-password: true was just an idea... Don't put to much time in this I think the existingSecret implementation is good enough.

Ah, nice... I like the approach with the `existingSecret`. The `must-change-password: true` was just an idea... Don't put to much time in this I think the `existingSecret` implementation is good enough.

👍 1

pat-s closed this issue

2023-04-01 08:35:33 +00:00

Sign in to join this conversation.

No Milestone

No Assignees

3 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/helm-chart#137