Kpow v91.2 is a minor release that introduces the new 'Resume Connector' bulk action and fixes a few outstanding small issues.

Kpow v90.6 introduces a new Dark Mode UI, improved intellisense, and confiugrable persistence settings.

Dark Mode

Start the new year right with the sleek new Dark Mode UI available in Kpow v90.6!

Improved Intellisense

From kJQ filters to Schema Editing, text entry input in Kpow has upgraded intellisense for JSON and EDN data.

Persistence Mode

Powered by two internal Kafka Streams applications, Kpow stores data in the first cluster in your configuration (we call this the Primary Cluster). This storage takes the form of several internal topics that are tuned to retain only a small amount of data.

In addition, an audit log topic is persisted permanently for data governance purposes.

These internal topics provide considerable feature support to Kpow, but there are circumstances in which you might want to turn them off.

Kpow v90.6 introduces a new PERSISTENCE_MODE environment variable that provides the following options to tune data storage:

Persistence Mode: Full (Default)

PERSISTENCE_MODE="full"

full is the current persistence behaviour of Kpow and utilizes the full set of internal topics.

This is the default behaviour of Kpow where no configuration is set.

Persistence Mode: Audit

PERSISTENCE_MODE="audit"

audit is a new persistence mode where the only internal topic that is created is the audit log.

This mode considerably reduces the amount of data written to Kafka, while retaining a full data governance trail.

When this mode is activated, certain features of Kpow run in a modified manner:

• Metrics charts are not re-hydrated on a Kpow restart (normally they hydrate from an internal changelog).
• Activity metrics (e.g. 'this topic was written to 3 minutes ago') are not persisted/maintained through a Kpow restart.
• Kpow Streams Agent integration is disabled

Persistence Mode: None

PERSISTENCE_MODE="none"

none is a new persistence mode where zero data is written to Kafka.

This mode ensures that no internal topics are created and no data is written by Kpow to your Kafka cluster.

When this mode is activated, certain features of Kpow run in a modified manner:

• Metrics charts are not re-hydrated on a Kpow restart (normally they hydrate from an internal changelog).
• Activity metrics (e.g. 'this topic was written to 3 minutes ago') are not persisted/maintained through a Kpow restart.
• Kpow Streams Agent integration is disabled
• Audit log and user log are not available
• Staged mutations are not available
• Bulk actions are not available

Kpow v90.5 fixes a regression in the 90.4 build of our Java 8 JAR artifact.

Java 8 Build Regression

In the 90.4 release of Kpow we updgraded our SAML client to latest, this brought a transitive dependency that required Java 11+.

This release rolls back that transitive dependency in our Java 8 build only.

Futureproofing

Our CI/CD process now runs full end-to-end build and tests on the Java 8 artifact with a Java 8 JRE.

This means we will catch any similar error earlier, in the automated build and release process.

If you have experienced an issue updating to Kpow v90.4 with Java 8, simply update to this release for the fix.

Kpow v90.4 introduces a new Bulk Actions feature that allows you to take action on multiple resources in one click.

This release also resolves performance issues related to materialization and internal scheduled tasks, freshens up our UI with new icons, fixes a long-standing Jetty JAAS expired-session login bug, open-sources a couple of cool Clojure libraries, and bundles a number of smaller fixes and improvements.

Thanks to all our users who raised issues or requested features that are highlighted in this release. We hope you all have a restful holiday period and we'll see you in 2023!

Bulk Actions

Bulk actions allow a user to invoke a single mutation against multiple resources.

This can be particularly useful for tasks such as deleting large numbers of items in one go, like the example of deleting 300 topics in a single request.

See the Bulk Actions documentation for a guide to configuring permissions for your users, and an explanation of how Bulk Action processing works.

In a future release we will expand on this feature, allowing mixed and scheduled bulk actions.

Eventually this function will be available programtically via an API for CI/CD and other purposes.

This feature is not available in the Community Edition of Kpow.

Materialization and Scheduling Performance Improvements

We recently received a performance report from a customer with the following installation and our Helm chart resource defaults (1CPU / 4GB heap)

• Single Kpow Installation
• 12 Kafka Clusters
• 6 Connect Clusters
• 6 Schema Registries

With their assistance we were able to isolate a bug in our internal scheduled task manager responsible for performing observation and materialization of the data we use to provide the Kpow UI. We also improved the performance of materialization by about 50%, significantly dropping CPU resource requirements.

Accompanying these improvements we have adjusted the default Helm resource requests to 2 CPU and 8 GB heap. Those defaults now represent the upper limit we expect you might need when running Kpow with 12 Cluster, 12 Connect, 12 Schema.

You should experiment and adjust your memory and CPU allocation, as it is likely for single cluster installs you may use significantly less than those defaults.

Authentication Improvements

We have been working over the previous months to open-source the Clojure network layer that we use to interact with Jetty (the Java networking framework).

That work is now complete and Slipway is available in Github and Clojars, as is Kpow Secure.

As a part of that work we updated our Jetty dependencies to latest, squashed a long-standing bug where a user might observe an internal error page when re-authenticating an expired session, and introduced the ability to secure your 'javax.net.ssl.trustStorePassword' when specifying custom SSL certificates to use with LDAPS.

Using Kpow Secure with trustStorePassword

Use the standard approach for encrypting configuration, see our secure-config guide for full details.

Example configuration with encrypted javax.net.ssl.trustStorePassword:

Example configuration with encrypted javax.net.ssl.trustStorePassword:

java -Djava.security.auth.login.config=dev-resources/jaas/ldaps-jaas.conf \
     -Djavax.net.ssl.trustStore=dev-resources/jaas/ldaps/local-client.jks \ 
     -Djavax.net.ssl.trustStoreType=JKS 
     -Djavax.net.ssl.trustStorePassword=AES:ARClD4Hz3A2VpdCGqZArl/OglnIawMHRzW0cVjraODxIeg== \ 
     -jar -Xmx4G ./kpow.jar

UX Improvements

We have removed the 'Multiple Kpow Detected' warning page and replaced it with a notification that appears in the top-right alerts.

This release also bumps Kpow's icon set up to HeroIcons v2.0 - we think they look great!

Community Improvements

The community edition wizard has been improved to support configuration of MSK Connect (along with existin support for Confluent/Kafka Connect).

As always you can simply run CE from environment variables if you prefer, see our Community Edition docs for more.

Kpow v90.3 improves OpenID Connect SSO configurability and the performance of tenancy materialization.

OpenID Configurability

In release 90.3 we improve support for generic OpenID Connect integration by providing two new variables, OPENID_USER_FIELD and roles_from.

Environment Variable - OPENID_USER_FIELD

The optional environment variable, OPENID_USER_FIELD, defines which field in the access token maps to a user's name (default: sub).

RBAC Configuration - roles_from

The optional RBAC configuration field, roles_from, specifies whether to use the access_token or id_token for roles mapping (default: access_token).

See our OpenID Connect documentation for full configuration options.

Custom Serdes in the kREPL

You can now use Custom Serdes in the kREPL by using their label directly in your query in place of any standard serdes.

Improved Scheduled Mutations UI/UX

Kpow now correctly shows the details of failed mutations, and more clearly differentiates between scheduled and executed mutations.

Improved Performance of Tenancy Materialization

Thanks to user reports we detected issues with tenancy materialization in larger installations of Kpow (10+ clusters).

Work in this area reduces CPU utilization by as much as 50% for tenancy materialization.

‍

Kpow v90.2 is a minor release featuring improved OpenID Connect SSO support.

OpenID Connect

Kpow provides a number of integrations for common SSO / Authentication providers.

In release 90.2 we extend support for generic OpenID Connect integration by providing a new OPENID_ISSUER environment variable.

Example Usage

Kpow validates the issuer presented in the authentication token as a part of the OpenID / OAuth2 SSO handshake process.

The default behaviour for most providers is to present the issuer field as a url that matches the base of your configured authentication uri.

Some providers present the issuer field in a different format, for example as a urn. You now have the option of specifying the expected issuer value like so:

OPENID_ISSUER=urn:com:corp:api:oauth2:v1

Where no OPENID_ISSUER field is set, Kpow will use the default uri validation.