Improve Security and Get Started Faster with Kong for Kubernetes 0.9

By on May 27, 2020

Kong for Kubernetes 0.9 Released With Encrypted Plugin Configuration and More!

Kong for Kubernetes is a Kubernetes Ingress Controller and a full-fledged edge-router which can route traffic to any destination of your choice. In addition to Ingress management, it provides enhanced security and management capabilities. With Kong, you can use Kubernetes not just for running your workloads but also for securing and monitoring connectivity between your workloads – all managed via Kubernetes manifests and CI/CD processes.

Back in April 2019, we released a DB-less version of Kong Ingress Controller, which doesn’t require a database to run Kong Gateway and reuses Kubernetes’ etcd as the source of configuration. Since the initial release, over 75% of all deployments of Kong Ingress Controller run without a database. This release focuses on key features that allow Kong Ingress Controller to run in full DB-less mode.

This release’s highlights include the ability to store plugin configuration in Secrets, support for exposing Kubernetes Services using mutual TLS authentication, support for custom entities in DB-less mode, environment variables driven configuration for certificates and several new annotations.

Plugins With Secret Configuration

Plugin configuration often has sensitive information that needs to be secured. Our users frequently use plugins to protect their serverless workloads running in AWS Lambda or use our OpenID connect plugin to protect enterprise applications. These, along with other plugins, contain sensitive credentials that our users wish to protect using Kubernetes Secrets. This has been a consistent ask from our open source users as well as enterprise customers. With this release,  KongPlugin and KongClusterPlugin Custom Resources now support a new configFrom setting, which references a Secret containing the plugin configuration:

 

The configuration format inside the Secret is flexible and allows for either YAML or JSON representation. Note that you must store the entire configuration in either config or configFrom; you cannot use both settings at once.

CA Certificates and Client TLS Authentication

Another sought-after feature from our customers has been the ability to verify client certificates without using a database with Kong. The mtls-auth plugin allows clients to authenticate to Kong using a TLS client certificate. This release adds the ability to dynamically configure CA certificates in Kong using Kubernetes Secrets, which can then be used in the plugin to verify a client’s TLS certificate. The controller watches for these Secrets and creates a CA certificate using the cert and id values from the Secret data:

See our guide on using mTLS authentication with Kong for Kubernetes for a detailed step-by-step example.

Custom Entities in DB-less Mode

Because DB-less configuration must be provided as a single unit, the controller must understand how to create configuration for all entities in it. This presents a problem for plugins that use custom entities: the controller must create this configuration but can’t know in advance what it will look like or where to look for it.

This release adds a new CONTROLLER_KONG_CUSTOM_ENTITIES_SECRET environment variable, which references a Secret whose config key contains a collection of JSON arrays, each of which contains custom entities of a particular type. For example, to create two foobar entities and one foobaz entity:

This allows the use of static custom entities but not dynamic custom entities: if your plugin needs to create custom entities at runtime (e.g. counters for a rate limiting plugin), it is still not compatible with DB-less mode.

See our guide to using custom entities with Kong for Kubernetes for more details.

Environment Variables for Certificates

The controller can optionally use an admission controller to validate a newly created configuration and can verify its connection with the Kong Admin API, both of which use certificates. Historically, these certificates were provided to the controller using command-line arguments indicating the certificates’ filesystem paths. This release adds new options to provide these certificates via environment variables, simplifying the configuration needed to use them:

Annotations

Starting with the 0.8 release, we began adding annotations to ease the configuration and maintenance of Kubernetes resources. This release adds several annotations that further reduce the need for KongIngress resources.

Regex Priority

Adding a konghq.com/regex-priority annotation to an Ingress will set the corresponding route’s regex priority. Among other criteria, Kong uses this value to determine which routes it should attempt to match first.

Host Header Manipulation

Host header for traffic destined to a specific Kubernetes Service can be changed using konghq.com/host-header annotation on the Service resource.

Method-Based Routing Using Ingress Resource

Kubernetes Ingress supports HTTP host and path-based routing. With Kong, you can now also perform HTTP method-based routing using the konghq.com/methods annotation. The Ingress rule will be matched only if the HTTP method in the request matches the methods listed in the annotation.

Usage details and other annotations are covered in the annotations documentation.

If you are upgrading from a previous version, please read the changelog carefully.

 

Upgrading

Breaking Changes

Starting with this release, the new status listen interface in Kong is used for Kubernetes-level health checks and to expose metrics data. Although this change is transparent to users on current versions, it does break compatibility with earlier versions of Kong Gateway before 1.4.0 and Kong Enterprise before 1.5.0.

Deprecations

This release deprecates support for Cassandra-backed Kong for Kubernetes installations. We recommend that users migrate to a DB-less or Postgres-backed installation at their earliest convenience. When migrating:

  • Configuration backed by Kubernetes resources and managed by the controller will be migrated automatically. It does not require a database.
  • Configuration added manually through the Admin API must be either converted to Kubernetes resources (which does not require a database) or exported and re-added (which does require a database). decK is recommended for exporting and re-adding configuration.
  • Enterprise configuration (primarily RBAC and Developer Portal configuration) requires a database and may require additional migration steps. Contact Kong Support for additional details.

Compatibility

Kong for K8s supports a variety of deployments and run-times. For a complete view of Kong for K8s compatibility, please see the compatibility document.

 

Getting Started

You can try out Kong for K8s using our lab environment, available for free to all at https://konghq.com/workshops/kong-for-kubernetes/.

You can install Kong for K8s on your Kubernetes cluster with one command:

Alternatively, if you want to use your own Kubernetes cluster, follow our getting started guide to get your hands dirty.

Please feel free to ask questions on our community forum — Kong Nation — and open a Github issue if you happen to run into a bug.

Happy Konging!