Skip to main content

​
Authentication

Reducto on-premise should run behind your private network boundary and should be called only by trusted services. Authentication protects access to the deployment, but Reducto does not provide per-end-user authorization inside a single on-premise tenant. Review the on-prem security model before exposing Reducto to additional services or networks. Reducto can read one or more tokens used for authenticating API calls from a file. On Kubernetes, a Secret can be mounted as a file in the http Pod - when this Secret is updated, Kubernetes automatically updates the mounted file using an eventually-consistent approach, allowing Reducto to reload the new value without requiring a restart. Multiple API keys can be specified by placing each key on a separate line. This enables progressive secret rotation: add the new key, roll your clients over, then remove the old key, all without downtime.
Enable API authentication for production on-premise deployments. If you need different permissions for different users, applications, or business units, enforce those permissions in your gateway or run separate Reducto deployments.

​
Overview

When enabled, Reducto reads the authentication secret from a mounted file specified by the AUTH_SECRET_PATH environment variable. This provides better security isolation and follows Kubernetes best practices for secret management.

​
Setup instructions

You can set up authentication using either manual secret creation or secret creation via Helm Chart.

​
Option 1: Manual secret creation

1. Create a Kubernetes secret
First, create a Kubernetes secret containing your API key(s). For a single key: 
kubectl create secret generic reducto-auth-secret \
  --from-literal=secret=your-api-key-here \
  --namespace reducto
For multiple keys (e.g., during rotation), separate them with newlines: 
kubectl create secret generic reducto-auth-secret \
  --from-literal=secret=$'current-key\nnew-key' \
  --namespace reducto
2. Configure Helm values
Add the following configuration to your Helm values file: 
auth:
  secretPath:
    enabled: true
    secretName: "reducto-auth-secret"
    mountPath: "/etc/auth"
    filename: "secret"

​
Option 2: Secret creation via Helm Chart

1. Configure values for creation via Helm Chart
Add the following configuration to your Helm values file to let the Helm chart create the secret: 
auth:
  secretPath:
    enabled: true
    createSecret: true
    apiKey: "your-api-key-here"  # Must specify when createSecret is true.
    secretName: "reducto-auth-secret"
    mountPath: "/etc/auth"
    filename: "secret"
Note: With createSecret: true you must specify apiKey

​
2. Deploy Reducto (for both options)

Deploy or upgrade your Reducto installation: 
helm upgrade --install reducto oci://registry.reducto.ai/reducto-api/reducto \
  --namespace reducto \
  --values your-values.yaml

​
Configuration options

ParameterDescriptionDefault
auth.secretPath.enabledEnable file-based authenticationfalse
auth.secretPath.createSecretCreate the Kubernetes secretfalse
auth.secretPath.apiKeyAPI key, must be specified when createSecret: true-
auth.secretPath.secretNameName of the Kubernetes secret"reducto-auth-secret"
auth.secretPath.mountPathMount path for the secret file"/etc/auth"
auth.secretPath.filenameFilename within the secret"secret"

​
How it works

  1. When auth.secretPath.enabled is true, the Helm chart mounts the specified secret as a volume
  2. The AUTH_SECRET_PATH environment variable is automatically set to the full file path
  3. Reducto’s authentication middleware reads all keys from the file (one per line) and authenticates API requests against any of them
  4. The file is monitored for changes, supporting secret rotation without restarts
  5. If the provided API key doesn’t match any key in the file, a 401 error is returned

​
Secret rotation

To rotate keys without downtime:
  1. Add the new key on a new line alongside the existing key
  2. Update the Kubernetes secret (Reducto picks up the change automatically)
  3. Migrate your clients to use the new key
  4. Remove the old key from the secret

​
Network access

Do not expose Reducto directly to the public internet. Put the API behind an internal load balancer, private ingress, service mesh, or API gateway that matches your organization’s access policy. Restrict access to:
  • Reducto API endpoints, including /job, /jobs, /upload, /cancel, /configure_webhook, and billing export endpoints
  • Metrics and Prometheus endpoints
  • PostgreSQL, Redis, object storage, model services, and observability UIs
If users or browser clients need to initiate work, route them through your own application backend. That backend should authenticate the user, authorize the workflow, and then call Reducto as a trusted service.