helm-charts/voucher-vault/values.yaml

# Scale the whole chart down without uninstalling it: scaleDown: true renders
# every Deployment/StatefulSet with replicas: 0 (and suspends CronJobs) and
# takes precedence over any per-workload replicas value. PVCs, Secrets and
# Services stay in place; scaleDown: false brings the workloads back up.
scaleDown: false

secrets:
  voucherVaultSecretRef: null
  oidcSecretRef: null
  databaseSecretRef: null

voucherVault:
  # Replica count for this workload; 0 is allowed and scales it down.
  # The chart-global scaleDown flag takes precedence.
  replicas: 1
  resources:
    # Limits are optional: memory and ephemeral-storage limits default to
    # limitFactor x the request, an explicitly set limit always wins, and a
    # CPU limit is only set when configured explicitly under "limits".
    limitFactor: 3
    requests:
      cpu: 0.1
      memory: 256Mi
      # The static-files emptyDir (~90Mi of static assets, see the
      # securityContext comment) counts toward the pod's ephemeral-storage
      # usage, so the request must cover it.
      ephemeral-storage: 128Mi
  # "/" answers with a redirect for anonymous users, which httpGet treats as
  # success. The Host header must be set to 127.0.0.1 because Django's
  # ALLOWED_HOSTS only accepts 127.0.0.1 and the configured DOMAIN — probing
  # with the default Host (the pod IP) would always return 400.
  livenessProbe:
    httpGet:
      path: /
      port: http
      httpHeaders:
        - name: Host
          value: 127.0.0.1
    periodSeconds: 10
    timeoutSeconds: 5
    failureThreshold: 3
  readinessProbe:
    httpGet:
      path: /
      port: http
      httpHeaders:
        - name: Host
          value: 127.0.0.1
    periodSeconds: 10
    timeoutSeconds: 5
    failureThreshold: 3
  # The startup probe gates liveness/readiness. Startup budget = 5s * 30 = 150s.
  startupProbe:
    httpGet:
      path: /
      port: http
      httpHeaders:
        - name: Host
          value: 127.0.0.1
    periodSeconds: 5
    timeoutSeconds: 5
    failureThreshold: 30
  # The upstream image (l4rm4nd/vouchervault) runs as www-data (uid/gid 33).
  # With readOnlyRootFilesystem the chart mounts emptyDirs over the paths the
  # image writes at runtime: /tmp (upload/PDF scratch files), /opt/app/logs
  # and STATIC_ROOT /opt/app/myapp/static (the entrypoint runs collectstatic
  # at every start; an init container seeds the volume with the static files
  # shipped in the image, because the directory doubles as the app's static
  # source). Uploads and the database live on the PVC at /opt/app/database.
  securityContext:
    pod:
      runAsNonRoot: true
      runAsUser: 33
      runAsGroup: 33
      fsGroup: 33
      fsGroupChangePolicy: Always
      # RuntimeDefault applies the container runtime's default seccomp filter,
      # which blocks the syscalls a normal workload never makes. It sits in the
      # pod context on purpose: from here it covers every container in the pod
      # including init containers, while a container-level seccompProfile would
      # have to be repeated for each one (and silently missed on the next one
      # added). A container that genuinely needs a different filter can still
      # override it under securityContext.container, which wins over this value.
      seccompProfile:
        type: RuntimeDefault
    container:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      runAsNonRoot: true
      capabilities:
        drop:
          - ALL
  ports:
    - containerPort: 8000
      protocol: TCP
      name: http
  env:
    # ingress.domain is not a pure Ingress value: Django's ALLOWED_HOSTS only
    # accepts 127.0.0.1 and this DOMAIN, so an empty value makes the app answer
    # 400 to every real request. It therefore stays required even when the
    # Ingress is switched off via ingress.enabled.
    - name: DOMAIN
      value: '{{ required "A Domain/Host must be provided (ingress.domain)" .Values.ingress.domain }}'
    - name: SECURE_COOKIES
      value: "True"
    - name: SESSION_COOKIE_AGE
      value: "30"
    - name: SESSION_EXPIRE_AT_BROWSER_CLOSE
      value: "True"
    - name: EXPIRY_THRESHOLD_DAYS
      value: "90"
    - name: EXPIRY_LAST_NOTIFICATION_DAYS
      value: "7"
    - name: TZ
      value: "UTC"
    - name: PORT
      value: "8000"
    - name: SECRET_KEY
      valueFrom:
        secretKeyRef:
          name: "{{ .Release.Name }}-{{ .Chart.Name }}-secret"
          key: "secretKey"
    - name: REDIS_URL
      valueFrom:
        secretKeyRef:
          name: "{{ .Release.Name }}-{{ .Chart.Name }}-secret"
          key: "redis-url"
    - name: CELERY_WORKER_CONCURRENCY
      value: "1"
    - name: CELERY_WORKER_PREFETCH_MULTIPLIER
      value: "1"
    - name: OIDC_ENABLED
      value: "True"
    - name: OIDC_AUTOLOGIN
      value: "True"
    - name: OIDC_CREATE_USER
      value: "True"
    - name: OIDC_RP_SIGN_ALGO
      value: "RS256"
    - name: OIDC_OP_JWKS_ENDPOINT
      valueFrom:
        secretKeyRef:
          name: "{{ .Release.Name }}-{{ .Chart.Name }}-oidc-secret"
          key: "oidc-jwks-endpoint"
    - name: OIDC_RP_CLIENT_ID
      valueFrom:
        secretKeyRef:
          name: "{{ .Release.Name }}-{{ .Chart.Name }}-oidc-secret"
          key: "client-id"
    - name: OIDC_RP_CLIENT_SECRET
      valueFrom:
        secretKeyRef:
          name: "{{ .Release.Name }}-{{ .Chart.Name }}-oidc-secret"
          key: "client-secret"
    - name: OIDC_OP_AUTHORIZATION_ENDPOINT
      valueFrom:
        secretKeyRef:
          name: "{{ .Release.Name }}-{{ .Chart.Name }}-oidc-secret"
          key: "authorization-endpoint"
    - name: OIDC_OP_TOKEN_ENDPOINT
      valueFrom:
        secretKeyRef:
          name: "{{ .Release.Name }}-{{ .Chart.Name }}-oidc-secret"
          key: "token-endpoint"
    - name: OIDC_OP_USER_ENDPOINT
      valueFrom:
        secretKeyRef:
          name: "{{ .Release.Name }}-{{ .Chart.Name }}-oidc-secret"
          key: "user-endpoint"
    - name: DB_ENGINE
      value: "postgres"
    - name: POSTGRES_HOST
      valueFrom:
        secretKeyRef:
          name: "{{ .Release.Name }}-{{ .Chart.Name }}-db-secret"
          key: "host"
    - name: POSTGRES_PORT
      valueFrom:
        secretKeyRef:
          name: "{{ .Release.Name }}-{{ .Chart.Name }}-db-secret"
          key: "port"
    - name: POSTGRES_USER
      valueFrom:
        secretKeyRef:
          name: "{{ .Release.Name }}-{{ .Chart.Name }}-db-secret"
          key: "user"
    - name: POSTGRES_PASSWORD
      valueFrom:
        secretKeyRef:
          name: "{{ .Release.Name }}-{{ .Chart.Name }}-db-secret"
          key: "password"
    - name: POSTGRES_DB
      valueFrom:
        secretKeyRef:
          name: "{{ .Release.Name }}-{{ .Chart.Name }}-db-secret"
          key: "database"
  storage:
    volumes:
      - name: voucher-vault-data
        persistentVolumeClaim:
          claimName: "{{ .Release.Name }}-{{ .Chart.Name }}-pvc"
    volumeMounts:
      - name: voucher-vault-data
        mountPath: /opt/app/database
        subPath: voucher-vault-data

storage:
  amount: 10Gi
  storageClass: null

ingress:
  # Set to false to omit the Ingress entirely. Note that ingress.domain stays
  # required even then: it is also Django's ALLOWED_HOSTS entry (the DOMAIN env
  # above), not just the Ingress host. Only clusterIssuer becomes unnecessary.
  #
  # Mutually exclusive with httpRoute.enabled below (Gitea #114): with both
  # true the render aborts, naming both values.
  enabled: true
  clusterIssuer: null
  # The public hostname of this release. Read by the Ingress, by Django's
  # DOMAIN (and through it ALLOWED_HOSTS and CSRF_TRUSTED_ORIGINS), and - when
  # httpRoute.hostnames is empty - by the HTTPRoute. Required in every mode.
  domain: null
  className: nginx
  # Extra annotations for the Ingress; merged with the cert-manager
  # cluster-issuer annotation the chart always sets.
  #
  # THESE HAVE NO COUNTERPART IN GATEWAY MODE. The Gateway API has no
  # annotation channel for controller behaviour, so anything configured here is
  # simply gone when httpRoute.enabled is used instead - it is then the
  # Gateway's business, or that of an implementation-specific policy object
  # this chart deliberately does not render. Nothing this chart needs lives
  # here by default.
  annotations: {}

# Gateway-API alternative to the Ingress above (Gitea #114). Off by default, so
# an existing release is unaffected; exactly one of ingress.enabled and
# httpRoute.enabled may be true.
#
# The chart renders ONLY an HTTPRoute with parentRefs - no Gateway, no
# gatewayClassName, no Certificate and no implementation-specific policy
# object. Class and certificate belong to the Gateway and therefore to the
# platform, which is what keeps this chart independent of whether the cluster
# runs nginx-gateway-fabric, Cilium, Envoy Gateway or Istio.
#
# The Gateway-API CRDs must be installed in the cluster: the chart does not and
# cannot detect them (.Capabilities.APIVersions is unreliable at template
# time), so with httpRoute.enabled: true and no CRDs the INSTALL fails.
httpRoute:
  enabled: false
  # The Gateway(s) this route attaches to - a platform object, usually in
  # another namespace, which must allow this namespace in its listener's
  # allowedRoutes. One entry per parent, the fields are the Gateway API's
  # ParentReference (name, and optionally namespace, sectionName, port, group,
  # kind), passed through unchanged:
  #
  #   parentRefs:
  #     - name: public
  #       namespace: gateway
  #       sectionName: https
  #
  # REQUIRED while httpRoute.enabled is true - the render aborts on an empty
  # list, because a route without a parent is created, is valid and routes
  # nothing, with no event to say so.
  parentRefs: []
  # Empty means [ingress.domain], so the hostname has one source of truth. Set
  # explicitly only to publish under a different or an additional name - which
  # is how a migration from the Ingress runs: the HTTPRoute takes a second
  # hostname while the Ingress keeps ingress.domain.
  #
  # FOR THIS CHART THAT IS A SHARP EDGE. A hostname the route publishes but
  # DOMAIN does not name is answered with 400 by Django (ALLOWED_HOSTS), and
  # all three probes stay green while it happens - they carry a Host header of
  # 127.0.0.1 on purpose. So a second hostname needs ingress.domain changed in
  # the same step.
  hostnames: []

# ---------------------------------------------------------------------------
# NetworkPolicy (Gitea #5). On by default. The reference implementation with
# the full reasoning is template-chart; the convention is in README, "Chart
# style guidelines", and the operator's view on this chart's wiki page.
# ---------------------------------------------------------------------------
networkPolicy:
  # WHAT THIS POLICY ALLOWS: inbound 8000 only, and outbound DNS plus TCP 5432
  # (Postgres), 6379 (Redis) and 443 (the OIDC provider).
  #
  # WHAT IT DOES NOT DO: those are the STANDARD ports, not the configured ones -
  # all three dependencies arrive as connection details inside 1Password items
  # this chart never parses. A dependency on another port is BLOCKED and belongs
  # in egress.extraPorts.
  #
  # Inbound 8000 is not restricted by source in the default (probe port), and a
  # policy is only a boundary where the CNI enforces one.
  enabled: true
  # Namespaces whose pods may reach this workload, in addition to the release's
  # own namespace, which is always allowed. Empty means: own namespace only.
  #
  # Matched on the "kubernetes.io/metadata.name" label Kubernetes sets on every
  # namespace itself, so no labelling work is needed on a namespace this chart
  # does not own - and no typo protection either: a name that does not exist
  # matches nothing and is silently ineffective. Note the granularity: an entry
  # opens the port to EVERY pod in that namespace.
  allowedNamespaces: []
  # Source CIDRs allowed to reach port 8000, which is the port all three probes address.
  #
  # EMPTY MEANS OPEN, NOT BLOCKED. With no entry that rule is rendered WITHOUT a
  # "from" selector, so the port is reachable from anywhere the CNI routes to -
  # inside the cluster, since it carries no NodePort.
  #
  # That is the deliberate choice between two bad defaults. The kubelet's probes
  # originate from the IP of the WORKER NODE running the pod, an address this
  # chart cannot know and must not guess: a CIDR that excludes the real node
  # blocks every probe, the pod never becomes Ready, the rollout times out, and
  # the symptom reads as a broken application rather than as a policy.
  #
  # Narrow it by listing the worker node IPs (e.g. ["10.0.1.11/32"]) - and mind
  # the companion trap: once this list is non-empty the rule IS restricted, so
  # everything else that needs the port has to be in it. The chart adds the own
  # namespace, the ingressController below and allowedNamespaces to the same rule for exactly that reason.
  probeSources: []
  # The ingress controller allowed to reach the routed port once probeSources
  # restricts it. Rendered only while ingress.enabled is true, and only in
  # the restricted branch - with the default (open) rule the controller reaches
  # the port anyway. The two keys become ONE "from" entry and are therefore an
  # AND: pods carrying podLabels IN namespace. That is the point of having them
  # at all - the controller's namespace in allowedNamespaces would open the port
  # to every pod in kube-system.
  #
  # MEASURED ON THIS CLUSTER, NOT ASSUMED (2026-10-14): ingress-nginx is gone,
  # the only IngressClass is "traefik" and it is the default, and the controller
  # is the DaemonSet rke2-traefik in kube-system. The same Traefik serves the
  # Gateway API here, so this one source covers the Ingress and the HTTPRoute
  # path alike. A policy written against the wrong controller is accepted, looks
  # strict, and silently blocks all web traffic - and ingress.className says
  # nothing about it, because a class names an implementation, not the pods the
  # traffic comes from.
  ingressController:
    namespace: kube-system
    podLabels:
      app.kubernetes.io/name: rke2-traefik

  # The policy's INBOUND side. Mind the three names that overlap as substrings,
  # because a search for "ingress" matches all of them and they are different
  # things:
  #
  #   ingress                          (top level) the Ingress OBJECT this chart
  #                                    renders - host, TLS, className
  #   networkPolicy.ingress            this block: what the policy lets IN
  #   networkPolicy.ingressController  the SOURCE SELECTOR for the ingress
  #                                    controller's pods. A SIBLING of this block
  #                                    and NO PART OF IT, despite the name.
  ingress:
    # Opens the pod for Istio's ambient mesh (Gitea #143). OFF by default and
    # additive: while it is false this chart renders byte for byte as it did
    # before the value existed.
    #
    # IT RENDERS TWO THINGS, and that they come together is the point:
    #
    #   1. 15008/TCP inbound - ztunnel's HBONE tunnel. Every inbound mesh
    #      connection arrives on it, and ambient "does not and will never bypass
    #      Kubernetes NetworkPolicy enforcement", so without this port a pod
    #      whose namespace has joined the mesh is unreachable.
    #   2. 169.254.7.127/32 as an additional peer - but ONLY where the rule
    #      restricts sources at all, which here means probeSources is non-empty.
    #      Inside the mesh the kubelet's probes are redirected and no longer come
    #      from the worker node's address.
    #
    # WHY ONE SWITCH AND NOT TWO: point 2 is the one nobody thinks of. Whoever
    # adds "15008" to a port list by hand writes a policy that passes review, and
    # the first time probeSources is narrowed every probe is dropped - the pod
    # never becomes Ready and the symptom reads as a broken application rather
    # than as a policy. A switch whose halves can only be had together cannot be
    # set halfway, which is why this is a named intention and not a port list.
    #
    # TWO THINGS IT DOES NOT PROVE:
    #   - That 15008 alone is enough. That comes from Istio's documentation;
    #     measured on this cluster is only which listeners ztunnel opens.
    #     Provable at the first namespace to join the mesh - none carries
    #     istio.io/dataplane-mode yet.
    #   - That the probe-source half works. probeSources is empty in every chart
    #     here, so no release reaches that branch. CI proves its render, not its
    #     effect.
    #
    # Note where the port lands: it joins the rule that carries the probe port,
    # so once probeSources restricts that rule, 15008 is restricted with it.
    # Whether ztunnel needs a peer of its own is open - it runs with its own pod
    # IPs in istio-system (measured: no hostNetwork on the DaemonSet, Istio
    # 1.30.6), so if one proves necessary it is expressible as a
    # namespaceSelector plus podSelector and needs no unknowable node CIDR.
    # BOTH NUMBERS BELOW ARE ISTIO CONSTANTS, NOT STANDARDS, and they are values
    # rather than template literals for exactly that reason: a vendor constant
    # can change, and an operator should be able to correct it without waiting
    # for a chart release. Their provenance is written on each one.
    #
    # DELETING THIS OBJECT IS SAFE. Every read falls back to the defaults
    # declared here (#99), so "ambientMesh: null", or an object carrying only
    # "enabled: true", renders the documented defaults instead of failing.
    ambientMesh:
      # The switch. Everything else here is inert while it is false, and the
      # chart renders exactly as it did before the object existed.
      enabled: false

      # ISTIO'S HBONE PORT. A constant Istio chose, not a standard: not
      # registered with IANA for this, prescribed by no protocol, and unknown to
      # Kubernetes. Read for ztunnel 1.30.6 (measured on this cluster: ztunnel
      # opens [::]:15008 as its inbound listener).
      #
      # If Istio changes it, a pod in the mesh cannot be reached. Change it here
      # in all 30 charts AND in the pinned expectation inside
      # ci/run-networkpolicy-test.sh - the test is deliberately what forces
      # someone to look, because the exception it grants this port is pinned to
      # the number IT knows and not to whatever this value says. A value-driven
      # exception would let a mistyped port through, which is the hole design A
      # of #143 was rejected for.
      #
      # NOT MEASURED: that this port ALONE suffices comes from Istio's
      # documentation. Measured here is only which listeners ztunnel opens, and
      # no namespace carries istio.io/dataplane-mode yet.
      port: 15008

      # SOURCES THE KUBELET'S PROBES ARRIVE FROM ONCE ISTIO HAS REDIRECTED THEM.
      #
      # NOT THE SAME VALUE AS networkPolicy.probeSources one level up, and the
      # two are easy to confuse, so:
      #
      #   networkPolicy.probeSources
      #       YOUR worker node CIDRs. Empty by default, and empty means the
      #       probe rule is OPEN. The chart cannot know these addresses.
      #   networkPolicy.ingress.ambientMesh.redirectedProbeSources
      #       ISTIO's rewrite address. Shipped filled, because unlike the node
      #       IPs it is a constant the chart CAN know. Only rendered where the
      #       rule above is restricted, i.e. where probeSources is non-empty.
      #
      # WHERE 169.254.7.127 COMES FROM - vendor magic, not protocol:
      #
      #   - LINK-LOCAL, 169.254.0.0/16 (RFC 3927): a range reserved for
      #     node-local use that is never routed - exactly the range one picks a
      #     vendor's magic address out of.
      #   - Istio's IPv6 counterpart gives it away:
      #     fd16:9254:7127:1337:ffff:ffff:ffff:ffff carries the SAME DIGITS
      #     (9254:7127 is 169.254.7.127) plus 1337. Numbers built that way are
      #     vendor constants, not protocols.
      #   - KUBERNETES DOES NOT KNOW THIS ADDRESS. Neither the NetworkPolicy API
      #     nor the kubelet has any notion of it; only Istio's own data plane
      #     rewrites the probe source onto it.
      #
      # Read for ztunnel 1.30.6. IF ISTIO CHANGES IT, THE FAILURE IS SILENT:
      # probes would be dropped, and only where probeSources is non-empty - which
      # is nowhere in this repository today - so nothing here and nothing in
      # Kubernetes would report it. What to re-check then: the address Istio's
      # release notes name for probe redirection, this list in all 30 charts, and
      # the pinned expectation in ci/run-networkpolicy-test.sh.
      #
      # A LIST, not a string, and the one case where that does not contradict "a
      # constant, not a configuration": on a DUAL-STACK cluster BOTH entries are
      # needed at the same time, not one of two. This cluster is SingleStack
      # IPv4, so the IPv6 counterpart is left out - an ipBlock of the wrong
      # family is accepted by the API server and matches nothing. Add it
      # ALONGSIDE, never instead, if the cluster gains IPv6.
      #
      # Clearing this list restores the default rather than removing the ipBlock,
      # deliberately: the two halves of this switch are not separable. To not
      # open the port at all, set enabled: false.
      #
      # UNPROVEN IN OPERATION: probeSources is empty in every chart here, so no
      # release reaches this branch. CI proves the render, not the effect.
      redirectedProbeSources:
        - 169.254.7.127/32

  egress:
    # Additional outbound TCP ports. DNS (UDP and TCP 53) is always allowed and
    # has no switch - a knob whose only other setting breaks every name lookup
    # in the pod is a trap, not a feature.
    #
    # PORTS, NOT DESTINATIONS, and that is a limit of the object rather than
    # laziness: a NetworkPolicy matches CIDRs and selectors and never hostnames,
    # so "only to the database host" cannot be written at all. Each entry
    # permits its port to ANY destination. What the cap still buys is real: a
    # compromised pod cannot open arbitrary outbound connections.
    #
    # Add the real port whenever Postgres, Redis or the OIDC issuer is not on
    # 5432 / 6379 / 443.
    extraPorts: []