Secret management in Noxus is designed to separate platform-level infrastructure credentials from workspace-specific runtime secrets.
What Belongs In Secrets
- Infrastructure: Database and Redis credentials, storage access keys.
- Identity: Auth provider (OIDC/SAML) client secrets and signing keys.
- AI Providers: Global API keys for model providers (OpenAI, Anthropic, etc.).
- Integrations: Credentials for third-party tools used across the platform.
Secret Reference
Database
| Secret | Description |
|---|
POSTGRESQL_URL | Primary PostgreSQL connection string (user:password@host:5432) |
VECTOR_POSTGRESQL_URL | Vector database (pgvector) connection string |
Redis
| Secret | Description |
|---|
REDIS_URL | Redis host (without port) |
REDIS_PASSWORD | Redis authentication password |
REDIS_USER | Redis username (optional, for ACL-based auth) |
Object Storage
| Secret | Description |
|---|
S3_ACCESS_KEY_ID | S3-compatible storage access key |
S3_SECRET_ACCESS_KEY | S3-compatible storage secret key |
Observability
| Secret | Description |
|---|
PROM_REMOTE_WRITE_USERNAME | Prometheus remote write basic auth username |
PROM_REMOTE_WRITE_PASSWORD | Prometheus remote write basic auth password |
Integrations
| Secret | Description |
|---|
PLUGIN_SERVER_API_KEY | Plugin server authentication key |
PLUGIN_SERVER_PLATFORM_KEY | Plugin server platform-level key |
Common Secret Backends
Noxus supports several backends for storing and injecting secrets depending on your deployment model.
Kubernetes & OpenShift
Cloud Native
VM / On-Premises
Native Secrets & External Secret Operators
- Store values in Kubernetes
Secrets within the relevant namespaces.
- Inject via
envFrom for all services or explicit secretKeyRef for specific containers.
- Support for External Secrets Operator to sync from AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault.
Managed Secret Managers
- AWS Secrets Manager / Parameter Store: Inject via IAM roles for service accounts (IRSA).
- GCP Secret Manager: Access via Workload Identity and direct environment binding.
- Azure Key Vault: Integration via Managed Identities and CSI drivers.
Encrypted Files & Environment
- Use protected
.env or /env.vm files with 0600 filesystem permissions.
- Support for HashiCorp Vault as a centralized sidecar or initialization agent.
- Systemd-level environment protection for the
noxus service.
Secret Injection Strategies
Noxus allows for granular control over where secrets are exposed within the platform architecture.
These are injected into all services (Frontend, Backend, Workers, Beat).
- Use Case: Database connection strings, Redis URLs, and core authentication secrets.
- Implementation: Defined in the primary Helm values or the main
/env.vm file.
Worker-Only Secrets
Inject secrets exclusively into the Noxus Workers.
- Use Case: Proprietary API keys for custom nodes, database strings for specific ETL flows, or credentials for internal tools.
- Benefit: Limits the “blast radius” by ensuring the web-facing frontend and backend never have access to these sensitive runtime credentials.
Pool-Specific Secrets (Kubernetes)
For advanced isolation, secrets can be injected into specific worker pools using envSecretRef.
- Use Case: A tenant-dedicated worker pool that needs its own LLM API keys, while the shared pool uses the platform defaults.
- Implementation: Set
worker.pools[<name>].envSecretRef in Helm values to the name of an additional K8s Secret. It is mounted after the shared secret, so its values override any overlapping keys.
See the Workers configuration guide for detailed examples.
Secrets injected into the worker environment are accessible from within the platform itself. Any workflow node, agent tool, or custom plugin running on a worker can read environment variables using the {{secret.MY_SECRET_NAME}} syntax in node configuration fields. This means you can add custom secrets (e.g., a third-party API key) to a worker’s environment and reference them directly from flows and agents without hardcoding credentials in the UI. When using pool-specific secrets via envSecretRef, only workers in that pool will have access to those values — other pools and services will not see them.
Rotation & Security Guidelines
- Regular Rotation: Rotate high-risk credentials (like API keys) on a 30-90 day schedule.
- Least Privilege: Only inject secrets into the specific services or worker pools that require them.
- Automated Reloads: In Kubernetes, use tools like
reloader to automatically restart pods when their underlying secrets are updated.
