Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for replacement of secret values #66

Open
telmich opened this issue Dec 12, 2021 · 3 comments
Open

Add support for replacement of secret values #66

telmich opened this issue Dec 12, 2021 · 3 comments

Comments

@telmich
Copy link

telmich commented Dec 12, 2021

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:

@mittwald-machine
Copy link
Collaborator

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.

@martin-helmich
Copy link
Member

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

@telmich
Copy link
Author

telmich commented Jan 17, 2022

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants