OpenID Connect, CLI, TUI, and Agent Skills

New CLI, TUI, and Agent Skills

Release 96.5 brings new CLI and TUI capabilities that leverage the Kpow REST API.

The CLI capabilities bring seven new agent skills that let a coding agent answer operational questions about Kafka.

See the new fh 1.0 release notes or watch the CLI, TUI, and Agentic Skills video guide presented by Chad Harris for more information.

Improved OpenID Connect (OIDC) Security Model

CLI and agentic skills are the first steps to allowing agentic access to the rich context we hold about your Kafka, Flink, and Iceberg resources. The next step is to release a full MCP implementation (watch this space).

Before we can allow agentic operations to Factor House products we need to ensure that we have the correct security model in place, with this in mind we have extended support for OIDC in our Web UI and API throughout all products.

Web UI OIDC Improvements

One common request for users who implement Kpow with OIDC is to avoid session-refresh from interrupting the user's UI state. Currenty when your OIDC session expires Kpow will redirect you through the IdP to re-authenticate, and you lose any context in your current UI session.

Refresh Tokens for Session Continuation

With release 96.5 we now support the BFF pattern and refresh tokens for session continuation, meaning that the Kpow server will handle session refresh behind the scenes, without interrupting your user session.

OIDC User Logout Support

Also new to release 96.5, if your OIDC provider support RP-initiated user logout your users will now be presented with the option to log-out of Kpow.

See the Kpow OIDC v2 documentation to understand how to upgrade Kpow to the latest OIDC implementation with refresh token and logout support.

API OIDC Security Model

Release 96.5 brings the ability to secure your Kpow API with OIDC for the first time.

This is how the FH CLI allows secure integration with the Kpow API for agentic access, and is a key requirement of the Model Context Prococol (MCP) specification for allowing AI applications access to external resources like Kpow.

With this new feature Kpow can be configured to accept OIDC access tokens as security credentials that authenticate and authorize your API users.

With OIDC security applied to your API, users who authenticate via access tokens have their access governed by Kpow's RBAC and Tenancy rules. This governance layer gives you fine-grained control of the resources an agent can see, and the actions they can take.

See the Kpow API OIDC documentation to understand how to configure OAuth2.0 Protected Resource Metadata and Access Token Validation to enable the new OIDC security model for your Kpow API.

Security and CVE Management

At Factor House we continually monitor the status of CVE within each of our products, and seek to ameliorate them at the earliest opportunity.

Kpow is scanned with OWASP Dependency-Check on each commit to trunk, and prior to release. We publish the OWASP report for each release (available under the Security/CVE tab above).

There are zero known CVE in Kpow (JVM 17+) at the date of releasing v96.5.

Read more about how the Factor House team manage security and CVE throughout our development and release process.

New Docker-Hardened Base Image

With v96.5 of Kpow we have introduced a new Docker container that uses the Docker Hardened Amazon Corretto base image.

Adopt this version of Kpow by using the following docker tag:

factorhouse/kpow:96.5-corretto-hardened

When using this hardened base image Kpow runs on Alpine Linux as opposed to our standard Docker image which runs on Amazon Linux 2023.

Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox and is well suited to JVM applications like Kpow that use few resources other than the installed JVM, memory, and network.

While the Amazon Corretto image that serves as the base of our standard Kpow container is well maintained and considered secure, we recommend adopting the corretto-hardened image for security conscious deployments.

In time we intend to move to the hardened image as the standard base image for all Factor House products.

For more information, see the Kpow Amazon Corretto Hardened Image Dockerfile.

Breaking: Logback Configuration Changes

Kpow uses Logback for application logging.

Configuration files using conditionals need to be migrated

In version 1.5.37 and subsequently in 1.6.x of Logback support for Janino-based conditional expressions was removed. Evaluating arbitrary Java expressions with the Janino library had led to numerous security vulnerabilities.

If you are using a custom logback.xml configuration and that configuration uses conditionals (as the default Kpow logback configuration does), then you will need to adjust your configuration to fit the new 1.6 method of conditional logging.

In short, where previously you had:

<if condition='isDefined("LOG_FORMAT")'>
    <then>
        <root level="INFO">
            <appender-ref ref="${LOG_FORMAT}"/>
        </root>
    </then>
    <else>
        <root level="INFO">
            <appender-ref ref="plain"/>
        </root>
    </else>
</if>

Now you should have:

<condition class="ch.qos.logback.core.boolex.IsPropertyDefinedCondition">
    <key>LOG_FORMAT</key>
</condition>
<if>
    <then>
        <root level="INFO">
            <appender-ref ref="${LOG_FORMAT}"/>
        </root>
    </then>
    <else>
        <root level="INFO">
            <appender-ref ref="plain"/>
        </root>
    </else>
</if>

See our application logs documentation for more information.