Need help putting jwt_auth_secret and database/passpharse away from config.toml

[Fabiosilvero]

Hello,

I'm trying to set up Garm in Kubernetes, and I would like to remove the sensitive strings from config.toml. I tried to use env vars like this :

    [jwt_auth]
    secret = "$JWT_AUTH_SECRET"

    [database]
      backend = "sqlite3"
      # This needs to be changed.
      passphrase = "$DATABASE_PASSPHRASE"

In kubernetes :

    Environment:
      DATABASE_PASSPHRASE:  <set to the key 'jwt_auth_secret' in secret 'garm-config-secrets'>      Optional: false
      JWT_AUTH_SECRET:      <set to the key 'database_passphrase' in secret 'garm-config-secrets'>  Optional: false

But that didn't worked :

2025/02/07 11:01:23 Fetching config: error validating database config: passphrase must be set and it must be a string of 32 characters (aes 256)
validating config
github.com/cloudbase/garm/config.NewConfig
	/build/garm/config/config.go:90
main.main
	/build/garm/cmd/garm/main.go:189
runtime.main
	/usr/local/go/src/runtime/proc.go:272
runtime.goexit
	/usr/local/go/src/runtime/asm_amd64.s:1700

Is it possible to use env vars or source these as separate files ? That way I can manage the configuration in configmap and the sensitive strings as Kubernetes Secrets.

I could encode the whole file as base64 and mounting it but the downside would be troubles when consulting the configuration from Git.

Thanks :)

[gabriel-samfira]

Hi @Fabiosilvero

I think this can be implemented by changing the way the GARM config is generated. You can use a simple entrypoint that makes sure that the final garm config file will have the appropriate values. So you can define a config map with some placeholder for secrets, you can define some secrets with those values, then an entrypoint for the GARM container can compose the final config before starting GARM.

I don't think this is something that needs to be implemented in GARM specifically.

At some point I really need to make time and deploy GARM along side the operator. See what we can do in GARM to make it easier to have a nice experience when deploying it in k8s. The operator doesn't require GARM to be in k8s, so this is not necessarily something that needs to be changed there. But it would be nice to have some helm charts for GARM itself, not just the operator.

[Fabiosilvero]

Hi @gabriel-samfira ,

Thank you for your answer and your hint, we'll do it like that :)

At some point I really need to make time and deploy GARM along side the operator. See what we can do in GARM to make it easier to have a nice experience when deploying it in k8s. The operator doesn't require GARM to be in k8s, so this is not necessarily something that needs to be changed there. But it would be nice to have some helm charts for GARM itself, not just the operator.

I agree completely :)

[Fabiosilvero]

We found this and that when looking around the repo, we'll use an initContainer so the garm container will run without any need of running something differently :)

[gabriel-samfira]

yup. The entrypoint can just do an envsub. The container we release is generated from busybox with just the GARM binaries inside. So you may need to add a custom entrypoint that calls envsub. But that is the general idea.