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, and playground	Loopback, private subnet, or admin-only network
Metrics listener	Prometheus metrics	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 and served on the dedicated metrics 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.

Binding Privileged Ports (80/443)

The AISIX container image runs as a non-root user (UID 10001) and grants the gateway binary the CAP_NET_BIND_SERVICE file capability — the same capability Kubernetes securityContext fields spell NET_BIND_SERVICE, without the CAP_ prefix — so listeners can bind privileged ports such as 80 and 443 without running the container as root. This works the same in plain Docker and in Kubernetes, including hostNetwork: true pods that expose the proxy directly on the node:

# Pod spec excerpt: proxy listener on node port 80 via host network
spec:
  hostNetwork: true
  containers:
    - name: aisix
      image: api7/aisix
      # config mounts proxy.addr: "0.0.0.0:80"

NET_BIND_SERVICE is part of the default capability set of Docker and containerd, so no extra settings are needed in a default deployment. If your pod security context drops all capabilities, add NET_BIND_SERVICE back — otherwise the container fails at startup with exec: Operation not permitted: the binary carries the file capability with the effective bit set, so the kernel refuses to execute it when the capability cannot be granted, rather than running it without the capability:

securityContext:
  capabilities:
    drop: ["ALL"]
    add: ["NET_BIND_SERVICE"]

This is compatible with the restricted Pod Security Standard, which permits adding back exactly NET_BIND_SERVICE. If you only need the gateway reachable on port 80 of the node rather than full host networking, a hostPort: 80 mapping to the container's regular proxy port avoids binding a privileged port inside the container.

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.