You are browsing documentation for an outdated version.
See the latest documentation here.
Networking Configuration for Kong Manager
By default, Kong Manager starts up without authentication (see
admin_gui_auth), and it assumes that the Admin API is available
on port 8001 (see Default Ports of the same host that serves Kong Manager.
Here are some common configuration scenarios for Kong Manager.
Serving Kong Manager from a dedicated Kong node
When Kong Manager is on a dedicated Kong node, it must make
external calls to the Admin API. Set
admin_api_uri to the
location of your Admin API.
Securing Kong Manager through an authentication plugin
When Kong Manager is secured through an authentication plugin
and is not on a dedicated node, it makes calls to the Admin API on
the same host. By default, the Admin API listens on ports 8001 and
8444 on localhost. Change
admin_listen if necessary, or set
Important: If you need to expose the
admin_listen port to the internet in a production environment,
secure it with authentication.
Securing Kong Manager and serving it from a dedicated node
When Kong Manager is secured and served from a dedicated node,
admin_api_uri to the location of the Admin API.
Connecting to the Admin API
The table below summarizes which properties to set (or defaults to
verify) when configuring Kong Manager connectivity to the Admin API.
To enable authentication, configure the following properties:
Important: When Kong Manager authentication is enabled, RBAC must be turned
on to enforce authorization rules. Otherwise, whoever can log in
to Kong Manager can perform any operation available on the Admin API.
By default, if Kong Manager’s URL is accessed over HTTPS without a certificate issued by a CA, it will
receive a self-signed certificate that modern web browsers will not trust, preventing the application
from accessing the Admin API.
In order to serve Kong Manager over HTTPS, use a trusted certificate authority to issue TLS certificates,
and have the resulting
.key files ready for the next step.
.key files into the desired directory of the Kong node.
admin_gui_ssl_cert_key at the absolute paths of the certificate and key.
admin_gui_ssl_cert = /path/to/test.crt
admin_gui_ssl_cert_key = /path/to/test.key
3) Ensure that
admin_gui_url is prefixed with
https to use TLS, e.g.,
admin_gui_url = https://test.com:8445
If serving Kong Manager on localhost, it may be preferable to use HTTP as the protocol. If also using RBAC,
admin_gui_session_conf. The reason to use HTTP for
localhost is that
creating TLS certificates for
localhost requires more effort and configuration, and there may not be any
reason to use it. The adequate use cases for TLS are (1) when data is in transit between hosts, or (2)
when testing an application with mixed content
(which Kong Manager does not use).
External CAs cannot provide a certificate since no one uniquely owns
localhost, nor is it rooted in a top-level
.org). Likewise, self-signed certificates will not be trusted in modern browsers. Instead,
it is necessary to use a private CA that allows you to issue your own certificates. Also ensure that the SSL state
is cleared from the browser after testing to prevent stale certificates from interfering with future access to