search

netbox-community / netbox-chart

A Helm chart for NetBox
https://netbox.readthedocs.io/
Apache License 2.0
244 stars 148 forks source link

When `existingSecret` value is set the values for postgres, redis and superuser remain empty #311

Closed joelvdvoort closed 3 weeks ago

joelvdvoort commented 3 weeks ago

Hello,

I'm facing a rather strange issue. I've set existingSecret in my values.yaml and created the secret with all the required keys. All the resulting secrets contain empty string values and thus the application doesn't start. Setting the values into the fields directly works and creating separate exisingSecrets for all the services works as well.

LeoColomb commented 3 weeks ago

Thanks for opening this issue @joelvdvoort. Could you elaborate on your use of redis and postegres? Eventually, please provide the values you are using for these two. Furthermore, what is the chart version?

joelvdvoort commented 3 weeks ago

Hello @LeoColomb. Thank you for your quick ressponse. Chart version is "netbox-5.0.0-beta.78" and I'm using external Postgres and external redis (bitnami's valkey chart to be precise).

Below is the application manifest I've used in argocd. It's a little different from editing the values.yaml directly, argocd allows patching values from the application spec.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: insights-netbox-cluster
spec:
  project: insights-netbox
  source:
    repoURL: ghcr.io/netbox-community/netbox-chart
    targetRevision: ' 5.0.0-beta.78'
    helm:
      parameters:
        - name: postgresql.enabled
          value: 'false' #disable bundled charts
        - name: redis.enabled
          value: 'false' #and same goes for redis
        - name: cachingRedis.host
          value: netbox-valkey-headless.netbox-valkey
        - name: cachingRedis.sentinelService
          value: netbox-valkey-headless.netbox-valkey
        - name: externalDatabase.database
          value: app
        - name: externalDatabase.host
          value: netbox-pg-cluster-rw.netbox-pg
        - name: externalDatabase.username
          value: app
        - name: tasksRedis.host
          value: netbox-valkey-headless.netbox-valkey
        - name: tasksRedis.sentinelService
          value: netbox-valkey-headless.netbox-valkey
        - name: replicaCount
          value: '3'
        - name: worker.replicaCount
          value: '3'
        - name: existingSecret
          value: netbox-app-auth
    chart: netbox
  destination:
    server: 'https://joel-k8stest.redacted.local:6443'
    namespace: netbox-app
  syncPolicy:
    syncOptions:
      - CreateNamespace=true

The referenced secret contains:

apiVersion: v1
data:
  db_password: ++++++++++++++++++++++++++++++++++++++++++++++++++
  email_password: ++++++++++++++++++++++++++++++++
  ldap_bind_password: ++++++++++++
  postgresql-password: ++++++++++++++++++++++++++++
  redis_cache_password: +++++++++++++
  redis_tasks_password: +++++++++++++++++++
  secret_key: +++++++++++++++++++++++
  superuser_api_token: +++++++++++++++++++++
  superuser_password: ++++++++
kind: Secret
metadata:
  creationTimestamp: "2024-08-20T13:42:40Z"
  name: netbox-app-auth
  namespace: netbox-app
  resourceVersion: "13479404"
  uid: 508d90f2-57ef-4d3b-988f-3c21e5cbf962
type: Opaque
LeoColomb commented 3 weeks ago

You should also specify the existingSecret for each sub-packages:

In the three cases, existingSecretName must be provided.

I'll fix the comment of existingSecret to reflect the actual behavior.

joelvdvoort commented 3 weeks ago

I understand and have edited my desployment with the necessary changes. I'm still getting errors; MountVolume.SetUp failed for volume "secrets" : references non-existent secret key: password. Looking at the values.yaml and the proposed keys in the existingSecret the key names are not the same. For example I've made key "superuser_password" but the deployment keeps looking for "password" in the volume mount even when hardcoding the existingSecretKey. Please see the application spec below

project: netbox
source:
  repoURL: ghcr.io/netbox-community/netbox-chart
  targetRevision: ' 5.0.0-beta.78'
  helm:
    parameters:
      - name: postgresql.enabled
        value: 'false'
      - name: redis.enabled
        value: 'false'
      - name: replicaCount
        value: '3'
      - name: worker.replicaCount
        value: '3'
    values: |-
      externalDatabase:
        host: netbox-pg-cluster-rw.netbox-pg
        port: 5432
        database: app
        username: app
        existingSecretName: "netbox-app-auth"
        existingSecretKey: postgresql-password
      tasksRedis:
        host: netbox-valkey-headless.netbox-valkey
        port: 6379
        existingSecretName: "netbox-app-auth"
        existingSecretKey: redis_tasks_password
      cachingRedis:
        host: netbox-valkey-headless.netbox-valkey
        port: 6379
        existingSecretName: "netbox-app-auth"
        existingSecretKey: redis_tasks_password
      superuser:
        existingSecret: "netbox-app-auth"
        existingSecretKey: superuser_password
      existingSecret: "netbox-app-auth"
  chart: netbox
destination:
  server: https://joel-k8stest.redacted.local:6443
  namespace: netbox-app
LeoColomb commented 3 weeks ago

There is no existingSecretKey for superuser, indeed, and this is by design, to make it as consistent as possible and to leverage kubernetes.io/basic-auth schema validation.

See the dedicated secret template, from which the key must be respected: https://github.com/netbox-community/netbox-chart/blob/b1415617209bf2ad0d36bdf8dfa342d02e76f130/charts/netbox/templates/superuser-secrets.yaml The README is up-to-date on this part: https://github.com/netbox-community/netbox-chart?tab=readme-ov-file#superuser-secret