Handling deployment secrets in Thunder

[hwupathum]

Right now, Thunder deployments include secrets directly in deployment.yaml file (for example, encryption secret).
This approach works for initial setups but poses clear security and maintainability risks, especially as we expand to different environments and teams.

We should move toward a secure and flexible secret management model, starting with environment variables as a baseline.

Option 1: Environment Variables

• Inject secrets at deployment time through environment variables instead of hardcoding them.
• Kubernetes supports defining secrets as Secret objects and mounting them as environment variables or volumes.
• Thunder could read required secrets via a utility package (for example, pkg/secrets or pkg/env).

Option 2: Secret Manager Integration (future extension)

• Later, we can consider fetching secrets from services such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault.
• The same abstraction layer could support both environment and managed sources.

[senthalan]

Shouldn’t we also support reading secrets mounted as files? The configuration file would have the location to the file with the secrets, and the file with the secrets would be mounted at runtime. I remember this was also a recommended practice.

The configuration will look like this

database:
  host: db.example.com
  username: dbuser
  password_file: /var/run/secrets/db-password  # Points to mounted secret

[darshanasbg]

+1.. As you correctly proposed, we need the environment variable support in immediate terms and vault integration after that..

Also, with [1] (cc: @rajithacharith) we are planning to infer values from the environment variables for some other configs.. We can(/need) to align the work and reuse any resolving logic.

Also, if there are default values that needs to be changed every deployment, we need to track those as well.. I'm thinking we need to generate those values dynamically in product startup sequence.. To be clear, i'm not suggesting to generate this in the server startup code.. Rather we have the start.sh script to initialize these when running with a flag like start.sh -i.

[1] #527

[hwupathum]

During offline discussion with @senthalan and @rajithacharith, we decided to supports 3 ways handle secrets depending on the deployment model:

• File reference: Use a file:// path to read the key from a mounted file or secret volume.
• Environment variable or templated value: Inject the key at runtime using an environment variable or Helm value.
• Inline string: Specify the key directly in the configuration, intended mainly for local development or testing.

crypto:
  key: "file://repository/resources/security/crypto.key"
  # or
  key: {{ .CRYPTO }}
  # or
  key: "value"

In the build script, we will be adding file object to the pack as default. The final format of the each variable type is yet to be finalised.

[senthalan]

Regarding the File reference pattern, let's do some research on how other products are defining it and let's comeup with some options

[hwupathum]

Product	Prefix/Syntax	Usage Context
Search Guard	file:/path or env:VAR	Security config (Certs/Passwords)
Apache Airflow	aws:// or vault://	Secret Backend selection
Caddy	{env.VAR}	Runtime placeholder resolution
Prometheus	_file suffix	Field-level distinction (e.g., password_file)
Spring Boot	configtree:/path	Directory-to-Secret mapping

[hwupathum]

Since file:// is a standard notation, IMO we can go ahead with it

[hwupathum]

Fixed with #937