allowed pass db credential through secret. #60

New Issue

2020-11-17T19:09:31Z

wener commented

2020-11-17 19:09:31 +00:00

(Migrated from gitea.com)

Using gitops, deploy must go through git, but this chart require clear credential.

During the init, can mount the external secret as env or somthing to provice extra conf for app.ini.

Using gitops, deploy must go through git, but this chart require clear credential. During the init, can mount the external secret as env or somthing to provice extra conf for app.ini.

👍 1

luhahn commented

2020-11-19 10:49:08 +00:00

(Migrated from gitea.com)

Do you want this option for the admin password only or for the database credentials as well?

viceice commented

2021-01-28 05:32:01 +00:00

(Migrated from gitea.com)

I think this should be for all passwords / secrets.

Maybe the chart can optionally use key-value pairs from an existing secret?

I think this should be for all passwords / secrets. Maybe the chart can optionally use key-value pairs from an existing secret?

Starefossen commented

2021-02-16 22:48:21 +00:00

(Migrated from gitea.com)

Injecting database credentials via secrets is a requirement if you want to use gitea with the Kubernetes PostgreSQL operator.

luhahn commented

2021-04-12 12:01:50 +00:00

(Migrated from gitea.com)

I currently have no idea how to do this properly :/

It is no problem at all to inject those secrets as env variables. However to set the database passwords we somehow need to get them into the app.ini.

First idea would be to check if secrets are available and set a placeholder in the generated app.ini and set it later in the init container via sed.

But im not really happy with this approach

I currently have no idea how to do this properly :/ It is no problem at all to inject those secrets as env variables. However to set the database passwords we somehow need to get them into the app.ini. First idea would be to check if secrets are available and set a placeholder in the generated app.ini and set it later in the init container via sed. But im not really happy with this approach

rema commented

2021-04-22 10:36:18 +00:00

(Migrated from gitea.com)

I am also interested in providing secrets to gitea using environment variables instead of setting them in plain format in app.ini. I did a bit of research and found out, since gitea image v1.14.1, there is the possibility to override everything in app.ini by passing ENVs by following the pattern "GITEA__SECTION_NAME__KEY_NAME". You can read more about this feature Managing Deployments With Environment Variables

So if I understand it correctly, we just need to extend the {{Values.statefulset.env}} to support not only simple "value" but also a "valueFrom" object. e.g:
...
env:
- name: GITEA_ADMIN_PASSWORD
valueFrom:
secretKeyRef:
name: nameOfSecret
key: password

Thanks

I am also interested in providing secrets to gitea using environment variables instead of setting them in plain format in app.ini. I did a bit of research and found out, since gitea image v1.14.1, there is the possibility to override everything in app.ini by passing ENVs by following the pattern "GITEA__SECTION_NAME__KEY_NAME". You can read more about this feature [Managing Deployments With Environment Variables](https://docs.gitea.io/en-us/install-with-docker/#managing-deployments-with-environment-variables) So if I understand it correctly, we just need to extend the {{Values.statefulset.env}} to support not only simple "value" but also a "valueFrom" object. e.g: ... env: - name: GITEA_ADMIN_PASSWORD valueFrom: secretKeyRef: name: nameOfSecret key: password Thanks

🎉 1

luhahn commented

2021-04-23 10:57:56 +00:00

(Migrated from gitea.com)

will check this, thanks for the hint :)

luhahn commented

2021-04-29 09:19:13 +00:00

(Migrated from gitea.com)

merged with #148

wener commented

2021-08-01 17:13:09 +00:00

(Migrated from gitea.com)

@luhahn still don't get how can I pass db conf by secret, there is no gitea.database.existingSecret like admin

wener commented

2021-08-01 17:15:32 +00:00

(Migrated from gitea.com)

ok, 1.14 support from env. like

- GITEA__database__DB_TYPE=mysql
- GITEA__database__HOST=db:3306
- GITEA__database__NAME=gitea
- GITEA__database__USER=gitea
- GITEA__database__PASSWD=gitea

ok, 1.14 support from env. like ```yaml - GITEA__database__DB_TYPE=mysql - GITEA__database__HOST=db:3306 - GITEA__database__NAME=gitea - GITEA__database__USER=gitea - GITEA__database__PASSWD=gitea ```

rounakdatta commented

2024-09-25 08:38:21 +00:00

(Migrated from gitea.com)

Just in case anyone comes across this, here's a snippet how you can do this:

gitea:
  additionalConfigFromEnvs:
    - name: GITEA__DATABASE__PASSWD
      valueFrom:
        secretKeyRef:
          name: postgresdb-password
          key: password
    - name: GITEA__database__USER
      value: 'mario'

This is possible as this block is inserted as-is.

Just in case anyone comes across this, here's a snippet how you can do this: ``` gitea: additionalConfigFromEnvs: - name: GITEA__DATABASE__PASSWD valueFrom: secretKeyRef: name: postgresdb-password key: password - name: GITEA__database__USER value: 'mario' ``` This is possible as [this](https://gitea.com/gitea/helm-chart/src/branch/main/templates/gitea/deployment.yaml#L112) block is inserted as-is.

❤️ 1

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: lunny/helm-chart#60