security¶
LunarGate supports basic inbound API-key authentication configured in YAML. That is enough to protect trusted internal callers, but it is still not a full customer-facing auth edge.
Fields¶
| Field | Type | Notes |
|---|---|---|
enabled |
bool | master switch for inbound auth |
provider |
string | none, api_key, or external |
api_key.header |
string | optional override for the primary header; default is Authorization |
api_key.prefix |
string | optional override for the primary header prefix; default is Bearer |
api_key.allow_x_api_key |
bool | optional X-API-Key fallback; default is true |
api_key.keys |
list[object] | configured API keys with name and value |
external.* |
object | reserved structure for future external auth backends |
api_keys_enabled |
bool | deprecated compatibility field for legacy API-key mode |
api_keys |
list[string] | deprecated compatibility field for legacy key list |
Example¶
security:
enabled: true
provider: "api_key"
api_key:
keys:
- name: "dashboard"
value: "${LUNARGATE_CLIENT_API_KEY}"
external:
type: ""
jwks_url: ""
introspection_url: ""
issuer: ""
audience: []
timeout: 5s
OpenAI-compatible defaults¶
For API-key auth, you do not need to set header/prefix fields unless you want custom behavior.
With just security.provider: api_key and a key list, the gateway already accepts:
Authorization: Bearer <key>(OpenAI-style)X-API-Key: <key>(fallback, enabled by default)
Current reality¶
The gateway now has a basic inbound API-key layer, but it still does not expose a full, finished public multi-tenant auth edge.
In practice, you should still:
- run it inside a trusted network
- put it behind a reverse proxy, API gateway, or service mesh that enforces auth
- keep provider secrets in environment variables or a secret store
Why this page is still here¶
The security schema is intentionally broader than today's implementation. api_key works now, while external exists as the forward-compatible place for future JWT/JWKS, token introspection, or similar inbound auth integrations.