What’s New in Kong Ingress Controller 3.1?
Kong Ingress Controller 3.1 provides brand-new capabilities for keeping your secrets secure. We’ve introduced new KongVault
and KongLicense
CRDs, and added a way to keep sensitive information in your cluster when using KIC in Konnect. Finally, there’s a quality-of-life improvement that allows you to use a Kubernetes secret to populate a single field in a KongPlugin
configuration.
KongLicense
If you’re a Kong Gateway Enterprise customer, you’re probably familiar with the process of placing your license in a Kubernetes secret before deploying Kong Gateway. The Helm chart mounts this secret at a well-known path in the Gateway container, and Kong Gateway reads a license from disk. This has worked so far, but we wanted to do better.
The biggest pain point of the “mount a secret” approach is that when your license is updated, pods need to be cycled to pick up the new value. This isn’t a huge task, but it’s also not frictionless.
In Kong Ingress Controller 3.1, we’ve added support for using the Kong Admin API to apply licenses to running Gateways. This allows you to apply or update a license on demand, without needing to cycle the pod.
Create a new KongLicense
CRD in your cluster, and KIC will take care of the rest. To learn more, see the KongLicense documentation.
KongVault
Support for secret vaults is a powerful Kong Gateway feature, and they’re now a first-class citizen for Kong Gateway users on Kubernetes.
The KongVault
CRD allows you to manage Vault entities in Kong Gateway. It provides access to AWS Secrets Manager, Azure Key Vaults, Google Secrets Manager, and Hashicorp Vault. Secrets from these vaults can be used to inject sensitive information such as certificate private keys and plugin configuration fields at runtime. Here’s an example that configures an AWS SM vault in us-west-2
:
All supported vaults can be configured using the KongVault CRD. For more information, see the Vaults on Kubernetes documentation.
KongPlugin ConfigPatch
Kong Ingress Controller supports reading KongPlugin
configuration from Kubernetes secrets using the configFrom
pattern. KIC 3.1 enhances this capability by allowing individual fields to be read from secrets, with the rest of the configuration being provided as plain text.
This is done using a new configPatches
property in the KongPlugin
CRD. configPatches
is a list of JSON patches to apply. Each patch contains a path
and a valueFrom
entry that references a secret in the same namespace.
The majority of the plugin is available in plain text in the KongPlugin
resource. This makes understanding what’s being applied much easier for operators. The redis_password
key is populated using a Kubernetes secret:
It’s worth noting that the Kong Ingress Controller resolves secrets before sending the configuration to Kong Gateway. Secrets injected using configPatches will be visible in plain text in the admin API. For a more secure option, we recommend using Kong Vault with an external vault such as AWS Secrets Manager, Hashicorp Vault or any other supported vault.
KIC in Konnect
The Kong Ingress Controller control plane in Kong Konnect is a read-only view of your Kong Gateway configuration. The ingress controller sends the configuration directly to the data plane and then mirrors the configuration to Konnect.
Many configurations contain sensitive information such as certificate private keys. These values were being transmitted to Konnect, but could not be used to configure data planes. KIC 3.1 adds a new SanitizeKonnectConfigDumps
feature gate, which prevents sensitive data from being sent to Konnect. When enabled, certificate private keys will not leave your cluster.
The SanitizeKonnectConfigDumps
feature gate is enabled by default, so upgrade to KIC 3.1 to try it today.
Try Kong Ingress Controller 3.1
For a full list of features, fixes, and updates please see the CHANGELOG.
As always, the quickest way to get started with KIC 3.1 is with Kong Konnect thanks to our KIC in Kong Konnect functionality.