Kong Api Gateway: Installing, Configuring and Securing.
By: Cagri Ersen
Tags: Microservices Application, Kong Api Gateway, Clustering, Microservices, Api Gateway

How It Works

Kong is built on top of Nginx, -this is why it’s highly extensible- and by using its own admin api, it configures the nginx server to provide proxying for backend services.

Kong uses OpenResty which is a kind of enhanced version of nginx that includes lua-nginx-module. Thus Kong is distributed along with OpenResty to leverage its lua scripting capability to configure and extend nginx.

In other and simple words, Kong accepts your reverse proxying directives via its own Admin API over http/s, translates them to nginx configuration using lua scripting language and builds a gateway platform for micro service backends.

Admin API

When you install Kong on a host, the Admin API will be accessible on tcp/8001(http) and tcp/8444(https) ports. By interacting the Admin Api , you can configure Kong dynamically.

As a security best practice, Admin API ports are for internal use and should be firewalled.

Proxying

On the other hand Kong listens tcp/8001(http) and tcp/8443(https) ports to receive end-user requests and according the configuration you define, forwards to your endpoints. Those ports are publicly-facing services that must allow external connections.

Datastore

Kong uses an external database to store configurations data. You passes your configuration directives over admin API and Kong stores them in its datastore. And multiple kong servers can use a central database. (Which makes the gateway platform high-available and scalable. I’ll mention this in detail on Clustering section.)

Supported datastores are Cassandra and PostgreSQL. Though Cassandra is preferred datastore to build a multi-regional Kong environment, PostgreSQL can also be used for production without any issues. (In this post, we’ll use a Postgres replication for the sake of simplicity.)

Cache

As you know, when it comes to performance, databases can be easily become a main bottleneck. In order to avoid this and improve performance, Kong maintains a cache to hold the configuration data in the node’s memory.

No matter which datastore engine you use, when you call admin API to configure Kong, configuration data is written to the external datastore, then pulled from the external db and written to the node’s memory as cache; finally, configuration is applied.

At this point there is no need for a database roundtrip anymore while proxying requests. If you do any configuration change, Kong invalidates cache and pulls the new configuration to cache it again. This approach boost Kong’s performance obviously.

In order to avoid to break Kong’s cache invalidation mechanism, you should not manipulate the datastore db directly.

DB-less Mode and Declarative Configuration

As I mentioned in Datastore section, kong requires a database for the configuration data, however there is another option called DB-less mode. In this mode the configuration directives is declared as a JSON or YAML formatted configuration file, thus Kong reads this file to get configuration directives and write it to node’s memory.

With this mode, you can manage Kong by using a CI/CD tool. Since, configuration directives are stored in a static file, you can keep it in a git repository and distribute to multiple kong nodes. However in this mode Admin API is read-only, because the only way to configure Kong is using a declarative configuration file. In other words, you can’t pass any configuration directives to the admin api over RESTFull api.

Moreover, some useful plugins are not compatible with this mode, since they require a database by design. For example, rate-limiting plugin requires to a database to hold limiting values.

This mode may seem useless for production use however it is also a part of another mode called Hybrid mode that can be used create a Kong cluster. Next section I’ll explain this mode as well.