Platform Manager 16.0.0 Readme

Overview

The Management API is part of the Topic Catalog system, designed to serve as a customer portal for managing and interacting with their part of the Axual Platform. It is used to administer the Axual platform to perform activities like:

  • View Topic availability on different environments

  • Request Topic deployments

  • Manage own environments

  • and more…

Installation & Configuration

Default Roles

When a new user is created in Platform Manager, certain roles can be automatically granted. These roles can be defined in the application.yml config as below:

axual:
  default-roles: APPLICATION_AUTHOR, ENVIRONMENT_AUTHOR, STREAM_AUTHOR

By default, APPLICATION_AUTHOR, ENVIRONMENT_AUTHOR and STREAM_AUTHOR roles are automatically granted to every new user in Self Service.

Schema Compatibility Checks

During stream deployment, a mandatory step is to verify the compatibility of the AVRO, PROTOBUF or Json schema (if changed). In some cases, it is desirable to force the topic apply.

This force field is added in the StreamConfig object.

{
  "keySchemaVersion": "http://localhost:8080/schema_versions/5322f72742cd4c6db07b9a71a825fe4f",
  "force": true
}

Flyway DB Migration

We use Flyway for version control and easy schema evolving of a Platform Manager database. Flyway will automatically run the SQL files to upgrade the database to required level.

Cross Origin Resource Sharing (CORS)

By default, CORS is enabled for all origins, methods and headers. To change this behaviour, Cross Origin Resource Sharing can be configured as below:

cors-allowed-origin-patterns is a list of accepted origin urls with which the response can be shared. To accept all, use the value '*'

cors-allowed-methods is a list of allowed HTTP methods in response to a pre-flight request. By default GET, POST, PUT, PATCH, HEAD and DELETE are allowed.

cors-allowed-headers is a list of accepted headers. To accept all, use the value '*'

cors-exposed-headers is a list of headers that can be exposed (accessed by clients). Simple response headers Cache-Control, Content-Language, Content-Type, Expires, Last-Modified and Pragma are already safe-listed so can be ignored in this list. Refer https://developer.mozilla.org/en-US/docs/Glossary/Simple_response_header for more details.

cors-max-age defines the time in seconds the client should cache the pre-flight response. In Platform Manager it is set to 3600 by default.

Example #1 - Allow all origins and all headers, with default methods

axual:
  rest:
    cors-allowed-origin-patterns:
      - '*'
    cors-allowed-headers:
      - '*'

Example #2 - Allow origin http://localhost and https://somewhere to access the service for the GET and POST methods for all headers:

axual:
  rest:
    cors-allowed-origin-patterns:
      - 'http://localhost'
      - 'https://somewhere'
    cors-allowed-methods:
      - 'GET'
      - 'POST'
    cors-allowed-headers:
      - '*'

Example #3 - Allow all origins to access the service for the GET and POST methods for Origin, Content-type and X-Requested-With headers:

axual:
  rest:
    cors-allowed-origin-patterns:
      - 'http://localhost'
      - 'https://somewhere'
    cors-allowed-methods:
      - 'GET'
      - 'POST'
    cors-allowed-headers:
      - 'Origin'
      - 'Content-Type'
      - 'X-Requested-With'

Vault Configuration

Platform Manager supports HashiCorp Vault for secure storage of credentials, certificates, and secrets. There are four distinct vault types, each serving different purposes:

Vault Type Purpose Scope

Governance Vault

Stores KSML application secrets, cluster credentials, and schema registry details

Single vault for entire governance system

Connector Vault

Stores connector certificates for legacy Axual Connect applications

Single vault shared across all tenant-instances

Instance Connector Vault

Stores connector certificates for legacy Axual Connect applications

Isolated vault per tenant-instance

Kafka Connect Cluster Vault

Stores mTLS/SASL_SCRAM credentials for a registered Kafka Connect cluster

Isolated vault per registered ConnectCluster

Note: Use either Connector Vault OR Instance Connector Vault, not both. Instance Connector Vault provides better isolation for multi-tenant deployments. Kafka Connect Cluster Vault is independent of both — it applies only to connector applications deployed to a registered Kafka Connect cluster (see below), and is configured per cluster, not via application.yml.

Governance Vault

The Governance Vault stores high-level secrets for KSML applications, clusters, and schema registries. It is mandatory for production deployments.

Configuration Properties:

governance:
  vault:
    enabled: true
    uri: https://vault.example.com:8200
    role-id: a876f265-b031-861f-d51b-2113602a1c34
    secret-id: e90bcb18-6a80-a8ee-ea34-5a607ef76bff
    path: governance                    # KV secret engine path (default: governance)
    namespace: my-namespace             # optional - Vault Enterprise namespace
    approle-path: approle               # optional - custom AppRole mount path (default: approle)
Property Required Default Description

enabled

Yes

false

Enables Governance Vault integration

uri

Yes

-

Vault server URI

role-id

Yes

-

AppRole Role ID for authentication

secret-id

Yes

-

AppRole Secret ID for authentication

path

No

governance

KV v2 secret engine mount path

namespace

No

-

Vault Enterprise namespace (if applicable)

approle-path

No

approle

Custom AppRole authentication mount path

Resources Stored:

Resource Path Pattern Description

KSML Application Principals

{path}/{tenant}/{instance}/{environment}/{application}

Private keys for KSML application authentication

Cluster Credentials

{path}/{tenant}/{cluster}

Kafka cluster bootstrap servers and security credentials

Schema Registry Credentials

{path}/{tenant}/{instance}/{cluster}

Schema Registry authentication details and Keycloak admin passwords

Distribution Secrets

{path}/{tenant}/{instance}/{cluster}/distribution

Distribution deployment credentials

Connector Vault (Single Vault)

The Connector Vault stores connector certificates for Kafka Connect applications in a single vault shared across all tenant-instances.

Configuration Properties:

vault:
  enabled: true
  uri: https://vault.example.com:8200
  role-id: a876f265-b031-861f-d51b-2113602a1c34
  secret-id: e90bcb18-6a80-a8ee-ea34-5a607ef76bff
  connectors-path: connectors           # KV engine path for SSL certificates
  credentials-path: credentials         # KV engine path for SASL credentials
  private-key-name: private.key         # Key name for private keys in Vault
  cert-chain-key-name: certificate.chain # Key name for certificate chains in Vault
  namespace: my-namespace               # optional - Vault Enterprise namespace
  approle-path: approle                 # optional - custom AppRole mount path (default: approle)
Property Required Default Description

enabled

Yes

false

Enables Connector Vault integration

uri

Yes

-

Vault server URI

role-id

Yes

-

AppRole Role ID for authentication

secret-id

Yes

-

AppRole Secret ID for authentication

connectors-path

Yes

-

KV v2 path for storing SSL certificates

credentials-path

Yes

-

KV v2 path for storing SASL credentials

private-key-name

Yes

-

Map key name for private keys (e.g., private.key)

cert-chain-key-name

Yes

-

Map key name for certificate chains (e.g., certificate.chain)

namespace

No

-

Vault Enterprise namespace (if applicable)

approle-path

No

approle

Custom AppRole authentication mount path

Resources Stored:

Resource Engine Path Secret Path Description

Application SSL Principals

connectors

{tenant}/{instance}/{environment}/{application}

Private keys and certificate chains for application authentication

SASL/SCRAM Credentials

credentials

{tenant}/{instance}/{environment}/{application}/{credential-type}

Username/password pairs (SCRAM_SHA_256, SCRAM_SHA_512, PLAIN)

Instance Connector Vault (Per Tenant-Instance)

The Instance Connector Vault stores connector certificates for Kafka Connect applications, with isolated vaults per tenant-instance for enhanced security and separation. Recommended for multi-tenant installations where strict data isolation is required.

Configuration Properties:

connector-vault:
  enabled: true
  instances:
    axual-qa: # tenant-instance name (format: {tenant}-{instance})
      uri: https://vault.example.com:8200
      role-id: a876f265-b031-861f-d51b-2113602a1c34
      secret-id: e90bcb18-6a80-a8ee-ea34-5a607ef76bff
      connectors-path: connectors
      credentials-path: credentials
      private-key-name: private.key
      cert-chain-key-name: certificate.chain
      namespace: ns1                    # optional - Vault Enterprise namespace
      approle-path: approle             # optional - custom AppRole mount path (default: approle)
      key-store: classpath:client.jks   # optional - client keystore for mTLS
      key-password: notsecret           # optional - private key password
      key-store-password: notsecret     # optional - keystore password
      trust-store: classpath:truststore.jks  # optional - truststore for server verification
      trust-store-password: notsecret   # optional - truststore password
    axual-prod:
      uri: https://vault-prod.example.com:8200
      role-id: b987f376-c142-972g-e62c-3224713b2d45
      secret-id: f01cdc29-7b91-b9ff-fb45-6b718fg87cgg
      connectors-path: connectors
      credentials-path: credentials
      private-key-name: private.key
      cert-chain-key-name: certificate.chain
      namespace: ns2
      approle-path: custom-approle      # example of custom AppRole path
Property Required Default Description

enabled

Yes

false

Enables Instance Connector Vault integration

instances.<name>.uri

Yes

-

Vault server URI for this tenant-instance

instances.<name>.role-id

Yes

-

AppRole Role ID for authentication

instances.<name>.secret-id

Yes

-

AppRole Secret ID for authentication

instances.<name>.connectors-path

Yes

-

KV v2 path for storing SSL certificates

instances.<name>.credentials-path

Yes

-

KV v2 path for storing SASL credentials

instances.<name>.private-key-name

Yes

-

Map key name for private keys

instances.<name>.cert-chain-key-name

Yes

-

Map key name for certificate chains

instances.<name>.namespace

No

-

Vault Enterprise namespace

instances.<name>.approle-path

No

approle

Custom AppRole authentication mount path

instances.<name>.key-store

No

-

Path to client keystore for mTLS with Vault

instances.<name>.key-password

No

-

Password for the private key in keystore

instances.<name>.key-store-password

No

-

Password for the keystore

instances.<name>.trust-store

No

-

Path to truststore for Vault server verification

instances.<name>.trust-store-password

No

-

Password for the truststore

Resources Stored:

Resource Engine Path Secret Path Description

Application SSL Principals

connectors

{tenant}/{instance}/{environment}/{application}

Private keys and certificate chains for application authentication

SASL/SCRAM Credentials

credentials

{tenant}/{instance}/{environment}/{application}/{credential-type}

Username/password pairs (SCRAM_SHA_256, SCRAM_SHA_512, PLAIN)

Kafka Connect Cluster Vault (AXPD-11425)

Each registered ConnectCluster (Kafka Connect deployment target, added under System Management) can have its own Connector Vault, entirely separate from the Governance/Connector/Instance Connector Vaults above. Unlike those, most of it is not configured via application.yml; it is a set of fields on the ConnectCluster entity itself, set when the cluster is registered (POST/PUT on the Connect cluster resource), so every Kafka Connect cluster can point at a different Vault instance and AppRole. The one exception is the Vault engine mount name: that is shared by every registered cluster and configured once by the operator at PM startup.

PM Startup Configuration:

axual:
  systemmanagement:
    kafka-connect:
      vault:
        engine-path: connector-auth   # optional - KV v2 engine mount every ConnectCluster's Vault shares
Property Required Default Description

axual.systemmanagement.kafka-connect.vault.engine-path

No

connector-auth

Vault KV v2 secret engine mount name shared by every registered ConnectCluster’s Connector Vault. Set once by the operator at PM startup — not per-cluster.

ConnectCluster Vault Fields:

Field Required Default Description

connectorVaultUrl

Yes

-

Vault server URI for this cluster’s Connector Vault

connectorVaultPath

Yes

-

Data-path prefix segment for this cluster, under the shared engine mount above (not an engine name itself)

connectorVaultApprolePath

No

approle

Custom AppRole authentication mount path

AppRole role-id / secret-id

Yes

-

Resolved per cluster+environment via ConnectClusterAppRoleResolver, not stored inline on the cluster row

Resources Stored (under the engine-path mount from PM startup config):

Resource Path Pattern Description

mTLS active secret

{connectorVaultPath}/{tenant}/{instance}/{cluster_name}/tls/{env}/{app}

Cert chain (PEM) + private key for the currently active principal

mTLS storage secret

{connectorVaultPath}/{tenant}/{instance}/{cluster_name}/tls/{env}/{app}/{uid}

Private key only, written on principal upload, keyed by principal id — always present regardless of the cluster’s current auth method

SASL_SCRAM credential

{connectorVaultPath}/{tenant}/{instance}/{cluster_name}/sasl/{env}/{app}/{credential_type}

Username/password for the connector’s Kafka credential (currently always scram-sha-512)

SR basic-auth credential

{connectorVaultPath}/{tenant}/{instance}/{cluster_name}/sr/{env}/{app}/{credential_type}

Username/password for the connector’s Schema Registry credential (currently always basic-auth); generated automatically on connector start, never returned in any API response

Required Vault ACL policy for the AppRole: grant on a nested glob under connectorVaultPath, not the bare path itself — no secret is ever written directly at {connectorVaultPath}, only under it (see Resources Stored above). Vault ACL globs are literal prefix matches, so …​/{connectorVaultPath}/* never covers the bare path without the trailing segment — no separate exact-match stanza is needed. KV v2 delete uses separate delete/destroy sub-paths from data/metadata, so all four are required or deletes 403:

path "{engine-path}/data/{connectorVaultPath}/*"     { capabilities = ["create", "read", "update", "delete"] }
path "{engine-path}/metadata/{connectorVaultPath}/*" { capabilities = ["list", "read", "delete"] }
path "{engine-path}/delete/{connectorVaultPath}/*"   { capabilities = ["update"] }
path "{engine-path}/destroy/{connectorVaultPath}/*"  { capabilities = ["update"] }

How it differs from the Connector/Instance Connector Vault above:

  • Scope: the Vault URL, AppRole, and connectorVaultPath prefix are per-ConnectCluster row, not per-tenant-instance or global — a single Instance can have multiple registered Connect clusters, each pointing at its own Vault. Only the engine mount name (engine-path) is shared globally, set once at PM startup.

  • mTLS credential format: PEM cert chain + PEM private key only. No JKS/keystore support.

  • Two-phase mTLS: uploading a principal (POST /application_principals) always writes its private key to the uid-suffixed storage path, independent of the cluster’s authMethod at that time. The cert itself is only ever combined with the key and written to the shared active path on POST /application_principals/{id}/activate — which is also where the cluster’s authMethod is actually enforced (MTLS required; SASL_SCRAM rejects activation with a clear error). This means a cluster can be switched between SASL_SCRAM and MTLS after a principal is uploaded without losing the ability to activate it later.

  • SASL_SCRAM rotation: a new credential simply overwrites the existing one at the same path — no versioned storage path like mTLS.

  • Schema Registry credential: generated automatically the first time a connector is started (not at grant time, and regardless of which Topics have grants) — always basic-auth, never OAuth or mTLS. A no-op if a credential already exists, or if the target cluster’s InstanceCluster isn’t configured for Apicurio basic-auth.

  • Delete: an inactive, non-last principal’s own uid-path secret is always removed on delete regardless of active/inactive status (it is never shared with another principal); the shared active-path secret is only removed by whichever principal currently owns it. Both deletes resolve the target cluster regardless of its current authMethod, so a secret written before a SASL_SCRAM↔MTLS switch is still reachable and doesn’t get orphaned in Vault.

AppRole Authentication Path (approle-path)

The approle-path configuration allows you to specify a custom mount path for AppRole authentication in HashiCorp Vault. This is useful when:

  • Your Vault instance has AppRole enabled at a non-standard path

  • You have multiple AppRole auth methods for different purposes

  • Your organization uses a naming convention for auth method paths

Default: approle (the standard HashiCorp Vault default)

Example with custom path:

governance:
  vault:
    enabled: true
    uri: https://vault.example.com:8200
    role-id: ...
    secret-id: ...
    approle-path: platform-manager-auth  # Custom AppRole mount path

This corresponds to the Vault CLI command:

vault auth enable -path=platform-manager-auth approle

Development Profile (Database-backed Vault)

For development environments, Platform Manager provides a database-backed vault alternative that doesn’t require a real HashiCorp Vault instance.

Configuration:

spring:
  profiles:
    active: dev

When vault is disabled, credentials are stored in the credentials_store database table. This should never be used in production environments.

OpenTelemetry Tracing Configuration

The service uses spring-boot-starter-opentelemetry for distributed tracing.

By default, tracing is enabled with 100% sampling, but OTLP export is disabled.

Enabling Trace Export

To export traces to an OTLP collector (such as Jaeger, Prometheus, or others), configure:

management:
  tracing:
    export:
      enabled: true
  opentelemetry:
    tracing:
      export:
        otlp:
          endpoint: http://otlp-collector:4317  # Replace with your OTLP collector URL
          transport: grpc  # Export protocol: grpc or http/protobuf
          headers: # Custom HTTP headers you want to pass to the collector, for example auth headers.
            key: value

Depending on the instrumentation backend, you may want to add custom headers.

To add additional tracing metrics, please refer to Spring Boot documentation: https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#actuator.micrometer-tracing

Adjusting Sampling

The trace.sampling.probability property controls the fraction of spans that are collected. Setting it to 1.0 means all spans will be exported.

To adjust the sampling rate (default is 100%):

management:
  tracing:
    sampling:
      probability: 0.1  # 10% sampling

Support for Spring Boot 3.5.x properties

The service has support for Spring Boot 3.5.x OpenTelemetry properties.

You can use the following Spring Boot 3.5.x properties to configure OpenTelemetry:

management:
  tracing:
    enabled: true
  otlp:
    tracing:
      endpoint: http://otlp-collector:4317  # Replace with your OTLP collector URL
      transport: grpc  # Export protocol: grpc or http/protobuf
      headers: # Custom HTTP headers you want to pass to the collector, for example auth headers.
        key: value

The service will map each Spring Boot 3.5.x property to the corresponding Spring Boot 4.x OpenTelemetry property.

Spring Boot 3.5.x property Spring Boot 4.x property Default value

management.tracing.enabled

management.tracing.export.enabled

false

management.otlp.tracing.compression

management.opentelemetry.tracing.export.otlp.compression

"none"

management.otlp.tracing.connect-timeout

management.opentelemetry.tracing.export.otlp.connect-timeout

10s

management.otlp.tracing.endpoint

management.opentelemetry.tracing.export.otlp.endpoint

""

management.otlp.tracing.export.enabled

management.tracing.export.otlp.enabled

true

management.otlp.tracing.headers

management.opentelemetry.tracing.export.otlp.headers

""

management.otlp.tracing.timeout

management.opentelemetry.tracing.export.otlp.timeout

10s

management.otlp.tracing.transport

management.opentelemetry.tracing.export.otlp.transport

"http"

Schema Registry OAuth

Platform Manager supports OAuth authentication for Schema Registry (Apicurio) via Keycloak. When enabled, applications can register as OAuth clients in Keycloak instead of using Basic Auth credentials.

To enable Schema Registry OAuth, configure the client secret salt used for deterministic secret generation:

axual:
  application-management:
    apicurio:
      clientSecretSalt: "<your-secret-salt>"
      clientSecretAlgorithm: HmacSHA256  # optional, defaults to HmacSHA256
Property Required Default Description

axual.application-management.apicurio.clientSecretSalt

Yes

-

Salt used as HMAC key for deterministic client secret generation. Without this property, Schema Registry OAuth is disabled.

axual.application-management.apicurio.clientSecretAlgorithm

No

HmacSHA256

Cryptographic algorithm used for client secret generation.

Note: Schema Registry OAuth is not supported for Axual Managed KSML applications.

Helm Chart: Audit Log File Output

The Platform Manager Helm chart deploys the application as a Deployment resource. When auditLog.enabled: true, audit events are written as JSONL (one JSON object per line) to a rolling log file inside the pod’s /logs directory, which is backed by an emptyDir volume. Logs do not survive pod restarts. To ship logs to an external system, add a sidecar container via extraContainers that reads from the same /logs volume.

Loggers

Below is a per-package breakdown of important packages to help operators configure logging:

Package Logger Description

io.axual.governance

Root Package

Platform Manager root package

io.axual.governance.applicationmanagement

Application Management

Kafka application credentials, principals, access grants, and authentication

io.axual.governance.applicationmanagement.web

Application API

REST API endpoints for application management operations

io.axual.governance.applicationlifecycle.connect

Connect Lifecycle

Kafka Connect connector deployments, lifecycle management, and status monitoring

io.axual.governance.applicationlifecycle.ksml

KSML Lifecycle

KSML application deployments, lifecycle operations, and state transitions

io.axual.governance.streammanagement.processor

Topic Processing

Topic configuration deployment, resolution, and topic mapping operations

io.axual.governance.streammanagement.validator

Topic Validation

Topic configuration validation and ACL collision detection

io.axual.governance.streammanagement.web

Topic API

REST API endpoints for Topic management operations

io.axual.governance.schemamanagement

Schema Management

Avro, JSON, and Protobuf schema version management and validation

io.axual.governance.schemamanagement.web

Schema API

REST API endpoints for schema management operations

io.axual.governance.systemmanagement.service

System Management

Cluster, Instance, Environment, and Schema Registry infrastructure management

io.axual.governance.systemmanagement.connect

Connect System

Kafka Connect system integration, ACL operations, and cluster operations

io.axual.governance.systemmanagement.connect.rest

Connect REST Client

REST client communication with Kafka Connect clusters

io.axual.governance.systemmanagement.keycloak

Keycloak Integration

Keycloak SSO integration and client configuration

io.axual.governance.systemmanagement.web

System API

REST API endpoints for system management operations

io.axual.governance.tenantmanagement.user

User Management

User account and profile management operations

io.axual.governance.tenantmanagement.group

Group Management

Group management operations

io.axual.governance.tenantmanagement.web

Tenant API

REST API endpoints for tenant operations

io.axual.governance.kameleon.governance

Kameleon Governance

Core governance operations on Kafka clusters (topic details, ACL operations)

io.axual.governance.kameleon.infrastructure.provider.kafka

Kafka Cluster Operations

Kafka AdminClient operations and cluster management

io.axual.governance.kameleon.infrastructure.provider.kafka.topic

Kafka Topic Operations

Topic creation, update, and management operations

io.axual.governance.kameleon.infrastructure.provider.kafka.acl

Kafka ACL Operations

ACL binding creation and management

io.axual.governance.kameleon.clusterimport

Cluster Import

Cluster discovery and import operations

io.axual.governance.clusterimportmanagement.processor

Import Processor

Cluster import processing for topics, ACLs, and system entities

io.axual.governance.security.filter

Security Filters

HTTP authentication filters and request processing

io.axual.governance.security.abac

ABAC Authorization

Attribute-Based Access Control (ABAC) permission evaluation

io.axual.governance.notifications.service

Notification Service

Email and event notifications

io.axual.governance.kms.db

DB Vault

Database-backed vault for credential storage (development profile)

io.axual.governance.kms.hashicorp

HashiCorp Vault

HashiCorp Vault integration for credential management

io.axual.governance.offboarding.web

Offboarding Service

Tenant offboarding and cleanup operations

io.axual.governance.organizationmanagement.infrastructure.keycloak

Organization Keycloak

Keycloak event listening and organization SSO integration

io.axual.governance.core.exception

Exception Handler

Global exception handling and error responses

io.axual.governance.auditing

Audit Service

Audit event listener and trail operations

io.axual.governance.AuditLogger

Audit Logger

Main audit logging facility for all governance events and changes

io.axual.governance.asyncapi.service

AsyncAPI Documentation

AsyncAPI documentation generation service

io.axual.governance.distributionlifecycle

Distribution Lifecycle

Distribution deployment configuration and operations

io.axual.governance.streambrowse.web

Topic Browse

Topic data browsing operations

io.axual.governance.insights

Admin Insights

Scheduled collection of aggregated platform usage data (resource ownership, topic volume, unused topics)

io.axual.governance.insights.web

Insights API

REST API endpoints for insights queries

The Kafka client config dump (AbstractConfig), AppInfoParser, Metrics and AbstractLogin loggers are set to WARN by default, since every short-lived AdminClient would otherwise log its full configuration and lifecycle at INFO.

Notifications Service Configuration

You can enable Notifications service using SMTP server for the Platform Manager, to notify application and stream owners by receiving emails whenever something important happens with their applications or streams. Below you can find the configurations that are defined to enable/disable the Notifications service for the Platform Manager application. Currently, we only support the SMTP server, and it needs to be enabled when the notifications is enabled.

platform-manager:

  config:
    axual:
      # Notifications Configuration
      notifications:
        enabled: true
        sender: [email address of the notification sender]
        smtp:
          enabled: true

Then you need to provide Spring configurations of the SMTP server:

platform-manager:

  config:
    spring:
      mail:
        host: [domain names or IP addresses of SMTP servers, e.g : smtp.gmail.com]
        port: [port number of the SMTP server]
        username: [username corresponds to the sender email account]
        password: [password corresponds to the sender email account]
        properties:
          mail:
            smtp:
              auth: true
              starttls:
                enable: true

Event Publication Completion Mode Configuration

By default, event publications are marked as completed when a transactional execution completes successfully. The completion is registered by setting the completion date on an EventPublication. This means that completed publications remain in the Event Publication Registry indefinitely, and the database table will grow unbounded over time.

Spring Modulith provides the spring.modulith.events.completion-mode configuration property to control how completed event publications are handled. The default mode for Axual Platform Manager is DELETE, which automatically removes event publications from the database upon completion.

platform-manager:

  config:
    spring:
      modulith:
        events:
          # -- Completion mode for event publications (UPDATE, DELETE, or ARCHIVE)
          completion-mode: DELETE

With the DELETE mode enabled, completed event publications are automatically removed from the database, preventing the persistence store from growing unbounded. The CompletedEventPublications interface will not return any publications. If you are upgrading from a previous configuration where completed events were being accumulated, you can clean up existing completed event publications using the following SQL script:

--
-- Clear completed event publications from the EVENT_PUBLICATION table
-- This script removes all completed event publications to prevent database bloat.
-- With spring.modulith.events.completion-mode=DELETE, new completed publications
-- will be automatically deleted from the database.
--

DELETE FROM EVENT_PUBLICATION
WHERE COMPLETION_DATE IS NOT NULL;

Scheduler Timestamp Configuration

Scheduled tasks (db-scheduler) store their execution times in zone-less DATETIME/TIMESTAMP columns. Platform Manager persists these timestamps in UTC so they are read back correctly regardless of the JVM or database timezone.

platform-manager:

  config:
    db-scheduler:
      always-persist-timestamp-in-utc: true
Property Required Default Description

db-scheduler.always-persist-timestamp-in-utc

No

true

Persist scheduled task timestamps in UTC instead of the JVM default timezone

Insights Configuration

The Insights feature collects aggregated platform usage data on a configurable schedule. Two background jobs run independently:

  • Resource ownership: counts topics, application deployments, and environments per group

  • Topic volume: tracks message counts and identifies unused topics per environment

Both schedules use standard cron expressions and default to running daily at midnight.

scheduler:
  insights:
    resources:
      cron: "0 0 0 * * ?"      # Resource ownership collection schedule
    topic-volume:
      cron: "0 0 0 * * ?"      # Topic volume collection schedule
Property Required Default Description

scheduler.insights.resources.cron

Yes

0 0 0 * * ?

Cron schedule for the resource ownership insights job

scheduler.insights.topic-volume.cron

Yes

0 0 0 * * ?

Cron schedule for the topic volume insights job

Audit History Retention & Cleanup

When auditing is enabled (axual.audit.enabled=true), audit events are persisted to the database. A scheduled job periodically deletes audit history older than the configured retention period, in batches, to keep the table from growing unbounded.

axual:
  audit:
    enabled: false
    history-retention-days: 365
    cleanup-cron: "0 0 3 * * ?"   # daily at 3 AM
    cleanup-batch-size: 1000
    cleanup-batch-delay-ms: 50
Property Required Default Description

axual.audit.enabled

No

false

Master switch for audit event persistence (also exposed as AXUAL_AUDIT_ENABLED).

axual.audit.history-retention-days

No

365

Age, in days, beyond which audit history rows are deleted by the cleanup job.

axual.audit.cleanup-cron

No

0 0 3 * * ?

Cron schedule for the audit history cleanup job.

axual.audit.cleanup-batch-size

No

1000

Number of audit rows deleted per batch.

axual.audit.cleanup-batch-delay-ms

No

50

Delay, in milliseconds, between consecutive delete batches (throttles database load).

Certificate Expiry Checks

A scheduled job inspects managed certificates and publishes expiry events as they approach their expiration date — daily once within the daily threshold, weekly once within the (wider) weekly threshold.

axual:
  system-management:
    scheduler:
      certificate-expiry:
        cron: "0 0 9 * * ?"   # daily at 9 AM
        daily-threshold-days: 7
        weekly-threshold-days: 30
Property Required Default Description

axual.system-management.scheduler.certificate-expiry.cron

No

0 0 9 * * ?

Cron schedule for the certificate expiry check job.

axual.system-management.scheduler.certificate-expiry.daily-threshold-days

No

7

Days before expiry within which expiry events are published daily.

axual.system-management.scheduler.certificate-expiry.weekly-threshold-days

No

30

Days before expiry within which expiry events are published weekly.

Note: this key uses the hyphenated axual.system-management prefix, which is distinct from the axual.systemmanagement prefix used by the Kafka Connect plugin scan below.

KSML Deployment Sizes

The catalog of deployment sizes (CPU / memory presets) and streams state-store sizes that KSML applications can be deployed with. Both lists are validated at startup — the application fails to start if either is empty. Exactly one deployment size may be marked as the default; if none is marked, the first entry is used and a warning is logged.

axual:
  application-deployment:
    ksml:
      deployment-sizes:
        - name: "XS"
          cpu: "0.5"
          memory: 2Gi
        - name: "S"
          default-size: true
          cpu: "1"
          memory: 4Gi
        # ... M, L, XL
      streams-state-store:
        sizes-megabytes:
          - 256
          - 512
          - 1024
          - 2048
          - 4096
Property Required Default Description

axual.application-deployment.ksml.deployment-sizes

Yes

-

List of selectable KSML deployment sizes. Each entry has name, cpu, memory, and an optional default-size (boolean). At least one entry, at most one default-size: true.

axual.application-deployment.ksml.streams-state-store.sizes-megabytes

Yes

-

List of selectable streams state-store sizes, in megabytes. At least one positive value. Sizes ≥ 1024 render as Gi, otherwise Mi, for Kubernetes.

The catalog of deployment sizes (TaskManager CPU / memory presets) for Flink SQL applications. The list is validated at startup — the application fails to start if empty. Exactly one deployment size may be marked as the default; if none is marked, the first entry is used and a warning is logged.

axual:
  application-deployment:
    flink:
      deployment-sizes:
        - name: "XS"
          cpu: "0.5"
          memory: 2Gi
        - name: "S"
          default-size: true
          cpu: "1"
          memory: 4Gi
        - name: "M"
          cpu: "2"
          memory: 8Gi
        - name: "L"
          cpu: "3"
          memory: 12Gi
        - name: "XL"
          cpu: "4"
          memory: 16Gi
Property Required Default Description

axual.application-deployment.flink.deployment-sizes

Yes

-

List of selectable Flink deployment sizes (TaskManager sizing). Each entry has name, cpu, memory, and an optional default-size (boolean). At least one entry, at most one default-size: true.

Generated Credential Passwords

Controls how randomly-generated passwords (used for SASL/SCRAM application credentials) are produced. Each password is length characters long; each character is a random code point in the [origin, bound) range.

axual:
  credentials:
    password:
      length: 10
      origin: 1
      bound: 122
Property Required Default Description

axual.credentials.password.length

Yes

10

Number of characters in a generated password.

axual.credentials.password.origin

Yes

1

Inclusive lower bound of the random character code-point range.

axual.credentials.password.bound

Yes

122

Exclusive upper bound of the random character code-point range.

Note: these properties have no built-in fallback in code; they ship with the values above in the default application.yml. Overriding them is optional, but removing them entirely prevents startup.

Connector & KSML Deployment State Polling

The database only stores the desired deployment state; the actual state is fetched live from the provisioner / Kafka Connect REST interface on a configurable cadence (see AXPD-11147). When the fetcher detects that the actual state diverges from the desired state, it publishes a deployment-failure event (which in turn drives the throttled notification described below). These poll jobs never write the actual state back to the database.

axual:
  applicationlifecycle:
    connector:
      state:
        poll:
          cron: "0 */5 * ? * *"   # every 5 minutes
    ksml:
      state:
        poll:
          cron: "0 */5 * ? * *"   # every 5 minutes
Property Required Default Description

axual.applicationlifecycle.connector.state.poll.cron

No

0 */5 * ? * *

Cron schedule for polling the actual Connector deployment state from Kafka Connect. Falls back to the legacy scheduler.reconciliation.connect.deployments.cron key if unset (honored for one release).

axual.applicationlifecycle.ksml.state.poll.cron

No

0 */5 * ? * *

Cron schedule for polling the actual KSML deployment state. Falls back to the legacy scheduler.deployment.report.failure.ksml.cron key if unset (honored for one release).

Service Accounts

Service accounts (AXPD-11914) are non-human identities that call the Platform Manager API. Each one is a confidential client in the tenant’s own identity realm plus a Platform Manager user of type SA, created, updated, rotated and deleted through /api/service-accounts by tenant administrators. Reading them (list, get, search, and the federated-mode options) is open to any user of the tenant — a service account turns up as a group member, so a team has to be able to resolve one, and the federation values are what an engineer needs to configure the workload that authenticates as it.

Configuration

Both defaults suit a hosted deployment and need no change. An on-premises deployment may want its own identity domain, and a deployment whose tenants tune their own realms may want to hand the token lifetime back to Keycloak.

axual:
  tenantmanagement:
    serviceaccount:
      access-token-lifespan-seconds: 300   # 0 or less: let each realm decide
      identity-domain: sa.axual.io
Property Required Default Description

axual.tenantmanagement.serviceaccount.access-token-lifespan-seconds

No

300

Written as the access.token.lifespan attribute on each service-account client. Deleting a service account does not revoke tokens already issued, so this is what bounds the revocation window. Set it to 0 (or any value below it) to write no attribute at all, which makes Keycloak apply the realm’s own accessTokenLifespan — per-tenant, because a realm is a tenant. Note that the realm setting also governs the other token flows in that realm, human SSO included; Keycloak has no service-account-only lifespan. Applied when the client is created. Changing it does not touch service accounts that already exist; they keep the value they were created with, and an operator can still edit one client’s attribute in Keycloak without Platform Manager overwriting it.

axual.tenantmanagement.serviceaccount.identity-domain

No

sa.axual.io

The domain of a service account’s reserved identity, <clientId>@<domain>. It never has to resolve — nothing mails a service account — but it must pass Platform Manager’s email check, which needs a real public TLD: .internal, .local, .corp and .lan are rejected, and a value that fails the check stops the application from starting. Applies to new accounts only; existing ones keep the address they were created with, which breaks nothing because a service account is identified by its SA type, not by its domain. Collision-safety with human users rests on no customer identity provider issuing addresses under this domain.

Federated (secretless) service accounts — per-realm prerequisite

A service account can authenticate with an assertion signed by the customer’s identity provider instead of a client secret. This needs realm configuration that Platform Manager does not create, and which is therefore an operator task, once per realm:

  1. An enabled identity provider with supportsClientAssertions set, configured with the external provider’s issuer, jwksUrl, validateSignature, and the clientId that assertions must carry as their aud (via allowClientIdAsAudience). Exactly one such provider must be enabled: with none, federation is reported as unavailable; with more than one, Platform Manager refuses to guess and logs a warning naming the competing aliases.

    Note this is not the separate jwtAuthorizationGrantEnabled flag, nor the jwt-authorization-grant provider type — Keycloak models those as a different feature, and a provider of that type can never authenticate a federated client.

    For Entra the provider also needs supportsClientAssertionReuse (Entra tokens carry uti, not jti, so reuse checks reject them otherwise) and a raised fedClientAssertionMaxExp (Azure caches managed-identity tokens for hours, which the default past-age check rejects).

  2. The federated-jwt execution in the realm’s bound Client Authentication flow. Realms created on Keycloak 26.6 or later already have it. Realms upgraded from an older version do not — Keycloak does not retrofit built-in flows on upgrade, and the built-in flow cannot be edited in place, so an operator has to duplicate the clients flow, add “Signed JWT - Federated” as Alternative, and bind the copy as the Client Authentication flow. The execution is also gated on the client-auth-federated feature flag, so the server must be started with it enabled.

Both are checked before anything is created, and creation fails with an error naming the missing prerequisite. If the execution is missing and the check is bypassed, the failure surfaces at token time as a misleading client_not_found. GET /api/service-accounts/federation-options reports the realm’s status, so the condition is visible without attempting a creation.

The whole exchange is covered end to end by ServiceAccountFederationKeycloakIT, which uses a second Keycloak realm as the external provider — so the setup above is executable documentation rather than prose.

Flink SQL application deployments (AXPD-11711) are provisioned on the Ververica platform. The Ververica engine version applied to SQL-script deployments is configurable, so a new engine can be rolled out without a code change. The base URL and API token are resolved per Flink cluster (from cluster config + Vault) and are not set here.

Deployments are created, read, updated and deleted through Ververica’s v1 (Kubernetes-style) deployment API, because that is the only one that models pod customization: spec.template.spec.kubernetes.pods. The update runs on v1 for the same reason as the create: a v2 update carries no kubernetes block, so it would drop the pod options off an existing deployment - and every start, resume and SQL save updates the deployment first. Because the v1 PUT replaces the whole resource, an update reads the deployment back first and overwrites only what Platform Manager owns (the SQL, the versions, the pod options and, when starting, the resources), so a change to pods reaches deployments that already exist. Only the job endpoints (start, stop, latest job) are on the v2 API, which has no v1 equivalent. The pod options are configured as a block of YAML rather than as nested properties, since they are Kubernetes API objects whose camel-case keys (nodeAffinity) must reach the platform unchanged. Either pods or the pod templates can be used, not both, and Ververica validates the object lazily at Flink cluster creation time - so a wrong affinity shows up as a deployment that does not schedule, not as a rejected request.

When a Flink SQL deployment is started (AXPD-11713), the resources of its job are pushed to Ververica. TaskManager CPU and memory come from the deployment’s own selected size (see Flink Deployment Sizes), because that is the application owner’s choice; the parallelism and the JobManager sizing are properties of how this platform runs Flink and are therefore configured here, once, for every Flink SQL job.

A Flink SQL deployment’s JobManager log can also be followed live (AXPD-11820). Ververica serves the log as a finite document with a byte offset rather than as a stream, so an open Server-Sent Events stream polls it: the first poll sends the tail of the log, and each one after that transfers only what has been written since. The interval is configurable because it trades how live the viewer feels against how many requests each open viewer costs.

axual:
  applicationlifecycle:
    flink:
      engine-version: "vera-4.5-jdk11-flink-1.20"
      flink-version: "1.20"
      parallelism: 1
      jobmanager:
        cpu: 1
        memory: 1Gi
      kubernetes:
        pods: |
          affinity:
            nodeAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                  - matchExpressions:
                      - key: axual.io/flink
                        operator: In
                        values: ["true"]
      logs:
        poll-interval: 5s
Property Required Default Description

axual.applicationlifecycle.flink.engine-version

No

vera-4.5-jdk11-flink-1.20

Ververica engine version applied to Flink SQL-script deployments.

axual.applicationlifecycle.flink.parallelism

No

1

Parallelism a started Flink SQL job runs with.

axual.applicationlifecycle.flink.jobmanager.cpu

No

1

JobManager CPU cores. Ververica requires a number of at least 0.1; fractions are allowed.

axual.applicationlifecycle.flink.jobmanager.memory

No

1Gi

JobManager memory, with a Kubernetes unit suffix (for example 1Gi).

axual.applicationlifecycle.flink.flink-version

No

1.20

Flink version of the engine image, sent as the v1 SQL artifact’s flinkVersion on creation.

axual.applicationlifecycle.flink.kubernetes.pods

No

(unset)

Kubernetes pod options (affinity, nodeSelector, tolerations, labels, …) applied to a Flink SQL deployment’s JobManager and TaskManager pods when it is created, as a YAML block passed through verbatim to spec.template.spec.kubernetes.pods. Unset sends no kubernetes block at all. Invalid YAML fails startup.

axual.applicationlifecycle.flink.logs.poll-interval

No

5s

How often an open SSE log stream asks Ververica for newly written JobManager log lines.

Deployment-Failure Notification Throttling

When a Connector or KSML deployment failure is detected during polling, a notification is sent to the application owners. To avoid alert storms, consecutive failure notifications for the same deployment are throttled: at most one notification per deployment within the configured interval.

axual:
  notification:
    connector:
      max-frequency-minutes: 60
    ksml:
      max-frequency-minutes: 60
Property Required Default Description

axual.notification.connector.max-frequency-minutes

No

60

Minimum interval, in minutes, between consecutive Connector deployment-failure notifications for the same deployment.

axual.notification.ksml.max-frequency-minutes

No

60

Minimum interval, in minutes, between consecutive KSML deployment-failure notifications for the same deployment. Falls back to the legacy scheduler.deployment.report.failure.ksml.max-frequency-minutes key if unset (honored for one release).

Kafka Connect Plugin Scan

Platform Manager periodically scans the managed Kafka Connect instances to refresh the catalog of available connector plugins. The scan cadence is configurable.

axual:
  systemmanagement:
    connect:
      plugins-scan:
        cron: "0 * */12 ? * *"  # every 12 hours
Property Required Default Description

axual.systemmanagement.connect.plugins-scan.cron

No

0 * */12 ? * *

Cron schedule for scanning managed Connect instances for available connector plugins. Falls back to the legacy scheduler.reconciliation.connect.plugins.cron key if unset (honored for one release).

Kafka Connect Cluster Plugin Discovery

For registered Kafka Connect clusters (not the legacy Axual Connect above), Platform Manager discovers the connector plugins installed on each cluster and stores them in a local catalog. A background job refreshes the catalog on a schedule, and each cluster is queried over its REST API with a per-cluster timeout. The same timeout is also used when validating a cluster during registration.

axual:
  systemmanagement:
    kafka-connect:
      plugins-scan:
        cron: "0 0 4 * * ?"   # daily at 4 AM
      rest:
        timeout-ms: 10000     # per-cluster Connect REST API timeout (connect + response)
Property Required Default Description

axual.systemmanagement.kafka-connect.plugins-scan.cron

No

0 0 4 * * ?

Cron schedule for the background job that discovers connector plugins from every registered Kafka Connect cluster. Runs on a single node.

axual.systemmanagement.kafka-connect.rest.timeout-ms

No

10000

Timeout in milliseconds for connecting to and reading from a Kafka Connect cluster’s REST API. Used by both plugin discovery and cluster validation.

Kafka Connect Log Viewer Credentials

A Kafka Connect cluster can name a runtime provisioner in its logViewerUrl. Platform Manager calls that address to read the worker logs of a connector deployment, as a JSON batch or as a live stream. If the provisioner requires basic authentication, set the credentials below.

These are separate from ksml-provisioner.username and ksml-provisioner.password on purpose. The log viewer address is stored per Connect cluster and the KSML address per instance, so the two may be different deployments with different credentials.

axual:
  application-deployment:
    connect:
      log-viewer:
        username: ""
        password: ""
Property Required Default Description

axual.application-deployment.connect.log-viewer.username

No

-

Basic authentication user for the runtime provisioner that serves Kafka Connect worker logs. Leave empty to send no authentication header.

axual.application-deployment.connect.log-viewer.password

No

-

Password that goes with the user above. Both must be set before a header is sent.

JVM memory

The image sizes the heap at 80% of the container memory limit (-XX:MaxRAMPercentage=80). That suits a deployment with a few GB: the JVM’s non-heap footprint — metaspace, code cache, thread stacks, direct buffers — is broadly fixed rather than proportional, so the heap ceiling plus non-heap still fits.

It does not suit small limits. Below roughly 1.5Gi the same 80% leaves less than the fixed non-heap needs, so the JVM may commit more than the container can hold and the kernel OOMKills it — with no OutOfMemoryError in the log, because the heap itself never exhausts.

Lower the ceiling on such deployments through the chart’s env, which is appended after the image defaults so later -XX flags win:

env:
  - name: JAVA_OPTS
    value: "-XX:MaxRAMPercentage=55 -XX:+UseG1GC -XX:G1PeriodicGCInterval=300000"

MaxRAMPercentage

Pick it so heap + non-heap fits: pct <= (1 - non-heap/limit), minus headroom. Measure non-heap on a running pod as cgroup memory.current minus heap committed.

+UseG1GC

Worth pinning below 1792MiB of container memory, where the JVM otherwise selects SerialGC — which never returns freed memory to the OS, so usage only ratchets upward.

G1PeriodicGCInterval

Lets G1 uncommit while idle; without it G1 only uncommits at Remark and Full GC.

env is a list, so keep any other entries the deployment needs in the same block — a later values layer that sets env replaces it wholesale rather than merging.

Docker environment variables

In this table, you can find a description of each environment variable that should be configured for deploying the application.

Name Possible Values Required Description

SPRING_DATASOURCE_URL

A string of jdbc url “no default”

YES

Specifies the JDBC URL used to connect to any database.

SPRING_DATASOURCE_NAME

A string defining the datasource name default value: governancedb

NO

This is typically used when you have multiple data sources in your application. It provides a name or identifier for the datasource.

SPRING_DATASOURCE_DRIVER-CLASS-NAME

A string defining the datasource driverClassName com.mysql.cj.jdbc.Driver | org.mariadb.jdbc.Driver “no default”

YES

Specifies the fully-qualified class name of the JDBC driver that should be used for the database connection.

SPRING_DATASOURCE_USERNAME

A string defining the username “no default”

YES

This sets the username used to authenticate with the database.

SPRING_DATASOURCE_PASSWORD

A string defining the password “no default”

YES

This sets the password for the database connection.

SPRING_JPA_HIBERNATE_DATABASE-PLATFORM

org.hibernate.dialect.MariaDBDialect | org.hibernate.dialect.MySQLDialect “no default”

YES

This is used to specify the SQL dialect that should be used by JPA and Hibernate when generating or interpreting SQL statements for a specific database.

SPRING_JPA_HIBERNATE_DDL-AUTO

none | validate | update | create | create-drop Default value: validate

NO

controls the behavior of database schema generation and modification during application startup. none: This is the default value. It means that no schema generation or modification is done by Hibernate. You are responsible for managing the database schema manually. validate: Hibernate validates the existing schema against the current entity mappings. It will not make any changes to the schema, but it will report any discrepancies or errors. update: Hibernate updates the schema automatically based on the entity mappings. It will create tables, columns, and constraints if they don’t exist in the database. However, it will not drop any tables or columns that are no longer needed. create: Hibernate creates the schema from scratch during application startup. It will drop and re-create the tables every time the application starts. Be cautious with this option as it can result in data loss in a production environment. create-drop: Similar to create, but it also drops the schema when the application shuts down. This is typically used for testing and development environments.

SPRING_FLYWAY_VENDOR

mysql/mariadb Default value: mariadb

NO

This is used to specify the database vendor for which Flyway should generate or apply database migration scripts.

SPRING_MODULITH_EVENTS_COMPLETION-MODE

UPDATE | DELETE | ARCHIVE Spring default: UPDATE Configured value: DELETE

NO

Controls how completed event publications from the Spring Modulith event publication system are handled. UPDATE (Spring default) keeps completed publications in the registry and requires manual purging. DELETE removes completed publications immediately after processing to prevent database bloat. ARCHIVE moves completed publications to an archive table while removing them from the main registry for auditability. Platform Manager is configured to use DELETE for operational simplicity.

SPRING_MAIL_HOST

A string defining SMTP server “no default”

Conditionally YES

Specifies the SMTP server that will be used to send emails. Possible values include domain names or IP addresses of SMTP servers, e.g., smtp.gmail.com. It is mandatory if AXUAL_NOTIFICATIONS_SMTP_ENABLED=true

SPRING_MAIL_PORT

A valid port number “no default” Possible value to be set for SMTP using TLS/STARTTLS is 587, using SSL is 465.

Conditionally YES

Specifies the port number of the SMTP server, is mandatory if AXUAL_NOTIFICATIONS_SMTP_ENABLED=true.

SPRING_MAIL_USERNAME

A string defining the username “no default”

Conditionally YES

Specifies the username used to authenticate with the SMTP server. It corresponds to the email account from which emails will be sent, is mandatory if AXUAL_NOTIFICATIONS_SMTP_ENABLED=true

SPRING_MAIL_PASSWORD

A string defining the password “no default”

Conditionally YES

Specifies the password used to authenticate with the SMTP server. It should be the password associated with the provided username, is mandatory if AXUAL_NOTIFICATIONS_SMTP_ENABLED=true

SPRING_MAIL_PROPERTIES_MAIL_SMTP_AUTH

A boolean value [true | false] Default value: false

Conditionally YES

Specifies whether authentication (user identification) is required by the SMTP server, it is mandatory to be set as true if AXUAL_NOTIFICATIONS_SMTP_ENABLED=true

SPRING_MAIL_PROPERTIES_MAIL_SMTP_STARTTLS_ENABLE

A boolean value [true | false] Default value: false

Conditionally YES

Specifies whether to enable the use of the STARTTLS command (which initiates a secure connection) when connecting to the SMTP server, it is mandatory to be set as true if AXUAL_NOTIFICATIONS_SMTP_ENABLED=true

SPRING_MAIL_PROPERTIES_MAIL_SMTP_LOCALHOST

A string representing the HELO/EHLO domain name. “no default” if it’s not set, the system’s hostname (e.g., Internal Kubernetes pod name) will be appear in the header

Conditionally YES

Specifies the domain name sent in the SMTP HELO/EHLO command. Setting this prevents the default pod hostname from appearing in email headers, such as “Received”. It helps mask internal infrastructure details when sending emails from a Kubernetes pod. it is mandatory to be set if AXUAL_NOTIFICATIONS_SMTP_ENABLED=true

VAULT_ENABLED

A boolean value [true | false] “no default”

YES

Controls supporting Vault for persisting application credentials.

VAULT_URI

A valid uri “no default”

Conditionally YES

Specifies the uri of the Vault. It is mandatory only if VAULT_ENABLED=true

VAULT_ROLE-ID

A valid RoleId “no default”

Conditionally YES

Role ID is used to identify the specific AppRole configured in Vault that the application is using for authentication. It is mandatory only if VAULT_ENABLED=true

VAULT_SECRET-ID

A valid secretId “no default”

Conditionally YES

The Secret ID is a secret token associated with a particular Role ID that proves the application’s identity and authorization to access secrets. It is mandatory only if VAULT_ENABLED=true

SERVER_HTTP2_ENABLED

A boolean value [true | false] Default value: false

NO

Is used in the configuration of a web server to enable or disable HTTP/2 support.

SERVER_SSL_ENABLED

A boolean value [true | false] Default value: true

NO

Enables SSL/TLS support for secure communication.

SERVER_SSL_KEY_STORE

A string of file path to the key-store “no default”

Conditionally YES

Specifies the file path to the Java KeyStore (JKS) file that contains the server’s SSL certificate and private key, is mandatory only if SERVER_SSL_ENABLED=true.

SERVER_SSL_KEY_STORE_PASSWORD

A string defining the password “no default”

Conditionally YES

Specifies the password required to access the keystore itself, is mandatory only if SERVER_SSL_ENABLED=true.

SERVER_SSL_ENABLED-PROTOCOLS

A comma separated list of these values [TLSv1.0, TLSv1.1, TLSv1.2, TLSv1.3] “no default”

Conditionally YES

Specifies the list of allowed SSL/TLS protocols, is mandatory only if SERVER_SSL_ENABLED=true.

AXUAL_API_AVAILABLE_AUTH_METHODS

A comma seperated list of String containing these items : SSL,SCRAM_SHA_256,SCRAM_SHA_512,PLAIN Default value: SSL

NO

Specifies the available authentication methods which can be used for applications to be authenticated while getting access to topics.

AXUAL_MULTI_TENANT

A boolean value [true | false] Default value: true

NO

Specifies if the cluster is multi-tenant or not. In case it is set to true, the cluster will be shared among multiple tenants.

AXUAL_DEFAULT_ROLES

A comma seperated List of strings containing default user roles. The list of existing roles in Axual is as follows: SUPER_ADMIN, TENANT_ADMIN, APPLICATION_ADMIN, STREAM_ADMIN, ENVIRONMENT_ADMIN, APPLICATION_AUTHOR, STREAM_AUTHOR, ENVIRONMENT_AUTHOR, BILLING_INTERNAL, BILLING_VIEWE, SCHEMA_AUTHOR, SCHEMA_ADMIN Default value: APPLICATION_AUTHOR, ENVIRONMENT_AUTHOR, STREAM_AUTHOR

NO

Specifies the default roles which can be automatically granted to a user when a new user is created.

AXUAL_DEFAULT_PARTITIONS

A valid number Default value: 2

NO

Specifies the number of partitions per each topic. Must be at least 1 and at most 120000.

AXUAL_DEFAULT_REPLICATION_FACTOR

A valid number “no default”

YES

Specifies how many copies (replicas) of each partition of a Kafka topic should be maintained across different broker nodes. It’s a crucial factor for ensuring fault tolerance and high availability in Kafka clusters.

AXUAL_DEFAULT_SEGMENT_TIME

A valid number (time in milliseconds) Default value: 604800000 (7 days)

NO

Controls the period of time after which Kafka will force the log to roll even if the segment file isn’t full to ensure that retention can delete or compact old data.

AXUAL_DEFAULT_RETENTION_TIME

A valid number (time in milliseconds) Default value: 604800000 (7 days)

NO

Controls the maximum time Kafka will retain a log before discarding old log segments to free up space if the retention policy is equal to “delete”. This represents an SLA on how soon consumers must read their data. If set to -1, no time limit is applied.

AXUAL_DEFAULT_CLEANUP_POLICY

delete | compact | delete,compact | compact,delete Default value: delete

NO

Specifies the cleanup policy for log segments in a topic. This property determines when log segments can be deleted to reclaim disk space. delete: This is the default cleanup policy. When this policy is applied, Kafka will delete log segments as soon as they are no longer needed for any active consumers or replication. compact: This policy is used for log compaction. With this policy, Kafka retains the latest value for each unique key in the log and deletes older versions of the same key. Log compaction is often used for Kafka topics that store changelog or event sourcing data, ensuring that the latest state of each key is always available.delete,compact: This policy combines both deletion and compaction. It deletes log segments that are no longer needed by any active consumers while also performing log compaction on the remaining data.compact,delete: Similar to the previous option, this policy combines both deletion and compaction, but it prioritizes log compaction before deletion.

AXUAL_DEFAULT_ENVIRONMENT_COLOR

A string defining a hexadecimal color code Default value: “#80affe”

NO

Specifies the default color of environment in UI.

AXUAL_DEFAULT_SKIP-ONBOARDING

A boolean value [true | false] Default value: true

NO

Controls whether the onboarding flow is skipped for newly created users.

AXUAL_BILLING_ENABLED

A boolean value [true | false] Default value: false

NO

This is used to enable billing component.

AXUAL_CSRF_ENABLED

A boolean value [true | false] Default value: false

NO

This is used for enabling Cross-Site Request Forgery (CSRF) protection.

AXUAL_ALLOW_OVERLAPPING_CA

A boolean value [true | false] Default value: false

NO

Allows Using one CERTIFICATE AUTHORITY (CA) on multiple tenants if it’s set to true.

AXUAL_VALIDATE_DUPLICATE_SCHEMAS

A boolean value [true | false] Default value: true

NO

Controls validation of a duplicate schema. If it’s set to false, the /schemas/check-parse API won’t check the uniqueness of the uploaded schema-version.

AXUAL_CREATE_STREAM_DISABLE_TIME

A valid number [0, …] Default value: 0

NO

Controls Disabling the StreamConfig resource creation for the specified time in minutes.

AXUAL_CLIENT_SOCKET_TIMEOUT

A valid number Default value: 90000

NO

Specifies the maximum amount of time in milliseconds that a client will wait for a response from a server before considering the operation as timed out or failed

AXUAL_ORGANIZATION_MANAGER_AUTH_PROVIDER

Supported auth provider: none, keycloak Default value: none

NO

Determines the authorization server for authenticating local users. ‘none’ disabled Organization Manager module.

AXUAL_ORGANIZATION_MANAGER_KEYCLOAK_URL

URL to access Keycloak “no default”:

YES

URL to access Keycloak.

AXUAL_ORGANIZATION_MANAGER_KEYCLOAK_USERNAME

Username to authenticate with Keycloak “no default”:

YES

Username to authenticate with Keycloak.

AXUAL_ORGANIZATION_MANAGER_KEYCLOAK_PASSWORD

Password to authenticate with Keycloak “no default”:

YES

Password to authenticate with Keycloak.

AXUAL_ORGANIZATION_MANAGER_KEYCLOAK_LOCAL_REALM

Name of local realm in Keycloak Default value: local

YES

Name of local realm in Keycloak.

AXUAL_ORGANIZATION_MANAGER_KEYCLOAK_MASTER_REALM

Name of master realm in Keycloak Default value: master

YES

Name of master realm in Keycloak.

AXUAL_ORGANIZATION_MANAGER_KEYCLOAK_CLIENT_ID

Client ID to use when authenticating with master realm of Keycloak Default value: admin-cli

YES

Admin client to authenticate with Keycloak.

AXUAL_ORGANIZATION_MANAGER_KEYCLOAK_CONNECT-TIMEOUT-SECONDS

A valid number (seconds) Default value: 5

NO

Connection timeout, in seconds, for the Keycloak admin client. Applies only when AXUAL_ORGANIZATION_MANAGER_AUTH_PROVIDER=keycloak.

AXUAL_ORGANIZATION_MANAGER_KEYCLOAK_READ-TIMEOUT-SECONDS

A valid number (seconds) Default value: 5

NO

Read timeout, in seconds, for the Keycloak admin client. Applies only when AXUAL_ORGANIZATION_MANAGER_AUTH_PROVIDER=keycloak.

AXUAL_SECURITY_DOCS-USERNAME

A string defining the username Default value: axual

NO

This sets the username used to authenticate with the docs.

AXUAL_SECURITY_DOCS-PASSWORD

A string defining the password Default value: notsecret

NO

This sets the password used to authenticate with the docs.

AXUAL_SECURITY_TRUST_STORE

A string of file path to the trust-store “no default”

YES

Specifies the file path to the trust store.

AXUAL_SECURITY_TRUST_STORE_PASSWORD

A string defining the password “no default”

YES

Specifies the password required to access and manipulate the trust store.

AXUAL_SECURITY_KEY_STORE

A string of file path to the key-store “no default”

YES

Specifies the file path to the key store.

AXUAL_SECURITY_KEY_STORE_PASSWORD

A string defining the key-strore password “no default”

YES

Specifies the password required to access and manipulate the key store.

AXUAL_SECURITY_KEY_PASSWORD

A string defining the key password “no default”

YES

Specifies the password required to unlock the private key within the key store.

AXUAL_KEYCLOAK_USERNAME

A string defining the username Default value: admin

YES

The administrative username that would be used to log in to the Keycloak administration console or authenticate API requests.

AXUAL_KEYCLOAK_PASSWORD

A string defining the password Default value: admin123

YES

The administrative password that would be used to log in to the Keycloak administration console or authenticate API requests.

AXUAL_CONNECT_AVAILABLE

A boolean value [true | false] Default value: false

Conditionally YES

Controls the direct connection to Axual-Connect.

AXUAL_CONNECT_INSTANCE-CONNECT-CREDENTIALS_[tenantShortName-instanceShortName]_AUTHORIZER

basic Default value: basic

Conditionally YES

Specifies the type of authorization per tenant-instance, is mandatory if AXUAL_CONNECT_AVAILABLE=true

AXUAL_CONNECT_INSTANCE-CONNECT-CREDENTIALS_[tenantShortName-instanceShortName]_USERNAME

A string defining the username “no default”

Conditionally YES

This sets the username per tenant-instance used to authenticate with the Axual-Connect, is mandatory if AXUAL_CONNECT_AVAILABLE=true.

AXUAL_CONNECT_INSTANCE-CONNECT-CREDENTIALS_[tenantShortName-instanceShortName]_PASSWORD

A string defining the password “no default”

Conditionally YES

This sets the password per tenant-instance used to authenticate with the Axual-Connect, is mandatory if AXUAL_CONNECT_AVAILABLE=true.

AXUAL_DEFAULT-CLUSTER-PATTERN_TOPIC-RESOLVER

A string of fully-qualified class name of topicResolver Default value: “io.axual.common.resolver.TopicPatternResolver”

NO

Specifies the fully-qualified class name of topicResolver which is used for resolving topics.

AXUAL_DEFAULT-CLUSTER-PATTERN_TOPIC-PATTERN

A string of topic pattern [“{topic}” | “{environment}-{topic}” | {instance}-{environment}-{topic} | {tenant}-{instance}-{environment}-{topic} ] Default value: “{topic}”

NO

Specifies the topic pattern for any kafka cluster owned by a Tenant and not having a defined topic pattern. This pattern is used when resolving the kafka topic name. “{topic}” this pattern means that this cluster does not support multi-environment, multi_instance and multi-tenant “{environment}-{topic}” this pattern means that the cluster is a multi-environment one and combination of environment-topic identifies a unique topic {instance}-{environment}-{topic} this pattern means that the cluster is a multi-environment and multi-instance one and combination of instance-environment-topic identifies a unique topic “{tenant}-{instance}-{environment}-{topic}” this pattern means that the cluster is a multi-environment, multi-instance and multi_tenant and combination of tenant-instance-environment-topic identifies a unique topic.

AXUAL_DEFAULT-CLUSTER-PATTERN_GROUP-ID-RESOLVER

A string of fully-qualified class name of groupIdResolver Default value: “io.axual.common.resolver.GroupPatternResolver”

NO

Specifies the fully-qualified class name of groupIdResolver which is used for resolving groups.

AXUAL_DEFAULT-CLUSTER-PATTERN_GROUP-ID-PATTERN

A string of groupId pattern [“{group}” | “{environment}-{group}” | {instance}-{environment}-{group} | {tenant}-{instance}-{environment}-{group} ] Default value: “{group}”

NO

Specifies the groupId pattern for any kafka cluster owned by a Tenant and not having a defined groupId pattern. This pattern is used when resolving the group name. “{group}” this pattern means that this cluster does not support multi-environment, multi_instance and multi-tenant “{environment}-{group}” this pattern means that the cluster is a multi-environment one and combination of environment-group identifies a unique group {instance}-{environment}-{group} this pattern means that the cluster is a multi-environment and multi-instance one and combination of instance-environment-group identifies a unique group. “{tenant}-{instance}-{environment}-{group}” this pattern means that the cluster is a multi-environment, multi-instance and multi_tenant and combination of tenant-instance-environment-group identifies a unique group.

AXUAL_DEFAULT-CLUSTER-PATTERN_TRANSACTIONAL-ID-RESOLVER

A string of fully-qualified class name of transactionalIdResolver Default value: “io.axual.common.resolver.TransactionalIdPatternResolver”

NO

Specifies the fully-qualified class name of transactionalIdResolver which is used for resolving transactions.

AXUAL_DEFAULT-CLUSTER-PATTERN_TRANSACTIONAL-ID-PATTERN

A string of transactionalId pattern [“{transactional.id}” | “{environment}-{app.id}” | {instance}-{environment}-{transactional.id} | {tenant}-{instance}-{environment}-{transactional.id} ] Default value: “{transactional.id}”

NO

Specifies the transactionalId pattern for any kafka cluster owned by a Tenant and not having a defined transactionalId pattern. This pattern is used when resolving the transactionalId. “{transactional.id}” this pattern means that the cluster does not support multi-environment, multi_instance and multi-tenant “{environment}-{transactional.id}” this pattern means that the cluster is multi-environment and combination of environment-transactionalId- identifies a unique prefixed transactional.id {instance}-{environment}-{transactional.id} this pattern means that the cluster is multi-environment and multi-instance and combination of instance-environment-transactionalId identifies a unique prefixed transactional.id “{tenant}-{instance}-{environment}-{topic}” this pattern means that the cluster is multi-environment, multi-instance and multi-tenant and combination of tenant-instance-environment-transactionalId- identifies a unique prefixed transactional.id.

AXUAL_DEFAULT-CLUSTER-PATTERN_MULTI-TENANT-TOPIC-PATTERN

A string of multi-tenant topic pattern Default value: “{tenant}-{instance}-{environment}-{topic}”

NO

Specifies the topic pattern for any kafka cluster not owned by a Tenant and not having a defined topic pattern. This pattern is used when resolving the kafka topic name. “{tenant}-{instance}-{environment}-{topic}” this pattern means that the cluster is a multi-environment, multi-instance and multi_tenant and combination of tenant-instance-environment-topic identifies a unique topic.

AXUAL_DEFAULT-CLUSTER-PATTERN_MULTI-TENANT-GROUP-ID-PATTERN

A string of multi-tenant groupId pattern Default value: “{tenant}-{instance}-{environment}-{group}”

NO

Specifies the groupId pattern for any kafka cluster not owned by a Tenant and not having a defined groupId pattern. This pattern is used when resolving the kafka group name. “{tenant}-{instance}-{environment}-{group}” this pattern means that the cluster is a multi-environment, multi-instance and multi_tenant and combination of tenant-instance-environment-group identifies a unique group.

AXUAL_DEFAULT-CLUSTER-PATTERN_MULTI-TENANT-TRANSACTIONAL-ID-PATTERN

A string of multi-tenant transactionalId pattern Default value: “{tenant}-{instance}-{environment}-{transactional.id}”

NO

Specifies the transactionalId pattern for any kafka cluster not owned by a Tenant and not having a defined transactionalId pattern. This pattern is used when resolving the transactionalId. “{tenant}-{instance}-{environment}-{transactional.id}” this pattern means that the cluster is multi-environment, multi-instance and multi-tenant and combination of tenant-instance-environment-transactionalId- identifies a unique prefixed transactional.id.

AXUAL_NOTIFICATIONS_ENABLED

A boolean value [true | false] Default value: false

NO

Enables Notification service for the application.

AXUAL_NOTIFICATIONS_SENDER

A valid email address “no default”

Conditionally YES

Represents the email address of the notification sender, it can be the same value as SPRING_MAIL_USERNAME property, it is mandatory if AXUAL_NOTIFICATIONS_ENABLED=true

AXUAL_NOTIFICATIONS_SMTP_ENABLED

A boolean value [true | false] no default:

Conditionally YES

Enables Notification service to use SMTP for on-prem installation. It is mandatory if AXUAL_NOTIFICATIONS_ENABLED=true

GOVERNANCE_VAULT_ENABLED

A boolean value [true | false] Default value: false

Conditionally YES

Controls supporting Hashicorp Key Vault for governance to persist application credentials.

GOVERNANCE_VAULT_URI

A valid uri “no default”

Conditionally YES

Specifies the URI or endpoint of the Hashicorp Key Vault instance. It is mandatory only if GOVERNANCE_VAULT_ENABLED=true.

GOVERNANCE_VAULT_ROLE-ID

A valid RoleId “no default”

Conditionally YES

Role ID is used to identify the specific AppRole configured in Hashicorp Vault that the application is using for authentication. It is mandatory only if GOVERNANCE_VAULT_ENABLED=true

GOVERNANCE_VAULT_SECRET-ID

A valid secretId “no default”

Conditionally YES

The Secret ID is a secret token associated with a particular Role ID that proves the application’s identity and authorization to access secrets. It is mandatory only if GOVERNANCE_VAULT_ENABLED=true

GOVERNANCE_VAULT_PATH

A string defining path Default value: “governance”

Conditionally YES

Defines the specific path within Vault’s storage hierarchy where the application expects to read or write secrets or other data. It is mandatory only if GOVERNANCE_VAULT_ENABLED=true

GOVERNANCE_VAULT_NAMESPACE

A string defining the namespace “no default”

Conditionally YES

Specifies the Vault namespace to use. A Vault namespace allows you to create isolated environments within a Vault server, is mandatory if GOVERNANCE_VAULT_ENABLED=true

SCHEDULER_RECONCILIATION_CONNECT_PLUGINS_CRON

A string defining a cron expression Default value: “0 * /12 ? *” (evey 12 hours)

NO

Deprecated — use AXUAL_SYSTEMMANAGEMENT_CONNECT_PLUGINS-SCAN_CRON (see “Kafka Connect Plugin Scan”). Still honored as a fallback for one release. Specifies the schedule or frequency at which reconciling plugins of managed instances task should be executed.

SCHEDULER_RECONCILIATION_CONNECT_DEPLOYMENTS_CRON

A string defining a cron expression Default value: “0 /5 ? * *” (evey 5 minutes)

NO

Deprecated — use AXUAL_APPLICATIONLIFECYCLE_CONNECTOR_STATE_POLL_CRON (see “Connector & KSML Deployment State Polling”). Still honored as a fallback for one release. Specifies the schedule or frequency at which reconciling deployments of managed instances task should be executed.

CONNECTOR-VAULT_ENABLED

A boolean value [true | false] Default value: false

Conditionally YES

Controls supporting Vault for persisting connectors secrets per tenant-instance.

CONNECTOR-VAULT_INSTANCES_[tenantShortName-instanceShortName]_URI

The URI of the vault “no default”

Conditionally YES

Specifies the type of authorization per tenant-instance, is mandatory if CONNECTOR-VAULT_ENABLED=true

CONNECTOR-VAULT_INSTANCES_[tenantShortName-instanceShortName]_ROLE-ID

A valid RoleId “no default”

Conditionally YES

Role ID is used to identify the specific AppRole per tenant-instance configured in Hashicorp Vault that the application is using for authentication, is mandatory if CONNECTOR-VAULT_ENABLED=true

CONNECTOR-VAULT_INSTANCES_[tenantShortName-instanceShortName]_SECRET-ID

A valid secretId “no default”

Conditionally YES

The Secret ID is a secret token associated with a particular Role ID per tenant-instance that proves the application’s identity and authorization to access secrets, is mandatory if CONNECTOR-VAULT_ENABLED=true

CONNECTOR-VAULT_INSTANCES_[tenantShortName-instanceShortName]_NAMESPACE

A string defining the namespace “no default”

Conditionally YES

Specifies the Vault namespace per tenant-instance to use. A Vault namespace allows you to create isolated environments within a Vault server, is mandatory if CONNECTOR-VAULT_ENABLED=true

CONNECTOR-VAULT_INSTANCES_[tenantShortName-instanceShortName]_CONNECTORS-PATH

A string defining path “no default”

Conditionally YES

Specifies a path within Vault per tenant-instance where connectors or secrets may be stored or managed, is mandatory if CONNECTOR-VAULT_ENABLED=true

CONNECTOR-VAULT_INSTANCES_[tenantShortName-instanceShortName]_PRIVATE-KEY-NAME

A string defining the privateKey name “no default”

Conditionally YES

Specifies the name of a private key per tenant-instance within Vault, is mandatory if CONNECTOR-VAULT_ENABLED=true

CONNECTOR-VAULT_INSTANCES_[tenantShortName-instanceShortName]_CERT-CHAIN-KEY-NAME

A string defining the certChainKey name “no default”

Conditionally YES

Specifies the name of a certificate chain or certificate-related resource per tenant-instance within Vault per tenant-instance, is mandatory if CONNECTOR-VAULT_ENABLED=true

CONNECTOR-VAULT_INSTANCES_[tenantShortName-instanceShortName]_TRUST-STORE

A string of file path to the trust-store “no default”

NO

Specifies the file path to the trust store within Vault per tenant-instance, if it’s not set, the AXUAL_SECURITY_TRUST_STORE value will be set as default value.

CONNECTOR-VAULT_INSTANCES_[tenantShortName-instanceShortName]_TRUST-STORE-PASSWORD

A string defining the password “no default”

NO

Specifies the password required to access and manipulate the trust store within Vault per tenant-instance, if it’s not set, the AXUAL_SECURITY_TRUST_STORE_PASSWORD value will be set as default value.

CONNECTOR-VAULT_INSTANCES_[tenantShortName-instanceShortName]_KEY-STORE

A string of file path to the key-store “no default”

NO

Specifies the file path to the key store within Vault per tenant-instance, if it’s not set, the AXUAL_SECURITY_KEY_STORE value will be set as default value.

CONNECTOR-VAULT_INSTANCES_[tenantShortName-instanceShortName]_KEY-STORE-PASSWORD

A string defining the key-store password “no default”

NO

Specifies the password required to access and manipulate the key store within Vault per tenant-instance, if it’s not set, the AXUAL_SECURITY_KEY_STORE_PASSWORD value will be set as default value.

CONNECTOR-VAULT_INSTANCES_[tenantShortName-instanceShortName]_KEY-PASSWORD

A string defining the key password “no default”

NO

Specifies the password required to unlock the client’s private key within the key store within Vault per tenant-instance, if it’s not set, the AXUAL_SECURITY_KEY_STORE_PASSWORD value will be set as default value.

AXUAL_AUDIT_ENABLED

A boolean value [true | false] Default value: false

NO

Enables Auditing for the application.

AXUAL_APPLICATION-DEPLOYMENT_CONNECT_LOG-VIEWER_USERNAME

A string defining the username “no default”

NO

Basic authentication user for the runtime provisioner that serves Kafka Connect worker logs (the logViewerUrl of a Kafka Connect cluster). Leave it unset to send no authentication header.

AXUAL_APPLICATION-DEPLOYMENT_CONNECT_LOG-VIEWER_PASSWORD

A string defining the password “no default”

NO

Password that goes with the user above. Both must be set before Platform Manager sends a basic authentication header to the log viewer.