Support existingSecrets and httproute

[rdmcguire]

The configuration contains many sensitive values, such as database password, client secrets, and smtp auth; but only supports configMap. The entire community.config key should support existingSecret as an option, to support the good advice given in general-guidelines.md: - Use secret management solutions for sensitive data.

Additionally, the Gateway API has superseded the Ingress API, support for defining an httproute would be a nice to have.

I'd be willing to submit a PR with support for config from a secret, and also one for httproute support. Please do let me know if there is appetite in this project for external contribution.

[AlePini]

Totally agree about using secrets for sensitive data, but I think is easier to maintain separated secrets for each section, rather than having a huge one containing every env var.

I was working on this specific issue in the last few days and I just created a PR, check if it resolve your issue!

[JakobStadlhuber]

please merge

[jonathanfoster]

A good way to support existing secrets as well as additional env vars would be to use an extraEnvs field.

community:
  # - name: DATABASE_URL
  #   value: "postgres://username:password@host:5432/database"
  extraEnvs: []

This could rendered in the deployment after existing env vars.

spec:
  template:
    spec:
      containers:
      - env:
        - name: EXISTING_ENV_VAR
          value: "abc1234"
        {{- toYaml .Values.community.extraEnvs | nindent 14 }}
        envFrom:
        - configMapRef:
          name: {{ .Release.Name }}-community-config
        - secretRef:
          name: {{ .Release.Name }}-community-secrets

Since env takes precedence over envFrom (environment variables), you could override the database URL with your own secret.

community:
  extraEnvs:
  - name: DATABASE_URL
    valueFrom:
      secretKeyRef:
        name: hoppscotch-postgres
        key: uri

For gateway API support, I would keep ingress and add a separate gateway node. This way any changes would be backwards compatible with ingress until it's fully deprecated.

service:
  ingress:
    enabled: false
  gateway:
    enabled: true