do not save sensitive data within the gitea configmap #17

Closed
opened 2020-08-31 16:02:29 +00:00 by Jasper-Ben · 6 comments
Contributor

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.

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.

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.

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.)
Member

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

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
lunny added the
kind
security
label 2020-09-02 12:41:59 +00:00
Member

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

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

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

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

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
Sign in to join this conversation.
No Milestone
No Assignees
4 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#17
No description provided.