chore(helm): enable k8s secrets and custom db user for subchart

[evegufy]

WHAT

• enable kubernetes secrets for postgresql subchart
• change to custom db user for subchart

WHY

use kubernetes resource designed to store sensitive information

Issue

related to eclipse-tractusx/ssi-credential-issuer#12

FURTHER NOTES

• I have performed a self-review of my own changes
• I have successfully tested my changes

[evegufy]

Hi @paullatzelsperger could you please support me with updating the dependencies file?
I ran the following on my local after downloading dash.jar, but I just get a blank file:

./gradlew allDependencies | grep -Poh "(?<=\s)[\w.-]+:[\w.-]+:[^:\s\[\]]+" | sort | uniq | java -jar dash.jar - -summary DEPENDENCIES-gen

Generally there shouldn't be a need to update the file as I didn't change any dependencies.

[paullatzelsperger]

Generally there shouldn't be a need to update the file as I didn't change any dependencies.

yeah, that is unfortunately not the case, because someone else, even outside of tractus-X could have created an IPLab review request, which causes a change...

The easiest way is to just copy the output of the failing check, between where it says === Please copy the following content back to DEPENDENCIES === and === end of content === and paste it into your DEPENDENCIES file.

You could regenerate the file also with the gradle command you mentioned, but the sorting will depend on your OS and locale. I found it generally works well with most en_US Linux distributions (Debian, Ubuntu, Arch).

[evegufy]

Generally there shouldn't be a need to update the file as I didn't change any dependencies.

yeah, that is unfortunately not the case, because someone else, even outside of tractus-X could have created an IPLab review request, which causes a change...

The easiest way is to just copy the output of the failing check, between where it says === Please copy the following content back to DEPENDENCIES === and === end of content === and paste it into your DEPENDENCIES file.

You could regenerate the file also with the gradle command you mentioned, but the sorting will depend on your OS and locale. I found it generally works well with most en_US Linux distributions (Debian, Ubuntu, Arch).

thanks, worked 👍

[paullatzelsperger]

I'm very doubtful that using Kubernetes Secrets will achieve much in the ways of security here, since all secrets are stored as environment variables within the containers, so everyone with access to the cluster can easily read them with kubectl describe pod.

In my opinion, a better approach for application security would be to store both the API key and the DB credentials in a vault, and read it from there instead of environment vars (or system/app properties).
Note that a K8s secret to configure the postgres pod would still be an improvement, so we should keep that.

For the API key, we could already do this using the edc.api.auth.key.alias application property, but for the DB credentials we need a small upstream change. To that end, we'll need to add a dependency on HashicorpVault plus implement a way to pre-seed credentials.

[paullatzelsperger]

The name authKeyAlias of just alias seems more fitting.

[paullatzelsperger]

that path seems incorrect - shouldn't it be this?

Suggested change

	{{- if .Values.existingSecret -}}
	{{- if .Values.server.endpoints.management.existingSecret -}}

[evegufy]

thanks, fixed

[paullatzelsperger]

that path seems incorrect - shouldn't it be this?

Suggested change

	{{- if .Values.existingSecret -}}
	{{- if .Values.server.endpoints.management.existingSecret -}}

[evegufy]

thanks, fixed

[evegufy]

I'm very doubtful that using Kubernetes Secrets will achieve much in the ways of security here, since all secrets are stored as environment variables within the containers, so everyone with access to the cluster can easily read them with kubectl describe pod.

In my opinion, a better approach for application security would be to store both the API key and the DB credentials in a vault, and read it from there instead of environment vars (or system/app properties). Note that a K8s secret to configure the postgres pod would still be an improvement, so we should keep that.

For the API key, we could already do this using the edc.api.auth.key.alias application property, but for the DB credentials we need a small upstream change. To that end, we'll need to add a dependency on HashicorpVault plus implement a way to pre-seed credentials.

sure, I agree completely with using a vault for secrets 👍 using k8s secrets can certainly not replace the usage of a vault but it's a best practice which reduces the risk of accidental exposure.

[paullatzelsperger]

sure, I agree completely with using a vault for secrets 👍 using k8s secrets can certainly not replace the usage of a vault but it's a best practice which reduces the risk of accidental exposure.

I created this upstream issue eclipse-edc/Connector#4128 which adds the possibility to read JDBC config from the vault.

My point was that neither the API key nor the JDBC config should not be configured directly, but should be put in the vault, and only the alias should be configured in the chart.

With that, the only necessary secret that remains is the DB config for the Postgres chart (not the JDBC config of the application!)

[evegufy]

@paullatzelsperger as discussed, I limited the change to the db secrets

[evegufy]

obsolete due to #35