Skip to main content

Using Kubernetes Secrets

To securely store sensitive configuration like passwords, tokens, and admin secrets, we recommend using Kubernetes Secrets.

By default, the RepoFlow Helm chart uses values defined in values.yaml, but any environment variable can be overridden using a Kubernetes Secret by setting the secretEnv section for each component.

Important:
If you use a Secret for a password (for example, Elastic, Postgres, or Minio), make sure any other component that needs that value is updated to use the same Secret or Secret Value. See examples below.

How secretEnv Works​

  • If a key exists in both environment and secretEnv, the value from secretEnv is used.
  • If a key exists only in environment, the inline value is used.
  • Secrets are never stored in Helm releases: They are only referenced at runtime using Kubernetes valueFrom.secretKeyRef.

Example Usage for Each Component​

All the environment variables that contain secrets (like passwords, tokens, and admin keys), along with other variables you will probably want to change in production (such as URLs, endpoints, and domains), are listed in the production deployment documentation.
We recommend you review and adjust all of them for a secure and production ready installation.

1. RepoFlow Server​

Example values.yaml:

server:
  secretEnv:
    HASURA_ADMIN_SECRET:
      secretName: repoflow-server-secret
      key: hasuraAdminSecret
    JWT_SECRET:
      secretName: repoflow-server-secret
      key: jwtSecret

2. Hasura​

If you want to keep your admin password (or full connection string) in a secret:

hasura:
  secretEnv:
    HASURA_GRAPHQL_DATABASE_URL:
      secretName: repoflow-postgres-secret
      key: databaseUrl
    HASURA_GRAPHQL_METADATA_DATABASE_URL:
      secretName: repoflow-postgres-secret
      key: databaseUrl
    HASURA_GRAPHQL_ADMIN_SECRET:
      secretName: repoflow-server-secret
      key: hasuraAdminSecret

Note:
The value of HASURA_GRAPHQL_ADMIN_SECRET (in Hasura) must exactly match the value of HASURA_ADMIN_SECRET (in the RepoFlow server) for authentication to work.
If you use a secret for the admin secret in Hasura, make sure the server is referencing the same secret with the key HASURA_ADMIN_SECRET, or sets the exact same value in its environment.

3. PostgreSQL​

If you want to store the Postgres password in a secret:

postgresql:
  secretEnv:
    POSTGRES_PASSWORD:
      secretName: my-postgres-secret
      key: postgresPassword

Note:
If you use a Secret for the Postgres password, you must also configure Hasura to read the database URL (including the password) from a Secret as shown above.
The fallback logic will only work if you are using inline values for both.

4. Minio​

If you want to store Minio root credentials in a secret:

minio:
  secretEnv:
    MINIO_ROOT_USER:
      secretName: minio-secret
      key: MINIO_ROOT_USER
    MINIO_ROOT_PASSWORD:
      secretName: minio-secret
      key: MINIO_ROOT_PASSWORD

Important: If you use secrets for Minio credentials, you must also update your S3 settings in the server to use the same secrets for S3_ACCESS_KEY and S3_SECRET_KEY.

5. ElasticSearch​

If you want to store the Elastic password in a secret:

elastic:
  secretEnv:
    ELASTIC_PASSWORD:
      secretName: elastic-secret
      key: ELASTIC_PASSWORD

Important:
If you use a Secret for the Elastic password, make sure the server also uses the same Secret for SMART_SEARCH_PASSWORD!