Network and Security
Treat the proxy listener, admin listener, metrics endpoint, etcd, and managed Cloud connection as separate trust zones.
Network Surfaces
Use this map to decide what can be reachable from each network:
| Surface | What it carries | Exposure |
|---|---|---|
| Proxy listener | Caller-facing AI traffic, such as /v1/chat/completions | Intended callers or the ingress tier |
| Admin listener | Admin API, admin health, OpenAPI, playground, and sometimes metrics | Loopback, private subnet, or admin-only network |
| Metrics listener | Prometheus metrics when a dedicated listener is configured | Trusted monitoring network |
| Configuration store | Dynamic gateway resources in etcd for self-hosted deployments | AISIX and configuration-management systems only |
| Managed Cloud connection | mTLS-authenticated gateway communication with the AISIX Cloud control plane | Outbound mTLS path to AISIX Cloud control plane |
Expose only the proxy listener to callers. Keep admin, metrics, OpenAPI, playground, and etcd on private networks. Metrics endpoints are unauthenticated, whether they are served on the admin listener or on a dedicated listener.
Use TLS or mTLS where network placement requires encrypted or mutually authenticated transport. If etcd TLS is enabled, the startup configuration must point to certificate files that the gateway process can read.
Credential Boundaries
Caller API keys and upstream provider credentials have different storage and forwarding rules:
| Credential or Secret | How AISIX Uses It | Protect |
|---|---|---|
| Caller API key | Stored as a hash; plaintext is held by the calling application | Application secret storage and API key rotation workflow |
| Provider key | Used to authenticate upstream provider requests | Configuration store, admin access, and backups |
| Observability exporter credential | Sent to or resolved for the configured telemetry destination | Dynamic resource store and observability configuration access |
| Managed certificate bundle | Authenticates a managed gateway to AISIX Cloud | Runtime state directory, trust root, and managed bootstrap process |
In self-hosted deployments, provider credentials can live in the configuration store. OTLP HTTP exporter headers can be stored in dynamic configuration; object-storage, Aliyun SLS, and Datadog exporters use credential references that the gateway resolves locally. Treat etcd, backups, and the admin API access path as secret-bearing surfaces. In managed deployments, AISIX Cloud controls provider-key handling and projects runtime configuration into the managed gateway.
AISIX authenticates callers with caller API keys and authenticates upstream requests with provider credentials. Passthrough strips sensitive inbound headers by default. Provider-key strip settings can affect what is forwarded, so keep credential-bearing headers such as authorization, cookie, and x-api-key stripped unless a specific upstream integration requires otherwise.
Security Baseline
Confirm these controls before routing production traffic:
- The proxy listener is reachable only from intended callers or ingress.
- The admin listener is private in self-hosted deployments.
- Metrics endpoints are private.
- etcd is private, persistent, backed up, and access-controlled in self-hosted deployments.
- Provider-key secrets and exporter credentials are treated as sensitive operational data.
- Listener TLS, etcd TLS, or managed mTLS is configured where the deployment requires encrypted or mutually authenticated transport.
- Managed gateway identity is validated through the certificate-based bootstrap path.
- Backups and observability pipelines do not expose dynamic resource payloads or provider credentials.
Next Steps
You have now seen the network and credential boundaries to protect before exposing AISIX. Continue with TLS and mTLS for transport security.