Why the Apache APISIX Admin API is the first thing to lock down
The Apache APISIX Admin API can change every route, plugin and credential in your gateway, so it must be restricted before go-live. By default it listens on 0.0.0.0:9180 under /apisix/admin, which means every network interface on the host accepts connections to it unless you change that. For a gateway team that needs operators to manage configuration without giving attackers the same reach, the first job is to decide who can reach that port at all and enforce the answer at the network layer, not only with credentials.
The deployment.admin.allow_admin list in the configuration file limits which client IP addresses the Admin API accepts. Treat it as a second control on top of network placement, not a replacement for it. Confirm the exact list format and any behavior behind a load balancer or proxy in the Admin API documentation, and test it from a host that is outside the allowed range before you rely on it. The Admin key also matters here: if admin_key is left empty, APISIX generates one at initialization and writes it back to the configuration file, so someone with read access to that file holds the key.
The Control API on port 9092 is a separate surface that the APISIX installation guide says should never be exposed publicly, and port 9180 should be restricted to operator networks. Map every listening port on each gateway node during the design phase, bind internal ports to private interfaces, and check the result from outside your network. Ask your platform team to confirm which of these ports are reachable from the internet, from partner networks and from other workloads in the same cluster.
Which access control fits each APISIX deployment mode
This table compares the access controls available for the Admin API and Control API across traditional, decoupled and standalone modes. Read each row as a control, then check which modes it applies to and when it is the right choice. The main takeaway is that the Admin API is only a runtime change path in modes that use it, so standalone and file-driven setups can shrink the exposed surface.
| Control | Traditional mode | Decoupled mode | Standalone mode |
|---|---|---|---|
| Explicit admin_key | Set a strong key in config before first start so it is not auto-generated | Set on the control plane node that serves the Admin API | Applies only if the Admin API is enabled for runtime changes |
| deployment.admin.allow_admin IP list | Limit port 9180 to operator subnets or bastion addresses | Limit the control plane Admin API to operator addresses | Use only if the Admin API stays enabled, otherwise leave it unused |
| Bind 9180 to a private interface | Keep the Admin API off public interfaces on every gateway node | Bind on the control plane only, not on data plane nodes | Bind only when the Admin API is in use |
| Bind 9092 (Control API) to a private interface | Never expose publicly; restrict to local or internal access | Keep the Control API on the control plane network only | Confirm with current docs whether the Control API is active in this mode |
| Bind 9091 (metrics) to a monitoring network | Allow only the Prometheus scraper or monitoring subnet | Restrict to monitoring subnet on both planes | Restrict to monitoring subnet |
| Separate operator network or bastion | Route all admin calls through a bastion with logged access | Recommended for the control plane, which holds the write path to etcd | Useful for change pipelines that push the YAML or JSON file |
| Admin API disabled for runtime changes | Not typical, since traditional mode relies on the Admin API for updates | Data plane nodes read from etcd and need no Admin API access | Configuration comes from conf/apisix.yaml or conf/apisix.json, so the Admin API can be left out of use |
| Best fit | Single cluster with frequent route changes by operators | Separate data plane fleets with central configuration | Git-driven configuration with a fixed set of routes |
How to set up Admin API and Control API access step by step
This sequence takes an Apache APISIX node from default listener settings to one where configuration endpoints accept only operator traffic from known networks. Each step ends with a check you can repeat after every change. Run it on a test node first, then apply the same settings to each gateway node in your environment.
Inventory listening ports and admin exposure
The platform engineer runs a listener inventory on each gateway node before changing anything. Record every port APISIX binds, including 9080 for client traffic, 9180 for the Admin API, 9092 for the Control API, 9091 for metrics and 2379 for etcd where it is used. Note the interface each one answers on, because the Admin API listens on 0.0.0.0:9180 by default. Done when you have a written list of each port, its current bind address and the networks that can reach it.
Set a deliberate admin key
The platform engineer sets admin_key in the deployment section of the config file to a value drawn from your secrets manager. If the field is left empty, APISIX generates a key at initialization and writes it back to the file, and the changelog records that 3.10.0 generates one when none is passed. A key you chose has a known origin and rotation path before the node serves any traffic. Check that a request without the key is rejected and a request with the stored key succeeds.
Protect the config file holding the key
The security engineer confirms that the config file is readable only by the account that runs APISIX and by the configuration management tooling that deploys it. Because APISIX can write a generated key back into that file, the file works as a credential store. Any step that copies it into a ticket, a container image layer or a shared repository exposes the key. Confirm file permissions with your operating system tools and confirm the file is excluded from version control. Done when a user outside the service account cannot read it.
Restrict allow_admin to operator networks
The network engineer sets deployment.admin.allow_admin to the address ranges your platform team uses for administration, for example a bastion or management subnet (illustrative). Keep the list short, reviewed and limited to operator ranges. Confirm the exact field path against the Admin API documentation for your version before editing. Check that a call from an address inside the list returns a response and a call from an address outside the list is refused.
Bind admin and control ports to private addresses
The platform engineer binds 9180, 9092 and 9091 to private interface addresses so they do not listen on public or load-balanced interfaces. The installation guide says port 9092 for the Control API should never be exposed publicly, and port 9180 should be restricted to operator networks. Use the listener or address settings for your deployment mode and confirm the exact keys in the installation guide for your version. Check that the listener inventory from the first step shows each port bound to a private address only.
Test refusal from outside networks
The security engineer tests from a host outside the operator and cluster networks, using the public address of each gateway node. Attempts to reach 9180, 9091 and 9092 should fail at the network layer or at the listener, and the test should be repeated from a second external segment if you have one. Record the time, source address and result of each attempt for your change record. Done when every admin, control and metrics port refuses the external connection and port 9080 still serves client traffic as designed.
Confirm schema validation requires the key
On APISIX 3.17.0 or later, the platform engineer confirms that the schema validation endpoint requires the admin key, as recorded in the APISIX changelog. Confirm the running version with your deployment tooling first, because this check only applies to that release or later. Send one request to the endpoint without the key and one with it from an operator network, then save both responses. Done when the request without the key is refused and the request with the key is accepted.
How the Admin API, Control API and etcd connect
Operator changes enter APISIX through the Admin API and are written to etcd, and every gateway node reads its configuration from there. In traditional mode, the data plane and control plane run in the same APISIX process, listen on the same host, and share the local view of configuration. The Admin API, served on port 9180 under /apisix/admin, accepts the route, upstream and plugin changes you make, and those changes land in the etcd cluster that APISIX uses as its configuration store. Anyone who can write to the Admin API can therefore change what every node will route and trust, which makes port 9180 the first control to confirm before go-live.
In decoupled mode, the control plane and data plane run as separate deployments that share one etcd cluster. Operators still talk to the Admin API on the control plane, the control plane writes to etcd, and the data plane nodes watch etcd and apply changes. The Control API on port 9092 is a different surface: it exposes internal state for the local instance and should never be reachable from outside the host or private network. Port 9091 carries metrics and port 2379 carries etcd client traffic, so you should treat 2379 as part of the same boundary as 9180 and 9092. Confirm which addresses each port binds to in your own configuration, and confirm which hosts can reach etcd at all, because a data plane node that can write to etcd can change the configuration of the whole fleet.
The trust boundary therefore runs around the etcd cluster and the Admin API, not only around the public listener on port 9080. Restricting deployment.admin.allow_admin to operator addresses, binding the management ports to private interfaces and setting a strong admin key all protect the write path. Encrypting and authenticating the connections between components is a separate, deeper control. The mTLS certificates for the Admin API and etcd clients are covered in the sibling topic on securing etcd and the Admin API with mTLS, so this page stops at identifying which connections must be protected and who is allowed to make them.
Security risks that come from exposed configuration endpoints
The Admin API, Control API and metrics port each accept or expose something an attacker wants: routes, upstreams, plugin settings and credentials. The cards below cover the main ways these endpoints get exposed and the control and check that addresses each one. Work through them together, because a single weak port or a leaked key can undo the others.
Admin API reachable with a default or known key
Port 9180 serves the Admin API under /apisix/admin and listens on 0.0.0.0 by default, so anyone who can reach it and present a valid key can rewrite routes and plugins. Bind the Admin API to an operator network, and set a long, unique admin_key rather than relying on any shipped value. Verify from outside the gateway's network that a request to port 9180 times out, and that a request with a wrong key is rejected.
Allow list left open
The deployment.admin.allow_admin setting limits which client IP addresses may call the Admin API. Teams often leave it at a broad range during setup and never narrow it, so a whole subnet or the internet can reach the API. Restrict the list to the addresses of your automation runners and administrator jump hosts. Verify the list in the rendered configuration on every node, not only in the template.
Control API exposed beyond the cluster
The Control API on port 9092 is used by the gateway for internal control functions and should never be reachable from outside. A public load balancer, a permissive security group or a Kubernetes Service of type LoadBalancer can publish it by accident. Bind it to the loopback or pod-internal interface and block it at the network edge. Verify with a scan from an external host that port 9092 is closed on every public address.
Metrics endpoint open on 9091
Port 9091 serves metrics that reveal route names, upstream health, traffic volumes and plugin usage, which helps an attacker map your API surface. Scrape it only from your monitoring system's address range, and keep it off public interfaces. Verify that your Prometheus scrape job is the only client allowed by network policy, and confirm that dashboards and alert sources do not publish the endpoint through another proxy.
Admin keys leaked in files and logs
Admin keys written into conf/config.yaml, Helm values, pipeline variables or deployment scripts tend to spread into version control, build logs and chat threads. If admin_key is left empty, APISIX generates one at initialization and writes it back to the config file, so that file needs the same protection as the key. Store the key in your secrets manager, inject it at runtime, and check that CI logs and repository history contain no copies.
Lockdown drift between environments
A tight configuration in staging can differ from production after a hotfix, a Helm upgrade or a manual edit to the config file. Settings such as the bound address of port 9180, the allow list and the key requirements that arrived in later releases, including the schema validation endpoint key requirement from 3.17.0, may not apply everywhere. Keep the Admin API settings in version-controlled templates, and run the same port and key checks in every environment after each rollout.
Questions teams ask before locking down the APISIX Admin API
What does locking down the APISIX Admin API cost, and what drives the effort?
The cost depends on how many gateway clusters you run, how your network is segmented, and how many people change routes today. Most of the work is one-time: setting admin keys, restricting the allow_admin list, binding ports 9180, 9092 and 9091 to private networks, and checking that nothing public reaches them. Recurring cost comes from key rotation, access reviews and upgrades. Ask any partner for a quote that separates these items, names who performs each step, and lists what you must supply. A written scope is the basis for any figure, and DeployOpen quotes follow from that scope.
How long does a hardening pass take for our environment?
Duration follows environment size and complexity: the number of gateway nodes, whether you run traditional, decoupled or standalone mode, how many teams hold admin access, and whether your load balancers and firewalls can be changed quickly. A single cluster with clear network ownership moves much faster than several clusters spread across cloud accounts and data centers. Ask for a timeline in the written scope with milestones for network changes, key handling, testing and go-live. Do not accept a duration that is not tied to a list of named environments.
What must our internal team provide before the work starts?
Your team provides three things: current network diagrams showing where the gateway, etcd and operator workstations sit; a named list of people and automation accounts that need Admin API access; and a decision on where admin keys will be stored, such as a secrets manager you already operate. You should also confirm which change windows apply and who approves firewall rule changes. Gaps in these inputs are the most common reason hardening slips, so agree on owners before scope is signed.
Can our engineers lock down the Admin API themselves using the official docs?
Yes, many teams do, and the official Admin API documentation and installation guide describe the settings involved. The risk lies in the details: a generated admin key written back to the config file, an allow_admin list that is wider than intended, or a port bound to an interface that a load balancer can reach. An internal team should verify each setting against a test plan, document the result and repeat the check after every upgrade. If your staff lack time or experience with these controls, a fixed-scope engagement can cover the build and the verification.
What changes when we upgrade to APISIX 3.17.0 or later?
From 3.17.0, the schema validation endpoint requires the admin key, so scripts or CI jobs that call it without credentials will fail. Check every pipeline, health probe and tool that validates configuration before the upgrade. Also review how your admin key is generated and stored, since APISIX 3.10.0 generates the key automatically when none is passed. Test the upgrade in a non-production environment, confirm that automation still authenticates, and record the results before you schedule the production change.
How do we verify the lockdown before go-live?
Verification should prove that the controls work from the networks you intend to block. Test that port 9180 answers only from operator networks, that port 9092 is unreachable from outside the control network, that port 9091 is restricted to your metrics collector, and that requests from addresses outside allow_admin receive no access. Confirm that the admin key is not present in plain text in shared locations, and that changes made through the Admin API are logged. Keep the test results as evidence. Auditors and certification bodies decide whether your controls meet a standard, so check the requirements with them.
Does locking down the Admin API affect running traffic?
Client traffic on port 9080 is not changed by restricting the Admin API, but the operations that depend on port 9180 are. Route changes made by pipelines, dashboards or ingress controllers will stop working if their source addresses fall outside the new allow list. Map every caller before you change the bindings. Plan a rollback path for each change, and confirm which tools reach the Admin API through a proxy or service account.
Keeping the lockdown in place after go-live
Locking down the Admin API and Control API is not a one-time configuration task. The controls drift as operator networks change, as new nodes are deployed and as upgrades reset or reshape listeners, so the recurring checks matter as much as the initial build. Plan a key rotation procedure for the Admin API key in config.yaml under deployment.admin.admin_key, with a named owner, a change window and a step that updates every operator tool and automation pipeline that uses it. Confirm the exact rotation steps and any rolling-restart requirements against the Admin API documentation for the version you run, because the key is also read by the schema validation endpoint in 3.17.0 and later.
Treat deployment.admin.allow_admin as a living list. Each time a VPN range, bastion host, CI runner subnet or management VLAN changes, the list should be reviewed against the actual sources of Admin API calls. After every upgrade, new Helm release or new data plane node, check that ports 9180, 9092 and 9091 still bind to the private interfaces you intended and are not reachable from public addresses. A simple scripted probe from outside the operator network, run on a schedule, gives you evidence that the bindings hold rather than an assumption that they do.
Auditing route changes is the control most teams skip. Record who changed a route, upstream, consumer or plugin configuration, when, and through which path, and confirm that changes arrive through approved channels such as version-controlled configuration rather than ad hoc calls. Keep the outputs of the checks above, the rotation records, the allow list history and the change logs together in a place reviewers can reach. DeployOpen prepares these controls and the evidence that shows they operate, but independent auditors are the ones who give an assurance opinion on them, so agree with your assessor early which artifacts they will expect and how often.
