Kong Gateway Security Guide: Admin API, Plugins and Consumer Credentials

Whoever can reach the Kong Admin API can reroute every API behind the gateway, disable its authentication plugins and read or mint the credentials of every consumer. Kong Gateway is a widely deployed open source and enterprise API gateway built on NGINX and OpenResty, and in most estates it sits in front of the APIs that partners, mobile apps and internal services depend on. This guide covers how identity works in Kong (the Admin API, RBAC, Kong Manager and Consumers), the admin roles that need privileged access controls, consumer credentials as non-human identities, secrets and keyring, hybrid mode certificates, audit logging, and a hardening baseline. It is for platform engineers and API security teams running Kong Gateway on premises or in Kubernetes. It goes deeper than the general API Gateway Security Guide on Kong specifics. Behaviour was checked against Kong's developer documentation on 27 October 2026; several features (RBAC, audit logs, keyring, external vaults) are Kong Gateway Enterprise only.

Key takeaways

• The Admin API is the crown jewel. Kong binds it to the local interface on port 8001 by default and warns that exposing it, especially on 0.0.0.0:8001, can seriously compromise the whole cluster. Only the proxy ports 8000 and 8443 should face clients.
• Open source Kong has no Admin API login. Protection comes from network restriction, or from proxying the Admin API through Kong itself with authentication and IP restriction plugins. Enterprise adds RBAC with enforce_rbac.
• Consumer credentials are non-human identities. API keys, Basic Auth, HMAC, JWT and OAuth 2.0 credentials attached to Consumers belong to partner systems and apps. Give each an owner, a scope (ACL groups) and a rotation plan.
• Keys in query strings leak. The key-auth plugin accepts keys in the query string by default; Kong notes these can appear in logs and browser bars. Turn off key_in_query for service traffic.
• Audit logging is off by default. Enterprise audit logs record Admin API requests and database changes, can be signed with an RSA key, and need audit_log = on and export before the TTL purges them.

How identity and access work in Kong Gateway

Kong has two separate identity planes: the administrators and automation that configure the gateway, and the Consumers whose requests it authenticates.

Default ports

Admin roles and privileged access

In Kong Gateway Enterprise, RBAC is enabled with enforce_rbac = on plus admin_gui_auth and admin_gui_session_conf for Kong Manager. You must set KONG_PASSWORD at first start or no super admin is created and the gateway is locked. Kong's documentation is direct: Kong Manager authentication requires RBAC, otherwise anyone who can log in can perform any Admin API operation.

• Deny by default: RBAC checks rules from most to least specific and denies if nothing matches. Wildcards replace a single URL segment and are not globs, so /rbac/* does not cover nested RBAC paths; test permissions rather than assuming.
• Workspace inheritance: roles assigned in the default Workspace carry into later Workspaces unless those Workspaces assign their own. Avoid granting broad roles in default.
• Separate the super admin: the super admin only manages RBAC. Create named admins for day-to-day work so audit records show real identities.
• Open source deployments: keep admin_listen on 127.0.0.1, restrict with host firewall rules, and if remote access is needed, create a Service and Route in Kong that points to the local Admin API and protect it with an authentication plugin, the IP Restriction plugin and the ACL plugin, as Kong's own guide describes.

Admin API access is privileged access to every API behind the gateway. See the PAM Maturity Model.

Integrations, API tokens and service accounts

Consumer credentials

• Authorisation after authentication: any Consumer with a valid credential can reach the Service or Route the plugin protects. Kong recommends the ACL plugin with allow or deny groups to restrict which Consumers reach which APIs.
• Anonymous fallback: configuring an anonymous Consumer turns failed authentication into anonymous access. Only use it with a downstream plugin or upstream logic that treats X-Anonymous-Consumer as untrusted.
• Inventory and ownership: each Consumer should map to a named partner, application or service, with a technical owner and a review date. Unused Consumers with live keys are orphaned non-human identities. See the API Key Management Guide and the API Keys vs OAuth Tokens Guide.

Gateway secrets

• Vault references: Kong resolves references of the form {vault://backend/key} in kong.conf and referenceable plugin fields. Open source supports environment variables only; Enterprise adds AWS Secrets Manager, Google Cloud Secret Manager, HashiCorp Vault (token, Kubernetes and AppRole auth), Azure Key Vault, CyberArk Conjur (3.11+), file system (3.15+) and Konnect Config Store. Rotation is driven by TTLs on the Vault entity.
• Keyring (Enterprise, on premises): with keyring_enabled = on and keyring_strategy = cluster, Kong encrypts certificate private keys and plugin fields marked encrypted before storing them. Admin API responses still show these values in plain text, so keyring protects the database, not the API. Disable swap on Kong hosts so keys are not written to disk, and protect the recovery private key.
• Automation identities: decK, CI pipelines and the Kubernetes Ingress Controller all hold Admin API access. Give each its own RBAC user and custom role limited to its Workspace, store its token in the CI secret store, and never reuse the super admin token. See the GitOps Security Guide.

Hybrid mode

In hybrid mode only control plane nodes hold the database and serve the Admin API; data plane nodes receive configuration over mTLS and cache it in a local dbless.lmdb file, which is unencrypted by default. The default cluster_mtls = shared uses one certificate and key on every node, so stealing it from any data plane lets an attacker impersonate any node. Prefer pki or pki_check_cn (which also checks the certificate common name against cluster_allowed_common_names) so each data plane has its own certificate, and enable cache encryption. See the mTLS Guide.

Logging and detection

What to alert on

• Any Admin API request from an unexpected source: the Admin API should only be called from localhost, named automation hosts or the management network. Requests from elsewhere suggest exposure (T1190 Exploit Public-Facing Application).
• Plugin removal or disablement on Routes and Services, especially authentication, ACL, IP restriction and rate limiting plugins.
• New Consumers or credentials outside the provisioning pipeline, and new credentials on existing high-value Consumers (similar to T1098.001 Additional Cloud Credentials in effect).
• Route or upstream changes that point a Service at an unfamiliar host, a classic way to intercept traffic (T1557 Adversary-in-the-Middle).
• RBAC changes: new admins, new role assignments, super admin logins.
• Consumer behaviour: one key used from many IPs or countries, spikes in 401 responses per source (T1110.004 Credential Stuffing), or keys appearing in query strings in logs.

Metrics

• Admin exposure: gateway nodes with admin_listen or Kong Manager reachable outside the management network (target 0).
• Consumer ownership: Consumers with a recorded owner and review date (target 100 percent).
• Credential age: API keys and secrets older than the rotation policy.
• Query-string keys: share of key-auth plugin instances with key_in_query enabled (target 0 for service traffic).
• Change attribution: share of configuration changes made by a named identity or pipeline rather than a shared token.
• Patch lag: days from a Kong security release to deployment, against Kong's version support policy.

Hardening baseline

1. Network first: expose only 8000 and 8443 to clients. Bind admin_listen and admin_gui_listen to localhost or a management interface, enforce with host and network firewall rules, and allow 8005 and 8006 only from data plane nodes. Test with an external port scan.
2. Admin authentication: on Enterprise, enable RBAC with KONG_PASSWORD set, configure Kong Manager with SSO through OpenID Connect or LDAP, and create named admins and per-pipeline RBAC users. On open source, proxy the Admin API through Kong with authentication and IP restriction, or keep it local only.
3. Configuration as code: manage entities with decK or the Kubernetes Ingress Controller from a reviewed repository so every change has a commit and reviewer; treat manual Admin API changes as exceptions that alert.
4. Consumer credentials: disable query-string keys, hide credentials from upstreams, prefer key-auth-enc, JWT with asymmetric keys, OpenID Connect or mTLS for new integrations, and apply ACL groups to every authenticated Route.
5. Secrets: move pg_password, plugin secrets and certificates to vault references; enable keyring where on premises; disable swap.
6. Hybrid mode: switch from shared to pki or pki_check_cn certificates, encrypt the data plane cache, and protect control plane hosts as tier 0.
7. Logging: enable and sign audit logs, forward them and access logs to the SIEM before audit_log_record_ttl purges them, and scrub credentials from logs.
8. Patching: follow Kong's vulnerability and patching policy and version support policy; stage upgrades in a non-production cluster with the same plugins, keep the previous image and database backup for rollback.

Open source or Enterprise, small or large

• Open source, single team: no RBAC or audit logs, so the Admin API must stay on localhost, changes should only come through decK in CI, and the CI token for the proxied Admin API is the most sensitive secret you hold.
• Enterprise, many teams: Workspaces per API domain, Workspace-scoped roles, per-pipeline RBAC users, signed audit logs and hybrid mode with PKI certificates. Review RBAC grants quarterly.

Common misconfigurations

• Admin API on 0.0.0.0: often from container examples or Helm values copied into production, leaving full gateway control one request away. AI and LLM gateways show the same pattern: the LiteLLM MCP auth bypass exposed provider API keys, and a scan found internet-facing gateways still accepting a default master key.
• Kong Manager without RBAC: anyone who can log in can do anything through the Admin API.
• Keys in URLs: key-auth left with key_in_query on, so partner keys appear in proxy logs, analytics and browser history.
• Authentication without ACL: every valid Consumer can call every API behind a Route that only has an authentication plugin.
• One super admin token for all automation: shared across CI, scripts and engineers, never rotated, and with no attribution in audit logs.
• Shared hybrid certificate: the same cluster_cert and key on every data plane, including those in less trusted networks.

Framework mapping

Practitioner checklist

• Confirm only ports 8000 and 8443 are reachable by clients and that the Admin API and Kong Manager are not reachable from outside the management network.
• On Enterprise, enable RBAC with KONG_PASSWORD, vault the super admin credential and create named admins.
• On open source, keep admin_listen on localhost or proxy it through Kong with authentication and IP restriction.
• Give decK, CI and the ingress controller separate, Workspace-scoped RBAC identities.
• Disable key_in_query, enable hide_credentials and add ACL groups to every authenticated Route.
• Record an owner and review date for every Consumer and remove unused credentials.
• Move gateway secrets to vault references and enable keyring on premises.
• Use pki or pki_check_cn for hybrid mode and encrypt the data plane cache.
• Enable signed audit logs and export them before the TTL purge, with alerts on plugin, route, Consumer and RBAC changes.
• Track Kong security releases and stage upgrades with a tested rollback.

Standards and references

• Kong: Secure the Admin API
• Kong: Gateway RBAC
• Kong: Gateway network and default ports
• Kong: Key Authentication plugin
• Kong: Gateway audit logs
• Kong: Secrets management
• Kong: Hybrid mode
• OWASP: API2:2023 Broken Authentication

Related NHI Mgmt Group resources: API Gateway Security Guide · API Key Management Guide · mTLS Guide · Rate Limiting and API Abuse Guide