do not save sensitive data within the gitea configmap #17

New Issue

2020-08-31T16:02:29Z

Jasper-Ben commented

2020-08-31 16:02:29 +00:00

(Migrated from gitea.com)

Currently, the configmap used to configure gitea contains the postgresql/mysql password.

To fix this, I propose one of the following solutions:

If(?) environment variables within the app.ini are interpreted, the easiest solution would be to mount the already existing postgresql/mysql secret into an environment variable.
Otherwise, creating an init container to replace a placeholder in the app.ini using the secret is also a valid option.

Currently, the configmap used to configure gitea contains the postgresql/mysql password. To fix this, I propose one of the following solutions: 1. If(?) environment variables within the `app.ini` are interpreted, the easiest solution would be to mount the already existing postgresql/mysql secret into an environment variable. 2. Otherwise, creating an init container to replace a placeholder in the app.ini using the secret is also a valid option.

techknowlogick commented

2020-08-31 16:48:45 +00:00

(Migrated from gitea.com)

FWIW some secrets (INTERNAL_TOKEN is one) can be read from a reference on disk, so k8s secrets could be used for those and the app.ini wouldn't need any secrets to be stored in plain text in them.

FWIW some secrets (`INTERNAL_TOKEN` is one) can be read from a reference on disk, so k8s secrets could be used for those and the app.ini wouldn't need any secrets to be stored in plain text in them.

paradon commented

2020-08-31 21:51:57 +00:00

(Migrated from gitea.com)

I had a PR against the old repo for this chart (https://github.com/k8s-land/gitea-chart/pull/22) that put all sensitive data into Secrets, but it was never merged.

Unfortunately it looks like it may need a fair bit of work now since the massive changes of PR #7, and it'll likely be a few weeks before I have time to look at it again.

option 1 above won't work as the Gitea container runs an init system with scripts that try to do overly clever things with environment variables. (That was my first thought, too.)

I had a PR against the old repo for this chart (https://github.com/k8s-land/gitea-chart/pull/22) that put all sensitive data into Secrets, but it was never merged. Unfortunately it looks like it may need a fair bit of work now since the massive changes of PR #7, and it'll likely be a few weeks before I have time to look at it again. option 1 above won't work as the Gitea container runs an init system with scripts that try to do overly clever things with environment variables. (That was my first thought, too.)

luhahn commented

2020-09-01 07:27:59 +00:00

(Migrated from gitea.com)

I'll have a look at it and will see if we can adapt this to the new structure. Might be later that week or next week

👍 1

luhahn commented

2020-09-18 06:58:06 +00:00

(Migrated from gitea.com)

Takes a little longer until i get back to this helm chart. Currently remodeling our cluster :D

luhahn commented

2020-09-24 11:04:52 +00:00

(Migrated from gitea.com)

Currently working on a PR for this. I think i might have a good and easy solution for this problem.

luhahn commented

2020-09-24 12:32:58 +00:00

(Migrated from gitea.com)

So, I've moved all password related data to secrets, please let me know if this is what you've had in mind.

We can discuss about not storing data in app.ini at all, but imo when someone gets access to your gitea container, security is broken anyways :D

So, I've moved all password related data to secrets, please let me know if this is what you've had in mind. We can discuss about not storing data in app.ini at all, but imo when someone gets access to your gitea container, security is broken anyways :D

👍 2

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#17