Skip to main content

Environment-Specific Secret Values

Use a single secret with different values for each environment. KnoxCall automatically uses the correct value based on the route’s active environment—no manual switching required.

The Problem

Traditional approach requires separate secrets per environment:
Problems:
  • Accidental use of production keys in staging
  • Manual route config updates when switching environments
  • Difficult to audit which env uses which key
  • Secret sprawl (3x secrets)

The Solution

One secret, multiple environment-specific values:
Benefits:
  • ✅ Automatic environment-based resolution
  • ✅ Hard fail if environment value missing (prevents accidents)
  • ✅ Simplified route configuration
  • ✅ Clear audit trail per environment

How It Works

Step 1: Create Secret

Create a secret normally:
Leave the initial value empty—we’ll set environment-specific values next.

Step 2: Configure Environment Values

In the secret detail page:
  1. Select environment from dropdown (top right)
  2. Enter value for that environment
  3. Save
  4. Repeat for other environments
Example:

Step 3: Reference in Route

Use the secret in your route config:

Step 4: Automatic Resolution

When a request comes in:
If route is in staging environment:

Hard Fail Behavior

Safety feature: If a secret lacks a value for the requested environment, the request fails immediately.
The detailed reason — Secret 'stripe_api_key' (<id>) has no value configured for environment 'development' — is recorded server-side in the request log (api_requests.error), not returned to the caller. Error responses are normalized so callers can’t enumerate tenant or secret configuration from the status code or message.
Why no fallback?
  • Prevents accidental production key usage in dev/staging
  • Forces explicit configuration
  • Makes missing config obvious during testing
  • Complies with principle of least privilege
Solution: Add the missing environment value or change route’s active environment.

Supported Secret Types

Environment-specific values work with all secret types:

String Secrets

OAuth2 Secrets

Certificate Secrets (mTLS)

Advanced Usage

Partial Environment Coverage

You can configure only the environments you need:

Duplicating Environments

Clone an existing environment’s value:
  1. Go to secret detail page
  2. Select source environment (e.g., “production”)
  3. Click Duplicate to another environment
  4. Choose target environment (e.g., “staging”)
  5. Modify the duplicated value if needed
  6. Save
Use case: Copy production config to staging, then change specific values.

Deleting Environment Values

Protected deletion: Cannot delete an environment value if any route is actively using it in that environment.
Solution:
  1. Switch routes to different environment, OR
  2. Update routes to use different secret, OR
  3. Delete the routes first

Viewing All Environments

In the secret detail page, see all configured environments at a glance:

API Reference

Get Secret Environments

Note: Values are never returned via API for security.

Create/Update Environment Value

Delete Environment Value

Duplicate Environment

Migration Guide

From Naming Convention to Environment Configs

Before:
After:
Steps:
  1. Create new secret: stripe_api_key (no initial value)
  2. Copy values:
    • Environment: production → Paste value from stripe_production_key
    • Environment: staging → Paste value from stripe_staging_key
    • Environment: development → Paste value from stripe_development_key
  3. Update routes:
    • Change {{secret:stripe_production_key}} to {{secret:stripe_api_key}}
    • Remove environment-specific references
  4. Test in staging first
  5. Deploy to production
  6. Delete old secrets after 48 hours

Best Practices

✅ Do This

  1. Use environment configs for new secrets
    • Simpler, safer, better audit trail
  2. Configure all environments you use
    • Don’t leave gaps (hard fail protects you)
  3. Test in staging first
    • Verify correct values loaded per environment
  4. Use descriptive names
    • stripe_api_key not secret_42
    • Easier to manage across environments
  5. Document your environments
    • Keep a list of which environments exist
    • Standard: production, staging, development

❌ Avoid This

  1. Don’t mix approaches for same service
    • Either use env configs OR naming convention
    • Don’t use both for Stripe (confusing)
  2. Don’t delete environment values carelessly
    • Check if routes are using them first
    • System prevents deletion, but verify manually
  3. Don’t share values across environments
    • Never use production keys in staging
    • Even if system allows it, don’t do it
  4. Don’t skip testing after migration
    • Always test in dev/staging first
    • Verify hard fail works as expected

Troubleshooting

”Secret not configured for environment”

Problem:
Solutions:
  1. Add the missing environment value
  2. Change route’s active environment
  3. Use a different secret that has the environment

Can’t delete environment value

Problem:
Solution:

Environment dropdown not showing

Problem: Can’t see environment selector in secret detail page Possible causes:
  1. Secret type doesn’t support environments (shouldn’t happen - all types do)
  2. Browser cache issue - hard refresh (Ctrl+F5)
  3. Old UI version - ensure admin-ui is up to date
Solution:

Wrong value being used

Problem: Route in staging is using production value Debug steps:
  1. Check route’s active environment (top right dropdown)
  2. Verify secret has value for that environment
  3. Check route config uses correct secret name
  4. Test with a different route
Common cause: Route’s active environment is set to “production” even though you think it’s staging.

Security Considerations

Encryption

All environment values are encrypted individually:

Audit Trail

Every environment value change is logged:

Access Control

  • Only tenant admins can view/edit secret environment configs
  • The client API requires a KnoxCall API key / access token (Authorization: Bearer <api_key> or the x-api-key header), not a session JWT
  • No way to retrieve values via API (write-only)
  • Environment values never logged or transmitted in plaintext

Compliance

Environment-specific secrets help with:
  • PCI DSS: Separate production and test credentials
  • SOC 2: Audit trail of secret changes per environment
  • GDPR: Environment isolation for data protection
  • HIPAA: Segregation of production and non-production

Next Steps

Creating Secrets

Learn how to create secrets in KnoxCall

Using Secrets in Routes

Reference secrets in route configurations

Environment Basics

Understand KnoxCall environments

Secret Rotation

Best practices for rotating secrets

📊 Guide Info

  • Level: Intermediate
  • Time: 10 minutes
  • Prerequisites: Basic understanding of secrets and environments

🏷️ Tags

secrets, environments, configuration, security, credentials