kubernetes-secret-generator
kubernetes-secret-generator copied to clipboard
Add support for replacement of secret values
Is your feature request related to a problem? Please describe.
Software like matrix-synapse expects a yaml file for the postgres configuration. The generated secret should be both consumable by postgres (reading from an environment variable) as well as from matrix-synapse.
Describe the solution you'd like
One of the easiest versions to support this would be by something on the lines of templating, aka sed aka helm alike:
apiVersion: v1
kind: Secret
metadata:
name: string-secret
annotations:
secret-generator.v1.mittwald.de/replace: PASSWORD
stringData:
dbconfig: |
database:
name: psycopg2
args:
user: synapse_user
password: PASSWORD
POSTGRES_PW: PASSWORD
Describe alternatives you've considered
Not sure which other ways are there to support one value that needs to be formatted differently.
Additional context
The main problem is that different software is bound, but uses different formatting. Matrix Synapse and postgresql is a good example, but the new libpq feature for managing passwords, which is now used in Django 4.0 is another one:
The secret should contain:
hostname:port:database:username:password
as a value. The username and password might be generated by the generator, whereas hostname/port/database is likely coming from something like helm/argocd/etc.
However, that file needs to be generated and above solution could solve this, too:
apiVersion: v1
kind: Secret
metadata:
name: string-secret
annotations:
secret-generator.v1.mittwald.de/replace: PASSWORD, USERNAME
stringData:
pgpass: |
hostname:port:database:USERNAME:PASSWORD
POSTGRES_PW: PASSWORD
POSTGRES_USER: USERNAME
The lower two can be injected into the postgres container, pgpass can be injected into the client (f.i. django) container.
See also:
- https://www.postgresql.org/docs/current/libpq-pgservice.html
- https://www.postgresql.org/docs/9.4/libpq-pgpass.html
There has not been any activity to this issue in the last 30 days. It will automatically be closed after 7 more days. Remove the stale
label to prevent this.
Apologies for the late response.
I'm hesitant to add additional complex features that are configurable using annotations (in fact, I'd prefer phasing out annotation support entirely in favour of using CRs).
Maybe we could extend the CR definition to allow templated values? Maybe something like this:
apiVersion: "secretgenerator.mittwald.de/v1alpha1"
kind: "StringSecret"
metadata:
name: "example-pw"
namespace: "default"
spec:
forceRegenerate: false
data:
username: "testuser"
fields:
- fieldName: "postgresPassword"
encoding: "hex"
length: "15"
templateFields:
- fieldName: dbconfig
template: |
database:
name: psycopg2
args:
user: synapse_user
password: {{ .data.dbconfig }}
WDYT? Anyway, PRs are always welcome. 🙂
I'm also in favor for CR >> annotations. The template looks great, unfortunately my go skills are not really existing :-(
In regards to the template, I think you meant to refer {{ .data.postgresPassword }}
, didn't you?