Release 0.15.0

This release introduces data retention filters for restores, SASL/OAUTHBEARER authentication for Kafka, global logging configuration, custom S3-compatible storage endpoints, and an updated plugin API.

Installation

For new installations, see the Installation guide.

For upgrading existing installations, see the associated Upgrading to 0.15.x guide.

Minimum Kubernetes version

The minimum required version of Kubernetes has been increased from 1.28 to 1.30. Make sure your cluster is running Kubernetes 1.30 or later before upgrading.

Restore filters

The restore configuration now supports a nested config.filters structure, replacing the previous flat restoreFromDateTime and restoreUntilDateTime fields. The old fields are still supported for backward compatibility but are now deprecated.

apiVersion: kannika.io/v1alpha
kind: Restore
metadata:
  name: restore
spec:
  source: "storage"
  sink: "kafka"
  config:
    restoreFromDateTime: "2021-01-01T00:00:00Z"
    restoreUntilDateTime: "2021-02-01T00:00:00Z"
    filters:
      time:
        absolute:
          fromDateTime: "2021-01-01T00:00:00Z"
          toDateTime: "2021-02-01T00:00:00Z"

Data retention filters

Restores now support data retention filters, giving you fine-grained control over which records are restored based on time. You can specify an absolute time window with a start and end timestamp, or apply the target topic’s retention policy to automatically filter out expired records during the restore. Both options can be combined.

Applying the target topic's retention period during a restore.

The corresponding Restore CRD uses a nested config.filters.time.retention structure:

apiVersion: kannika.io/v1alpha
kind: Restore
metadata:
  name: restore-filters
spec:
  source: "storage"
  sink: "kafka"
  config:
    filters:
      time:
        retention:
          policies:
            - ApplyTargetTopicRetention
    topics:
      - target: target-topic
        source: source-topic

Filtering restored records Learn how to filter records during a restore using time windows and retention policies.

SASL/OAUTHBEARER credentials

You can now authenticate to Kafka clusters using SASL/OAUTHBEARER, in addition to the existing PLAIN and SCRAM mechanisms. This enables integration with OAuth 2.0 identity providers using the Client Credentials flow.

The console provides a dedicated form for setting up OAUTHBEARER credentials.

Configuring OAUTHBEARER credentials in the console.

The corresponding Credentials CRD references Kubernetes secrets for the client ID and secret:

apiVersion: kannika.io/v1alpha
kind: Credentials
metadata:
  name: kafka-sasl-oauth-creds
spec:
  sasl:
    mechanism: OAUTHBEARER
    tokenEndpoint: https://idp.example.com/oauth2/token
    clientIdFrom:
      secretKeyRef:
        name: oauth-secret
        key: client-id
    clientSecretFrom:
      secretKeyRef:
        name: oauth-secret
        key: client-secret
    scope: "kafka"
    extensions:
      - key: "logicalCluster"
        value: "lkc-abc123"

SASL authentication Learn how to configure SASL authentication for Kafka EventHubs.

Global logging configuration

A new global logging configuration allows you to set the log format and level for all Armory components from a single place in your Helm values. The settings are propagated to the operator, API, and all runtime pods including backup and restore jobs.

global:
  logging:
    format: "json"
    level: "info"

Individual resources can still override the global settings using extraEnvVars.

Logging configuration Learn how to configure logging for all Armory components.

Custom S3 endpoint

Armory now supports custom S3-compatible storage backends such as MinIO or Akave. You can specify a custom endpoint URL and enable path-style addressing for providers that do not support virtual-hosted-style bucket access.

Configuring a custom S3-compatible endpoint in the console.

apiVersion: kannika.io/v1alpha
kind: Storage
metadata:
  name: s3-akave
spec:
  s3:
    bucket: my-bucket
    endpoint: https://o3-rc3.akave.xyz
    forcePathStyle: true

S3-compatible storages Learn how to configure S3-compatible storage backends.

Updated plugin API

This release introduces version 0.2 of Armory’s plugin interface, defined using WIT (Wasm Interface Type). Restore plugins now receive the target topic’s configuration, enabling plugins like topic-retention to read the target topic’s retention.ms and filter out expired records automatically.

The plugin interface definitions are available at https://github.com/kannika-io/armory-plugins-wit.

Improvements

• Improved reliability by retrying per-topic metadata fetching with backoff when initial cluster-wide metadata fetch fails during a restore.

• The console now displays existing SASL secret references and includes a password reveal toggle, instead of showing empty fields that required re-entering all values.

• Partition offsets are now persisted in the backup metrics database.

• Improved API connection error messages in the console.

• Added actionable context to storage backend error messages.

Bug fixes

• Backup: fixed offset lag calculation for empty topics due to missing sink offset, by falling back to consumer offset.

• Console: fixed platform info warning icon from clipping when the sidebar is collapsed.

Breaking changes

• The minimum required version of Kubernetes has been increased from 1.28 to 1.30.

Release notes

For a full list of changes, see the Changelog.