kubernetes-secret-generator icon indicating copy to clipboard operation
kubernetes-secret-generator copied to clipboard

Add support for replacement of secret values

Open telmich opened this issue 2 years ago • 3 comments

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

telmich avatar Dec 12 '21 21:12 telmich

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.

mittwald-machine avatar Jan 13 '22 02:01 mittwald-machine

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. 🙂

martin-helmich avatar Jan 17 '22 10:01 martin-helmich

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?

telmich avatar Jan 17 '22 11:01 telmich