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

[jonathanfoster]

This issue is resolved with PR #35.

[jonathanfoster]

@rdmcguire This should be fixed in hoppscotch-0.1.0. Mind giving it a try to confirm?

[rdmcguire]

Nitpick: It might be good to reference docs such as this: https://docs.hoppscotch.io/documentation/self-host/enterprise-edition/prerequisites#configuring-openid-connect and note that environment will override config keys,

It's not immediately clear given in cases such as backend.auth.oidc.clientSecret which lacks options for existingSecret and clientSecretKeyName for configuring sensitive fields. With just generic env secret support, config is disjointed and not obvious if leaving clientSecret an empty string will work and be overridden by environment.

[jonathanfoster]

Environment variable order of precedence isn't driven by Hoppscotch, it's native to Kubernetes. The order of precedence is first env then envFrom. If the same value appears multiple times in either env or envFrom, then the last value takes precedence.

You won't find options for extraEnvVars or existingSecret under hoppscotch, you'll find those in the container parameter sections instead. The settings under hoppscotch are for general application settings that are mapped to either a configmap or secret then referenced in pod containers via envFrom. Anything container related is under the corresponding container parameter section like aio, frontend, backend, and admin.

Here's an example of overriding backend.auth.oidc.clientSecret with an existing secret.

backend:
  # Must include OIDC_CLIENT_SECRET key
  extraEnvVarsSecret: your-existing-secret