Why Apache APISIX security hardening goes beyond changing one key
Hardening an Apache APISIX gateway before it faces internet or partner traffic means controlling four things: who can reach the control surface, what the data plane will accept, how client traffic and etcd are protected, and how every configuration change is recorded. In traditional mode, the Admin API on port 9180 can create or change routes, plugins and upstreams, so anyone who reaches it effectively controls the gateway. Changing the default Admin API key is one step in that work, not the work itself.
Why it is harder than it looks: APISIX is built on NGINX and etcd, and configuration and plugins hot-load without a restart. A change made through the Admin API takes effect quickly, and it is stored in etcd, so a weakness in either layer affects live traffic. The project documents more than 100 built-in plugins covering authentication, security, traffic control and observability. Each enabled plugin adds configuration surface, and each one needs a decision about whether it belongs in production at all.
The same control also differs by deployment mode. In traditional mode, the Admin API and client traffic listen on separate ports (9180 and 9080 by default), and the Admin API must be kept off public networks. In decoupled mode, the data plane and control plane share one etcd cluster, so etcd access and authentication become a boundary between the two planes. In standalone mode there is no etcd, and the configuration file or API is the control point, with the file checked every second for changes. Your hardening checklist must be written for the mode you run.
Confirm the defaults before you rely on them: the facts available for this page do not state default values for the Admin API key, the TLS settings, the etcd authentication options or the audit logging behavior. Check the configuration reference and the release notes for the exact version you plan to deploy, including the default key in the shipped configuration file and whether the Admin API accepts requests from all addresses by default. Record the results in your build standard so the next upgrade can be checked against it.
Ask your team or partner to produce a short written baseline before go-live: the Admin API listener and its network path, the key and role management approach, the plugins enabled on each route, the etcd access model, and where change logs are sent. Each item should name an owner and a verification step. The sections that follow cover these controls one by one, so the baseline gives you a way to see which ones your environment already meets and which need work.
Which Apache APISIX components need hardening
These six surfaces are where an Apache APISIX gateway can be changed, reached or bypassed. Most exposure comes from the links between them: an open Admin API can rewrite plugins, an unprotected etcd cluster can rewrite routes, and weak credentials can satisfy every authentication check. Work through them in the order a request or a configuration change travels.
Admin API on port 9180
In traditional mode, the Admin API listens on port 9180 and accepts changes to routes, upstreams, consumers and plugins. Anyone who reaches it with a valid key can reroute production traffic or disable a security plugin, which makes it the most sensitive surface on the gateway. Check that it binds only to a management network, that access is limited to named administrators and automation, and that the port is not exposed through a public load balancer or ingress. Confirm the listen address and access control settings for your version in the deployment documentation.
Client traffic on port 9080
Port 9080 carries client requests to the routes you publish, so it is the surface exposed to consumers, partners and the internet. Without TLS, requests and tokens cross the network in clear text, and a route without an authentication plugin passes traffic straight to its upstream service. Decide which routes are public, enforce HTTPS on them, and confirm how your cloud load balancer or firewall forwards traffic to the gateway. Confirm in the current documentation how TLS listeners and mutual TLS are configured for this port.
etcd cluster that stores configuration
In traditional and decoupled modes, etcd holds the route, consumer and plugin configuration that APISIX loads. Anyone who can write to etcd can change gateway behavior without passing through the Admin API, and lost etcd data removes the configuration unless it has been backed up. Restrict client and peer access with authentication and TLS, keep the cluster off public networks, and test restoring from backup. Standalone mode removes etcd but moves configuration into a file that needs its own access control and version control. Confirm etcd settings against the APISIX and etcd documentation for your versions.
Admin and consumer credentials
Admin keys grant control of the gateway, and consumer credentials identify each API client to authentication plugins such as key-auth or jwt-auth. The default admin key shipped with the project must be replaced before any environment is reachable from a network. Exposure happens when keys are shared across teams, stored in configuration files or repositories, or never rotated after staff changes. Set a rotation process, store secrets in your secrets manager, and give each consumer its own credential so one leak can be revoked alone. Confirm the exact key settings for your version.
Authentication and security plugins
APISIX documents more than 100 built-in plugins, and the ones that enforce identity and access decide what reaches your upstream services. Options named in the documentation include openid-connect, key-auth, jwt-auth, basic-auth, ldap-auth, forward-auth and multi-auth, along with IP restriction and WAF-related plugins. Exposure comes from a route with no authentication plugin, a plugin left in a permissive setting, or a control tested on some routes but not others. Map each route to its intended control and confirm exact plugin names and settings in the current plugin documentation.
Audit trail
An audit trail records who changed routes, consumers and plugins, when the change happened, and from where. Without one, an unexpected route change or a disabled security plugin is hard to attribute or reverse. Check which logging plugins and log destinations your version supports, whether Admin API calls are logged, and whether logs are shipped to storage that administrators cannot edit. Confirm retention periods against your own compliance obligations. Test by making a controlled change and confirming the record appears where your team will look.
Which deployment mode and admin access model fit your risk
This table compares the three APISIX deployment modes and four ways to control access to the Admin API, showing when each fits and what it costs to run. Read each row against your own exposure model: the mode determines where the Admin API lives, and the access model determines who can reach it.
| Option | When it fits | Operational cost | Hardening implication |
|---|---|---|---|
| Traditional mode | Small or single-site gateways where one team owns both data and control planes and a single cluster is acceptable | Admin API on port 9180 runs on the same nodes that serve client traffic on port 9080, so node hardening and Admin API hardening are coupled | Admin API must be firewalled, bound to a management interface or fronted by a restricted path, and default keys replaced before exposure |
| Decoupled mode | Multi-site or high-traffic estates that need control plane changes isolated from data plane nodes | Separate data plane and control plane to run, plus one shared etcd cluster that needs its own authentication, TLS and backup | Data plane nodes can be kept free of the Admin API; etcd becomes the critical trust boundary and must be locked down |
| Standalone mode | Fixed, low-change routing where configuration is versioned in Git and rolled out through your existing pipeline | No etcd to operate, but live API-driven change is lost; every change is a file edit that APISIX picks up on its one-second check | Smaller control surface and no etcd exposure; file integrity, access to the config file and the rollout pipeline become the controls to harden |
| Admin API on a management network or bastion | Teams with an established management plane and privileged access paths who need administrative changes kept off user networks | More network paths to design, monitor and document, plus jump host patching and access logging | Strongest fit for traditional mode; restrict source addresses and require authenticated access to the bastion |
| Admin API behind an internal load balancer | Organizations that already standardize on internal load balancers and want one controlled entry point for administrative calls | Load balancer rules, health checks and TLS termination must be managed and kept aligned with APISIX version changes | Does not replace authentication; the Admin API key and TLS still need to be enforced at the APISIX layer |
| Admin API kept off the data plane altogether | Decoupled or standalone deployments where gateway nodes should never serve administrative endpoints | Requires decoupled mode with a control plane, or a configuration pipeline in standalone mode; more components to size and monitor | Removes the Admin API from internet-facing nodes entirely, which narrows the attack surface most directly |
| etcd authentication and TLS | Decoupled and traditional deployments that keep configuration in etcd | Certificate issuance, rotation and etcd user management add recurring work to the platform team | Confirm supported etcd authentication settings for your APISIX version with the official documentation before relying on them |
How to lock down the Admin API on port 9180, step by step
This sequence takes an Apache APISIX gateway from its default state to one where the Admin API on port 9180 is reachable only from approved management hosts, authenticates with a unique credential, and records every change. Each step ends with a check you can repeat, so the result is evidence that the controls work.
Inventory listening ports and who reaches them
Before changing anything, list every port the gateway nodes and their etcd members listen on, including 9080 for client traffic and 9180 for the Admin API in traditional mode. For each port, record which networks, jump hosts, CI runners and dashboards connect to it today, and name the owner of each caller. Use a listening-socket review on each node and a firewall or flow log extract covering a representative period. The step is done when every Admin API client appears on a list the platform owner approves. Check: a port listing on each node that matches the approved list, with no unexplained listeners.
Restrict network access to port 9180
Allow inbound connections to port 9180 only from the management network segment or from named administration hosts, and deny them from every other source, including client-facing networks and the internet. Apply the rule at the host firewall and at the network layer, such as a security group or perimeter firewall, so that one layer failing does not expose the port. Keep client traffic on port 9080 under its own rule set. Check: run a port scan against 9180 from a host outside the management network and confirm the port is filtered or closed, then confirm that an approved administration host still connects.
Replace the default Admin API key
Remove the sample Admin API key that ships in the default configuration and generate a long, random, unique key for each administrative identity or automation tool. Store each key in your secrets manager or the platform's secret store, and have the gateway read it at startup through a reference so the value stays out of files checked into source control. Confirm the exact configuration field for your release in the APISIX documentation before editing it. Check: send one Admin API request with the old default key and confirm it is refused, send one with a new key and confirm it succeeds, and search repositories and images for the old key string.
Separate read and write admin access
Where the APISIX release you run supports separate read and write permissions for Admin API consumers, create a read-only credential for dashboards, monitoring and auditors. Reserve write credentials for the automation pipeline and a small set of named operators. Confirm the exact role model for your release in the Admin API documentation before designing the split, because it varies by version. Check: use the read-only credential to attempt a route change and confirm it is refused, then confirm that a read request still succeeds.
Enable TLS on client and admin paths
Turn on TLS for the Admin API listener and for client traffic on the data plane so that credentials and payloads are encrypted in transit. Issue certificates from your internal certificate authority or a managed issuer, set minimum protocol versions and cipher suites according to your policy, and set a rotation schedule with your security team. Mutual TLS for the Admin API is worth evaluating for automation clients. Check: send a plaintext request to the Admin API and confirm it fails, then inspect the handshake with a TLS client to confirm the certificate chain and protocol version match your policy.
Turn on etcd authentication and encryption in transit
Gateway configuration lives in etcd, so an unauthenticated etcd cluster exposes every route, consumer key and plugin setting. Enable client authentication with dedicated users and least-privilege roles for the gateway and control plane. Enable TLS for peer and client connections between etcd members and gateway nodes, and restrict etcd ports to the gateway and etcd network segment only. Check: attempt an etcd read with no credentials and confirm it is refused, then restart one gateway node and confirm it loads its routes from the authenticated cluster.
Configure IP restriction and WAF plugins on exposed routes
Apply the IP restriction plugin to routes that should accept traffic only from known partner or internal address ranges. Apply the WAF plugin to routes that receive untrusted input. Choose the WAF rule set and its mode with the application owners, and start in a detect-only mode where the release supports it so that legitimate traffic is not blocked unexpectedly. Document which routes carry which plugins. Check: send a request from an excluded address and confirm it is refused, then send a known-good request and a test payload to a WAF-protected route and review the logged decisions.
Enable audit logging to a central system
Forward Admin API activity and gateway access logs to a central log platform that the security team controls, with retention and access rules set by policy. Record who changed which configuration and when, and alert on changes made outside the approved change process. Confirm that the log format includes the fields your investigators need, such as the identity behind a request, the source address and a timestamp. Check: make a harmless test change through the Admin API and confirm the event appears in the central system with the correct identity and source address within the window your team sets.
How TLS and mTLS are set between clients, gateway and upstreams
Hardening TLS on an APISIX gateway means treating four separate hops as four separate decisions: client to gateway, gateway to upstream, gateway to etcd, and the Admin API endpoint on port 9180. Each hop has its own certificate chain, its own trust store and its own owner, so a single setting applied globally rarely covers them all. Start by writing down every hop in your deployment mode. In traditional mode the gateway serves client traffic on port 9080 and the Admin API on port 9180, and both need a deliberate TLS decision rather than inheriting whatever the default configuration leaves in place. For client to gateway traffic, the main questions are which certificates the gateway presents, which protocols it accepts, and whether it should request client certificates. If you enable HTTP/3 with QUIC, which the APISIX repository lists among supported protocols, treat it as its own configuration target. Confirm the TLS settings that apply to each protocol you enable against the release you run, including the protocol versions and cipher suites in use. Do not copy values from older hardening guides, and do not assume a setting that governs HTTPS also governs HTTP/3. Gateway to upstream and gateway to etcd are where most operational effort sits. The gateway should verify the certificate of each upstream it calls, and etcd should be reached over TLS with client authentication where your cluster supports it. Confirm with your platform team which certificate authority signs each internal endpoint, because a mismatched trust store is the most common reason a hop works in staging and fails after go-live. Record the owner, expiry date and rotation method for every certificate you install.
Mutual TLS is worth its operational cost in specific cases. Service-to-service calls inside a zero-trust internal network are the strongest candidate, because the gateway can prove its identity to upstreams and reject callers that cannot present a valid certificate. Partner integrations are the second case, where a known counterparty must authenticate with a client certificate issued under an agreed trust model. For public, anonymous or browser-facing APIs, mutual TLS usually adds friction without adding much, and token-based authentication or IP restriction may serve better. Decide per route, not per gateway, and document the reason next to each route that requires client certificates. The certificate lifecycle is the real cost of mTLS, and it recurs for as long as the gateway runs. Issuance covers how client and upstream certificates are requested, approved and delivered. Rotation covers how they are replaced before expiry without dropping traffic, which means confirming that the gateway reloads new material cleanly on your chosen deployment mode. Revocation covers how a compromised client certificate is blocked, and you should confirm whether your APISIX release and chosen plugins check revocation status, and how quickly. Trust store updates cover adding or removing a certificate authority from the gateway's trust set, which must be tested in a non-production environment first.
Plan the lifecycle as an operational runbook before go-live. Name the team that owns each certificate authority, the process for emergency revocation, and the alerts that fire before any certificate expires. Test one full rotation in a non-production environment, including the gateway, the upstreams and the etcd connection, and time how long the change takes with your team in the loop. Ask your implementation partner or internal platform team to show the exact steps, because a rotation that works for a single route can still break a decoupled deployment where data and control planes read certificates separately. For a quote or internal plan, ask for the list of hops in scope, the certificate authorities involved, the protocols enabled on the client side, and the rotation procedure for each hop. Ask whether the work includes testing of HTTP/3 with QUIC if it is enabled, and whether revocation checks are part of the design. These items drive effort more than the number of routes, because each new trust relationship adds its own issuance, rotation and revocation path. Confirm the exact TLS options available in your release against the official APISIX documentation and the release notes for the version you deploy before you finalize any setting.
Securing etcd, keys and secrets in the APISIX control path
In APISIX, the configuration store, the Admin API keys and the consumer credentials together decide who can change how traffic is routed and authenticated. The controls below cover each layer, from the etcd cluster the gateway reads from, to the secrets and repositories that hold keys, to the backups that copy them.
Etcd client authentication and peer encryption
APISIX in traditional and decoupled modes reads its routes, plugins and consumers from an etcd cluster, so anyone who can write to etcd can change gateway behavior. Enable client authentication so that only the APISIX nodes and administrators can connect, and encrypt peer traffic between etcd members. Check both settings on every etcd node, not only the first one you configured, and confirm the TLS options against the etcd version your team runs.
Least-privilege etcd users for gateway nodes
Give each gateway node an etcd user with access to the keys APISIX needs to read and no more. Gateway nodes in the data plane should not hold credentials that can rewrite the full configuration, and administrative roles should be kept separate from runtime roles. Review the role grants whenever you add a new etcd prefix or a plugin that stores its own data, because a broad grant made during initial setup often survives unnoticed.
Admin API keys in a secrets manager
The Admin API on port 9180 accepts changes to every route and plugin, and its access keys are the most sensitive credentials in the gateway. Store these keys in a secrets manager your organization already audits, inject them at deploy time, and replace the default key in every environment before any node is reachable. Confirm that keys are rotated on a schedule and that rotation does not require editing files on the gateway host.
Consumer credentials handled like admin keys
The key-auth, jwt-auth, basic-auth and ldap-auth plugins each store or check credentials in a different way. Key-auth and basic-auth keep secrets in consumer objects, jwt-auth depends on a configured signing secret or public key, and ldap-auth delegates checks to a directory server. Consumer secrets and signing keys therefore need the same vaulting, rotation and access review as the Admin API keys, and the openid-connect plugin needs its client secret handled the same way.
TLS certificates and private keys
Gateway certificates and their private keys are used for client-facing TLS and for any mutual TLS checks. Store private keys outside the configuration repository, restrict which nodes can read them, and record expiry dates in your certificate inventory. Confirm how certificates are loaded from etcd or from files in your chosen deployment mode, because a certificate stored in configuration can be exposed by any user with read access to the store.
Access to the APISIX configuration repository
Route, plugin and consumer definitions are usually kept in Git and applied through a pipeline. Protect the repository with branch protection, required reviews for changes to the Admin API settings and consumer definitions, and secret scanning that blocks committed keys. Check that the pipeline pulls secrets at deploy time and that no environment file with credentials is ever committed, including old branches and forks.
Backups of etcd data
Each etcd snapshot contains the full gateway configuration, including any credentials stored there, so a backup is as sensitive as the live cluster. Encrypt backups at rest, limit who can restore them, and store copies in the same access boundary as production. Test restores in an isolated environment and confirm that old snapshots are deleted on the retention schedule your security policy sets.
What drives the effort of APISIX security hardening
This table lists the factors that move the effort and cost of hardening an APISIX gateway, with a way to keep each one down. Read it before requesting a quote, so you can see which items your environment will push up. Most of the cost is people time, plus any support agreement you add, so ask the quote to name each item separately.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Deployment mode and gateway node count | Traditional, decoupled and standalone modes each change where the Admin API, etcd and configuration sit, so each needs its own hardening steps. More gateway nodes multiply the work per change. | Choose one deployment mode early, apply one hardening baseline through configuration management, and confirm the node count in the written scope. |
| Number of environments (dev, test, production, air-gapped) | Each environment needs its own keys, certificates, etcd access and Admin API controls. Air-gapped sites also need offline packages and manual evidence collection. | Build one parameterized baseline and promote it between environments, rather than hardening each environment by hand. |
| Routes and consumers needing per-route policy | Every route that needs its own WAF rule, IP restriction or authentication policy adds design, testing and review time. Large consumer lists add credential and rotation handling. | Group routes into a small number of policy tiers and scope the first release to public routes, adding internal routes in later phases. |
| Identity providers and authentication plugins in use | Each identity provider and plugin, such as openid-connect, key-auth, jwt-auth or ldap-auth, needs its own secret handling, token validation tests and failure-mode checks. | Standardize on one primary identity provider and the fewest authentication plugins that meet your requirements. |
| Certificate and PKI maturity | Without an existing certificate authority, mTLS and TLS hardening require building issuance, renewal and revocation processes. Mature PKI shortens this work. | Reuse one internal certificate authority and an established renewal process, and confirm who owns certificate issuance before the work starts. |
| Existing SIEM and logging integration | Audit logs must reach your SIEM in a format it parses. Each new log destination, field mapping or alert rule adds configuration and validation time. | Agree the log fields and destination in advance and reuse existing SIEM parsers and alert templates where they fit. |
| Kubernetes involvement through the APISIX Ingress Controller | Hardening the Ingress Controller adds Kubernetes RBAC, admission and secret handling on top of the gateway. Controller and gateway versions must be checked together. | Confirm early whether the Ingress Controller is in scope and keep its resource definitions in the same version-controlled repository as the gateway configuration. |
| Compliance evidence requirements | Assessors often ask for configuration records, change history, test results and access reviews. Producing that evidence in a usable form takes extra time. DeployOpen prepares evidence but does not issue audit reports. | Ask your assessor for the exact evidence list before work starts and generate it from the baseline and pipeline where possible. |
| People time and support agreement | Cost comes from the hours of the people doing the work and any support or retainer you add after go-live. These are the items the quote should name. | Ask the quote to list each role, its hours, what is one-time and what recurs, and whether a support agreement is included or optional. |
How hardening changes across single node, HA, Kubernetes and air-gapped setups
A single-node deployment runs the data plane and control plane together on one host, so there are fewer network paths to restrict. The trade-off is that the Admin API on port 9180 is the single management surface you must protect, and there is no failover if the node or its etcd dependency fails. Hardening effort concentrates on one listener and one configuration store rather than on many internal connections.
The controls that change most are:
- Admin API exposure: bind the Admin API to a management interface or restrict it with host firewall rules so client traffic on port 9080 never reaches it.
- Admin key replacement: replace the default Admin API key before first start and store the new key in your secrets manager, not in configuration files on disk.
- Recovery planning: because there is no standby node, document how configuration is restored and tested from backup.
- Access logging for management calls: confirm that Admin API requests are logged and forwarded to your central log platform.
Verification focuses on proving the Admin API is unreachable from client networks, that the default key no longer works, and that a restore from backup brings the gateway back to a known configuration. Ask your team to confirm how the single-node setup maps to the APISIX deployment mode they plan to use.
In a high availability design, the data plane and control plane are decoupled and share a clustered etcd. This adds more endpoints to restrict, including the Admin API on each control-plane node, the etcd client and peer ports, and the connections between them. Each of these links needs its own authentication and certificate handling, and certificate rotation becomes a recurring operational task across several components.
The controls that change most are:
- Etcd access control: enable etcd authentication and TLS for client and peer traffic, and limit which hosts can reach the etcd ports.
- Certificate lifecycle: define issuance, renewal and rotation for every mTLS link between gateway nodes, control plane and etcd, and test a rotation before it is needed.
- Admin API scope: restrict the Admin API to control-plane addresses and keep data-plane nodes away from write access.
- Consistent configuration across nodes: confirm that key, certificate and plugin settings are identical on every node so a failover does not change security behavior.
Verification must cover each node and each link, not one representative host. Test that a data-plane node cannot write configuration, that an etcd member without valid credentials is rejected, and that a failover keeps authentication and TLS in force. Confirm the exact etcd and APISIX settings for your version with the vendor documentation.
When APISIX runs as the gateway behind the APISIX Ingress Controller, Kubernetes provides several controls that you would otherwise build yourself. Kubernetes RBAC limits who can create or change the custom resources the controller reads, network policies limit which pods can reach the gateway and its management ports, and Kubernetes secrets store keys and certificates. These controls do not replace APISIX settings, and you must confirm how the controller and the gateway interact before deciding where each control applies.
The controls that change most are:
- RBAC for route and plugin resources: restrict who can create or modify custom resources, since a change to a route can change authentication and exposure.
- Network policies: isolate the Admin API and etcd endpoints so only controller and gateway pods can reach them.
- Secret handling: store Admin API keys, TLS certificates and identity provider secrets in Kubernetes secrets or an external secrets store, with access limited by namespace.
- Controller-to-gateway trust: confirm how the controller authenticates to the gateway and which credentials it uses.
Verification should include policy tests from pods outside the gateway namespace, a check that RBAC denies changes from application teams, and a review of what the controller writes into the gateway. Ask your team to confirm the controller version and the gateway version it supports, since both are tracked as separate releases.
In an air-gapped network, the gateway cannot reach an external certificate authority, an external identity provider or public package sources. Any control that depends on those services has to be replaced with a local alternative, and the plan must cover how plugins, images and release updates enter the network. The hardening goals stay the same, but the supporting infrastructure becomes part of your scope.
The controls that change most are:
- Local PKI: operate an internal certificate authority for TLS and mTLS, with a documented process for issuing, revoking and renewing certificates without external reach.
- Identity without external reachability: if you use the openid-connect plugin, confirm that your identity provider is reachable inside the enclave, or choose a local authentication method.
- Offline plugin and release handling: verify each plugin, package and image against your own checksums before import, and keep a documented process for security fixes.
- Local logging and time sources: route audit logs to an internal collector and confirm an internal time source so log records remain usable.
Verification must prove that the gateway functions with no outbound connections, that certificate revocation works without public endpoints, and that an imported release matches the expected hash. Confirm with your platform team which artifacts can cross the boundary and through which approved transfer path.
How to test that APISIX hardening works and fails safely
The test plan should prove each hardening control in the gateway, not just confirm that the configuration files were changed. For an APISIX gateway running in traditional mode, the first checks are network reachability and authentication. Confirm from outside the management network that port 9180, the Admin API port, does not accept connections, and confirm from inside a permitted management host that it still does. Then send requests to the Admin API without the new credential and confirm every one is refused. Run these checks from the same network segments your security team uses for scanning, so the results carry evidence weight in your review. Next, test transport security from both sides. Confirm that TLS handshakes succeed for allowed clients and fail for clients without a valid certificate. Where mutual TLS is enforced, present a certificate signed by an untrusted authority, an expired certificate and a certificate issued to a client outside the allowed group, and confirm each is rejected. Record the protocol versions and cipher suites negotiated, so the evidence matches the policy your architecture team approved. Do the same for etcd. An unauthenticated client should be unable to read or write keys, and the test should cover the client certificate or password settings you chose during the etcd hardening work. The traffic controls need tests in both directions. IP restriction and WAF rules must block the malicious and out-of-policy cases you define, such as a request from a denied address range, a classic injection payload and an oversized body. Equally important, legitimate requests must pass. Prepare a set of representative API calls for each route, including authenticated calls with valid tokens, and confirm they return the expected status codes. A WAF that blocks everything is as much a failure as one that blocks nothing, so treat false positives as defects to be tuned and retested. Failure tests show whether the gateway fails safely. Stop one etcd member and confirm that the cluster still has quorum, that the gateway continues to serve traffic and that configuration changes behave as designed. Rotate a gateway certificate and confirm that serving continues during and after the change, and that the rotation is either applied cleanly or refused with a logged error. The gateway should keep serving its last known configuration if the control plane becomes unavailable. Verify this by making a route change while etcd is unreachable and confirming the change is refused or queued, not silently lost. Confirm that each of these events, including the Admin API refusals, reaches the central log within the time your monitoring standard requires. Ask your platform team to confirm the exact retention and alerting expectations before you fix the pass criteria. Keep the whole plan in a repeatable test script stored in the same repository as the gateway configuration, so it runs after every change and every upgrade. The script should be idempotent, return a clear pass or fail for each control, and write its output as an artifact that can be attached to a change record. Ask the implementer to name the owner of the script, the environments where it runs and the process for updating tests when a control changes. Note that these results support your own assessment and audit preparation. They do not replace the independent review that an auditor or certification body performs.
What to monitor, back up, upgrade and document after go-live
Hardening an APISIX gateway is not finished at go-live, because configuration, plugins and the etcd store keep changing. The cards below cover the signals to watch, the backups that make recovery possible, the release policy you need to set, and the baseline record that ties every decision to an owner.
Monitor Admin API access attempts
The Admin API on port 9180 is the most sensitive surface in a traditional deployment, so every access attempt should be logged and reviewed. Check for requests from unexpected source addresses, calls outside your change windows, and attempts against routes, consumers or plugin settings that nobody has requested. Confirm that alerts reach an on-call owner, not only a log file.
Track failed authentication
Failed key, JWT, basic or OpenID Connect authentication on client routes shows both abuse and misconfiguration. A sudden rise on one consumer or route can mean leaked credentials, while a steady background rate often points to a client using an expired secret. Set thresholds per authentication plugin and decide who investigates each alert and how a consumer's credentials get rotated.
Watch certificate expiry dates
TLS certificates on the gateway, and any client certificates used for mTLS, have fixed end dates that cause outages when missed. Build an inventory that lists each certificate, the hostname or upstream it protects, its issuer and its expiry date, then alert well before renewal is due. Renewal should be rehearsed in a non-production environment so that the process is known when the date arrives.
Monitor etcd health and membership
In traditional and decoupled modes, etcd holds every route, consumer and plugin setting, so its health determines whether the gateway can accept configuration changes. Watch member health, leader changes, disk latency and unexpected member additions or removals, and confirm that etcd client authentication and peer TLS remain enabled after each change. Record every membership change with a reason and an approver.
Confirm audit log delivery
Audit logs are only useful if they reach the system where your security team reviews them. Test end to end by making a controlled change and checking that the event appears in the destination, with the timestamp, actor and resource recorded. Repeat the test after logging plugins or log destinations change, and alert when log shipping stops or falls behind.
Back up etcd and the configuration repository
Back up etcd snapshots in traditional and decoupled deployments, and keep the declarative configuration in a version-controlled repository for standalone or file-driven setups. A backup is only proven when a restore has been run into a separate environment and the gateway behaves as expected afterward. Schedule restore tests, record the result and confirm who holds the keys and credentials needed to restore.
Set an upgrade policy from release notes
APISIX 3.19.0 was released on September 28, 2026, and later releases appear on the APISIX downloads page. That page does not mark any release as long-term support, so you need to decide which release line you follow, how quickly you adopt patches, and who reviews release notes for security fixes. Confirm the support terms of any commercial distribution you use before relying on them.
Re-test after each change
Every new plugin, route, consumer or configuration change can weaken a control that worked before, including authentication, IP restriction and WAF rules. Re-run the hardening checks that cover the changed component, and treat a failed check as a blocker for release. Keep the test scripts in the same repository as the configuration so they run with every change.
Keep a hardening baseline document
A baseline document records each hardening decision, the setting that implements it, the test that proves it and the owner who answers for it. Update it with every upgrade, plugin change and certificate renewal, and review it on a fixed schedule. Auditors and new operators will rely on it, so store it with the configuration and link each entry to the evidence that supports it.
Questions buyers ask before hiring help with APISIX security hardening
How much effort does APISIX security hardening take, and what drives the cost?
Effort depends mainly on how many gateway nodes, etcd members and environments are in scope, and on how many routes, consumers and plugins need review. Cost components usually include discovery (reviewing the current Admin API exposure, keys, certificates and logging), design of the hardened configuration, implementation, testing, and handover documentation. One-time work covers the initial hardening and evidence capture. Recurring work appears when you add routes, change identity providers or upgrade APISIX, because each change may need the same checks again. When you request a quote, ask for the list of environments, the plugins in scope, who performs the etcd and certificate tasks, and which test evidence is delivered. DeployOpen issues fixed-scope quotes from a written scope, so the figure follows from that document rather than a standard rate.
How long does an APISIX hardening engagement take?
Duration depends on the deployment mode, the number of environments, and the agreed scope. APISIX runs in traditional, decoupled or standalone mode, and each mode changes which components need locking down. A gateway with one etcd cluster and two environments takes less time than a multi-region decoupled setup with mTLS to upstreams and a WAF rule set. The timeline should appear in the written scope, with milestones for review, change windows, test rounds and sign-off. Ask for the assumptions behind the estimate, including your change freeze dates and the availability of your certificate authority and identity provider staff, since those are the most common sources of delay.
Can a small team harden APISIX on its own?
Yes, a small team can do this in-house if it already has working knowledge of etcd, public key infrastructure and the gateway itself. The hardening work covers changing the default Admin API key, restricting access to port 9180, configuring TLS and mTLS, enabling etcd authentication, setting up IP restriction and WAF plugins, and turning on audit logging. Each decision should be written down, including why a plugin was chosen and what it blocks, and each control should have a repeatable test. Teams without these skills usually lose time on certificate lifecycle and etcd access control, so those areas are the first to consider for outside help.
What do you need to provide for an APISIX hardening project?
The project needs several inputs from your side before work starts. Network access to the gateway, etcd and test environments, plus firewall change approval for the Admin API and management paths. A certificate authority or a documented process to issue server and client certificates for TLS and mTLS. Identity provider details if you protect APIs with the openid-connect plugin, including client registration and redirect rules. Access to your logging system so audit logs can be forwarded and checked. Named owners for the gateway, the identity provider, the certificate authority and the logging platform, each with authority to approve changes. Confirm these items in the written scope, because missing owners are a frequent cause of schedule slips.
Does hardening APISIX make our API platform compliant?
No. Hardening configures controls and produces evidence, but it does not make a system compliant with any framework on its own. Compliance is assessed by an independent auditor or a certification body against the control set you are working toward, such as a control in a published security standard. DeployOpen prepares systems, controls and evidence for that assessment, including configuration records, test results and access reviews, but it does not issue audit reports, attestations or certifications. Ask your auditor early which evidence they expect, and map each hardening control to the requirement it supports before the work begins.
Should we use the Apache-2.0 release or a commercial APISIX-based product?
The Apache-2.0 release is free to use, modify and deploy, and it is maintained by the Apache Software Foundation community. A commercial APISIX-based product, such as API7 Enterprise from API7.ai, adds vendor-provided features and support, and the vendor describes it as a full API lifecycle management product. Vendor pricing is not published on the vendor page, so request a quote. Confirm which security features each edition includes, such as management interfaces, audit features and support terms, because these differ by product. For the multi-year comparison of infrastructure, staffing and support, see the cost of ownership and editions topic.
How DeployOpen scopes, hardens and hands over APISIX security work
DeployOpen approaches Apache APISIX security hardening as fixed-scope work inside your own infrastructure, starting with a written scope that names the deployment mode, exposed listeners and controls to change. We build and test each control in a non-production environment, then document the configuration and evidence so your team can operate and audit it.
How we scope
- Confirm the deployment mode (traditional, decoupled or standalone) and which listeners, including port 9080 and the Admin API on port 9180, are reachable from where
- Inventory existing Admin API keys, default credentials, etcd access paths and upstream TLS settings that the hardening must change
- Agree in writing which controls are in scope, such as TLS, mTLS, WAF, IP restriction and audit logging, and what is excluded
How we build
- Restrict Admin API access, replace default keys and apply etcd authentication and network controls in a staging gateway first
- Configure TLS and mTLS for client and upstream traffic, then test certificate rotation and rejection of untrusted clients
- Enable and tune WAF, IP restriction and logging plugins against captured traffic, checking for false positives before production
How we hand over
- Deliver the hardened configuration as code with a record of each control, its purpose and where it is enforced
- Provide test evidence showing the Admin API, TLS and access restrictions behave as documented, for your auditors or internal reviewers
- Walk your operations team through log locations, alert conditions, key rotation steps and the change process for future plugin edits
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, covering APISIX release changes that affect hardened settings
- Compliance readiness work prepares systems, controls and evidence; independent auditors and certification bodies issue any audit reports
- Quotes follow from the written scope, so ask for the listed controls, environments and deliverables to be itemized before signing
