Apache APISIX - Hardened Cloud-Native API Gateway

What is Apache APISIX

Apache APISIX is a cloud-native, high-performance API gateway built on OpenResty (NGINX + LuaJIT). It routes, secures and observes API traffic through a large catalogue of plugins: key-auth, JWT, basic-auth, OpenID Connect, rate limiting, IP restriction, CORS, request and response transformation, Prometheus metrics and OpenTelemetry. Routes, upstreams, consumers and plugins are configured dynamically through the Admin API or the embedded web Dashboard, with no restart required. APISIX stores its configuration in etcd; this image bundles a single-node etcd locally, so there is no external etcd cluster to deploy, secure or operate. Apache-2.0 license, no per-API fees, no vendor lock-in - the open-source gateway is the production gateway.

Why self-host Apache APISIX

Running your API gateway on a VM you control keeps your route definitions, upstream topology, consumer credentials and gateway traffic inside your own tenant rather than a managed API service - fitting data residency requirements and GDPR, HIPAA or ISO 27001 obligations, with no per-call fees. Apache-2.0, fully auditable, no vendor lock-in.

What this VM image adds

Security hardening:

• Single-node etcd datastore bundled and bound to 127.0.0.1 only - no external etcd cluster to deploy or expose
• Admin API and embedded Dashboard bound to 127.0.0.1 only - remote management only through an Nginx TLS perimeter on port 443
• The historical default Admin API key is rotated to a unique per-instance key at first boot, saved to /root/apisix-credentials.txt (mode 0600)
• Data plane on ports 9080 (HTTP) and 9443 (HTTPS) for proxied API traffic
• No anonymous telemetry; the bundled OpenResty links OpenSSL 3.x (not the EOL 1.1.1 branch)
• UFW firewall - TCP 22 for SSH plus the gateway ports (443, 9080, 9443) opened by the buyer in the NSG; all other inbound dropped
• fail2ban - SSH brute-force protection
• AppArmor - mandatory access control
• CVE scan - every image is scanned with Trivy before release

OS hardening (CIS Level 1):

• CIS Ubuntu 24.04 LTS Level 1 Benchmark via ansible-lockdown
• auditd for system call auditing of critical paths
• SSH hardening - key-only access, PermitRootLogin no, LoginGraceTime 60
• Kernel hardening - SYN cookies, ASLR, rp_filter, IPv6 off
• /tmp as tmpfs with nosuid, nodev, noexec

Compliance artifacts (inside the VM):

• SBOM - CycloneDX 1.6 at /etc/lynxroute/sbom.json with Apache APISIX pinned by version, PURL, license and hash
• CIS Conformance Report at /etc/lynxroute/cis-report.html (OpenSCAP, Azure tailoring profile, 0 FAIL rules)
• Tailored CIS profile at /usr/share/doc/lynxroute/CIS_TAILORED_PROFILE.md
• Operator credentials file at /root/apisix-credentials.txt (mode 0600) with the per-instance Admin API key and the management URLs

Quick Start

1. Deploy VM from Azure Marketplace (Standard_D2s_v3 recommended)
2. Open NSG: TCP 443 from your API administrators, TCP 9080 and 9443 from your API clients, TCP 22 from your management IPs only
3. SSH: ssh -i key.pem azureuser@<PUBLIC_IP>, then sudo cat /root/apisix-credentials.txt for the Admin API key
4. Open the embedded Dashboard over TLS at https://<PUBLIC_IP>/ui/, accept the self-signed certificate, and paste the Admin API key from the credentials file
5. Or manage routes through the Admin API over the TLS perimeter: curl -k https://<PUBLIC_IP>/apisix/admin/routes -H "X-API-KEY: your-admin-key"

The Admin API key is generated at first boot (the historical default key is rotated). Configuration is stored in a bundled single-node etcd on 127.0.0.1:2379 - there is no external etcd cluster to operate. The raw Admin API and Dashboard (port 9180) and etcd (port 2379) stay bound to 127.0.0.1; the only remote management path is the TLS perimeter on port 443. Create a route to a backend, then send traffic through the data plane on port 9080 (HTTP) or 9443 (HTTPS). To serve HTTPS for your own domain on the 9443 data plane, add an SSL certificate through the Dashboard (APISIX terminates TLS per-SNI). For production, replace the self-signed perimeter certificate with a CA-signed certificate.