Security best practices

Read this before you expose Vikat to the internet. Vikat includes secure defaults, but a public deployment is only as safe as the controls you actually turn on. By default the dashboard and inference endpoints are reachable by anyone who can route to the host. The items below are the minimum hardening for any gateway that is reachable from outside your private network.

Most of these controls live on the Security Settings page in the dashboard at /workspace/config/security, or in your config.json (inference and CORS controls under the client block; dashboard credentials under governance.auth_config). The rest live in the reverse proxy in front of Vikat.

0. Read the startup security report

You do not have to audit this from memory. On every start, Vikat inspects its own resolved configuration — after config.json, the configuration store and the built-in defaults have been merged — and reports each permissive setting that is actually in effect. Each one is written as a WARN log line and repeated in a console banner, naming the setting, what it exposes, and the exact configuration that closes it:

security posture: client.enforce_auth_on_inference (false) — inference endpoints answer without a
virtual key, API key or user token. Anyone who can reach this port can spend your provider credits
and reach every model you have configured. Fix: "client": {"enforce_auth_on_inference": true}

The report covers governance.auth_config.is_enabled, client.enforce_auth_on_inference, the field encryption key, client.disable_content_logging and client.allowed_origins. A gateway with all five closed prints nothing, so the report is also the quickest confirmation that your hardening took effect. There is no flag to suppress it — the way to silence the warning is to fix the setting.

These defaults are permissive and they have not changed. Turning one on in a release would stop existing deployments answering, so Vikat reports the exposure rather than changing behaviour under you. Nothing in this report alters how the gateway runs.

1. Use a strong dashboard password

The dashboard can be protected with Password protect the dashboard on the Security Settings page (an admin username + password). Anyone who reaches the dashboard URL without credentials can read configuration, virtual keys, and logs, so this is the first thing to turn on for a public host.

Password policy is enforced starting OSS v1.6.0 and Enterprise v1.5.0. On these versions Vikat validates the password both in the UI and on the server before saving, and rejects weak values with HTTP 400. On earlier versions there was no strength check at all. If you are running an older build, choose a strong password manually (and upgrade as soon as you can).

The enforced policy requires every dashboard password to have:

At least 12 characters
At least one uppercase letter
At least one lowercase letter
At least one number
At least one special character

{
    "auth_config": {
      "is_enabled": true,
      "admin_username": "admin",
      "admin_password": "env.VIKAT_ADMIN_PASSWORD"
    }
}

Reference the password from an environment variable or secret (env.VAR_NAME) instead of hardcoding a literal value in config.json. Env/secret references are stored as-is; literal passwords are hashed before storage.

For Enterprise deployments, prefer SSO / OIDC over a shared dashboard password so every operator who can change configuration is a known, traceable identity. See the security hardening guide and the SSO setup guides (Okta, Entra, Keycloak, Zitadel, Google Workspace).

2. Enforce authentication on inference

By default, inference endpoints (/v1/chat/completions, /v1/embeddings, /v1/images/generations, and related endpoints) accept anonymous requests. On a public host that means anyone who finds the URL can spend against your provider keys. Turn on the Enable Auth on Inference toggle on the Security Settings page (labeled Enforce Virtual Keys on Inference in OSS). This requires every inference call to present a valid credential, such as a Virtual Key, API key, or user token, which Vikat resolves to scoped upstream provider keys. Your raw provider keys never leave the gateway.

{
  "client": {
    "enforce_auth_on_inference": true
  }
}

This is the main setting. The older fields enforce_governance_header and enforce_scim_auth are deprecated. Don’t use them in new deployments. Changing this setting requires a Vikat restart in Enterprise.

Once enforced, pair it with budgets and rate limits per virtual key so a runaway client can’t burn through your provider spend even with valid credentials.

3. Review the rest of the Security Settings page

The Security Settings page (/workspace/config/security) exposes several more controls worth checking before going public:

Setting	Config key	Recommendation for public hosts
Allow Direct API Keys	`allow_direct_keys`	Keep off (default). When on, callers can pass their own provider key in a header (`x-vikat-direct-key: true`), bypassing your registered key pool.
Allowed Origins	`allowed_origins`	Set an explicit list. Never `*` in production. A wildcard lets JavaScript from any page on the internet call your gateway.
Allowed Headers	`allowed_headers`	Narrow to the minimum your callers need (e.g. `Authorization`, `Content-Type`, your virtual-key and tracing headers).
Required Headers	`required_headers`	Optionally require headers on every request; missing ones are rejected with 400.
Whitelisted Routes	`whitelisted_routes`	Only add routes that must bypass auth. System routes (`/health`, login, etc.) are always whitelisted.

{
  "client": {
    "allow_direct_keys": false,
    "allowed_origins": [
      "https://app.example.com",
      "https://internal-dashboard.example.com"
    ],
    "allowed_headers": ["Authorization", "Content-Type", "X-Request-Id"]
  }
}

Changing allowed_origins or allowed_headers requires a Vikat restart to take effect.

Enterprise deployments should also tighten the provider-forwarded x-vikat-eh-* header allowlist (header_filter_config). See Tighten both header allowlists for details.

4. Terminate TLS and serve from a reverse proxy

Never expose Vikat’s HTTP port directly to the internet. Put a reverse proxy (NGINX, an Ingress controller, or a cloud load balancer) in front of it to terminate TLS, so all traffic, including dashboard logins, virtual keys, and prompts, is encrypted in transit. See the Nginx reverse proxy guide for streaming-safe proxy settings, and bind Vikat itself to an internal interface so it is only reachable through the proxy.

5. Send security headers from the reverse proxy

Add hardening response headers at the proxy layer to defend the dashboard against clickjacking, MIME sniffing, and protocol downgrade. Vikat is served behind the proxy, so this is the right place to set them once for every response.

NGINX
Kubernetes (NGINX Ingress)

server {
    listen 443 ssl;
    server_name vikat.example.com;

    # Force HTTPS for one year, including subdomains
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # Clickjacking / iframe embedding protection
    add_header X-Frame-Options "DENY" always;
    add_header Content-Security-Policy "frame-ancestors 'none'" always;

    # Block MIME-type sniffing
    add_header X-Content-Type-Options "nosniff" always;

    # Limit referrer leakage
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    location / {
        proxy_pass http://vikat_backend;
        # ... streaming-safe proxy settings (see nginx guide)
    }
}

ingress:
  enabled: true
  className: nginx
  annotations:
    nginx.ingress.kubernetes.io/configuration-snippet: |
      more_set_headers "Strict-Transport-Security: max-age=31536000; includeSubDomains";
      more_set_headers "X-Frame-Options: DENY";
      more_set_headers "Content-Security-Policy: frame-ancestors 'none'";
      more_set_headers "X-Content-Type-Options: nosniff";
      more_set_headers "Referrer-Policy: strict-origin-when-cross-origin";

Header	Protects against
`Strict-Transport-Security`	Protocol downgrade / SSL-stripping attacks
`X-Frame-Options` / `Content-Security-Policy: frame-ancestors`	Clickjacking and embedding the dashboard in a hostile iframe
`X-Content-Type-Options: nosniff`	MIME-type sniffing
`Referrer-Policy`	Leaking dashboard URLs to third-party sites

Use the always flag (NGINX) so headers are sent even on error responses. Only enable HSTS once you are confident HTTPS will stay on. Browsers cache it for the full max-age.

6. Restrict network exposure

Network-level controls limit the impact of a misconfiguration:

Don’t publish the raw container port. Expose only the reverse proxy; keep Vikat on an internal network or localhost upstream.
Firewall / security groups. Allow inbound traffic only on 443 (and 80 for the ACME/HTTP-to-HTTPS redirect). Block everything else.
Restrict the admin surface. If only your team needs the dashboard, put it behind a VPN, an IP allowlist, or an identity-aware proxy rather than the open internet.
Run as non-root. The official vikat/vikat-gateway image already runs as an unprivileged user. Keep it that way and avoid mounting host paths writable.

Hardening checklist

Startup security report is silent

Restart the gateway and check the logs: no security posture: lines means nothing on this list is still open.

Strong dashboard password (or SSO)

12+ chars with mixed case, number, and symbol. Upgrade to OSS v1.6.0 / Enterprise v1.5.0+ so the policy is enforced.

Auth enforced on inference

enforce_auth_on_inference: true: no anonymous path to a model.

Direct API keys disabled

allow_direct_keys: false unless you have a specific reason.

CORS locked to your origins

Explicit allowed_origins, never * in production.

TLS terminated at a reverse proxy

No raw HTTP port exposed to the internet.

Security headers set at the proxy

HSTS, frame-ancestors / X-Frame-Options, nosniff, Referrer-Policy.

Budgets and rate limits configured

Per-virtual-key limits before the first real request.

Network exposure minimized

Firewall to 443, admin surface behind VPN/allowlist where possible.

Nginx reverse proxy
Enterprise security hardening
Virtual keys
Budgets and limits
Security at Vikat: how Vikat itself is built and scanned

Platform specific guides

Config as Code

Enterprise Deployment

Common setup instructions

Security best practices

0. Read the startup security report

1. Use a strong dashboard password

2. Enforce authentication on inference

3. Review the rest of the Security Settings page

4. Terminate TLS and serve from a reverse proxy

5. Send security headers from the reverse proxy

6. Restrict network exposure

Hardening checklist

​0. Read the startup security report

​1. Use a strong dashboard password

​2. Enforce authentication on inference

​3. Review the rest of the Security Settings page

​4. Terminate TLS and serve from a reverse proxy

​5. Send security headers from the reverse proxy

​6. Restrict network exposure

​Hardening checklist

​Related guides

0. Read the startup security report

1. Use a strong dashboard password

2. Enforce authentication on inference

3. Review the rest of the Security Settings page

4. Terminate TLS and serve from a reverse proxy

5. Send security headers from the reverse proxy

6. Restrict network exposure

Hardening checklist

Related guides