0

I am using supabase-community/supabase-kubernetes to deploy Supabase in Kubernetes.

For Studio, Storage, Kong, Realtime, Rest and Auth services, you need to define at least jwt secret or in some cases the anon or service key.

However, I have two problems with this kind of configuration:

  1. You need to configure the same secret information multiple times in values.yaml
  2. The secrets won't be stored in a K8s secret

To improve these two aspects, I propose two configure those values in a dedicated section, e.g.:

  jwtSecrets:
    anonKey: "JWT_ANON_KEY"
    serviceKey: "JWT_SERVICE_KEY"
    key: "YOUR_SUPER_SECRET_JWT_TOKEN_WITH_AT_LEAST_32_CHARACTERS_LONG"

When rendered with the templates, a "global" secret gets created and every service (Studio, Storage, Kong, etc.) references this secret in its configuration:

          env:
          ...
            - name: SUPABASE_ANON_KEY
              valueFrom:
                secretKeyRef:
                  name: my-jwt-secret
                  key: anonKey

However, I am unsure if this is best practice for Helm charts?, to have such global configuration sections? Besides, I would like to know where to define this global secret creation — in _helpers.tpl?

Any help is appreciated! :)

Pievee
  • 41
  • 5
  • Declaring a Secret in your chart and referencing it from your chart's Deployments is totally fine; there's no rule that each Deployment must have its own Secret. Some third-party charts have the ability to inject external Secrets into them (but not all). I don't know that there's a specific "best practice" here, beyond that there are legitimate security concerns around passing actual secrets through Helm. – David Maze Jun 13 '22 at 14:22
  • @DavidMaze Thank you for your answer. I also thought of referencing the secret with `secretKeyRef`, whereas the secret needs to be created manually first. But this is cumbersome... When you speak of legitimate security concerns, what are you referring? As I know, the secrets would be in clear text in values.yaml. – Pievee Jun 13 '22 at 16:14
  • Exactly: the secret values need to be passed along in plain text in several places and there are a couple of places they can be extracted (`helm get values`, `helm get manifest`, `kubectl get secret`, in the CI/CD system). – David Maze Jun 13 '22 at 16:33
  • Yeah, I think in this case I will reference the secret with `secretKeyRef`, as I already do with my database connection credentials. That way, the user needs to create the secrets first and then reference it in their `values.yaml`. – Pievee Jun 13 '22 at 17:34

1 Answers1

0

As stated out by @David Maze there is no best practice regarding one secret for multiple deployments in values.yaml of a Helm chart.

On grounds of convenience, the secret name should be referenced in values.yaml like this:

jwtSecretName: my-secret

While the secret must be created by the user beforehand:

apiVersion: v1
data:
  jwtSecret: YWRtaW4=
  serviceKey: MWYyZDFlMmU2N2Rm
  anonKey: MWYyZDFlMmU2N2Rm
kind: Secret

This allows to store the secret data according to Kubernetes best practice and simplifies the configuration of Helm charts.

Pievee
  • 41
  • 5