Schema Registry
Configuration
Kpow supports Confluent Schema Registry–compatible registries, including Confluent Schema Registry, Apicurio Registry, and Karapace.
It also supports provider-specific registries, such as AWS Glue Schema Registry, Google MSKA Schema Registry, Redpanda Schema Registry, and Buf Schema Registry (BSR).
This section covers general configuration options for Confluent-compatible registries. More detailed configurations can be found in the Integration section.
Kpow connects to a schema registry using environment variables.
| Variable | Description |
|---|---|
| SCHEMA_REGISTRY_NAME | UI and logs friendly name for this Schema registry |
| SCHEMA_REGISTRY_URL | The client connection URL for your registry |
| SCHEMA_REGISTRY_AUTH | USER_INFO if basic authentication is configured |
| SCHEMA_REGISTRY_USER | Username if basic authentication is configured |
| SCHEMA_REGISTRY_PASSWORD | Password if basic authentication is configured |
| SCHEMA_REGISTRY_RESOURCE_IDS | Optional, comma separated list of unique ids. Only specify when configuring multiple schema registries. |
| SCHEMA_REGISTRY_OBSERVATION_VERSION | Optional, sets the observation version used to snapshot schema resources. Default=1. See Observation Version. |
| SCHEMA_REGISTRY_STARTUP_VALIDATION | (Optional) Validate that the Schema Registry is reachable at startup. When set to false, and Kpow cannot reach the host, an error message will be displayed in the UI, and Kpow will attempt to reconnect to the specified host. Default: true |
Multiple schema registries
Kpow supports multiple Schema Registries associated to a single Kafka cluster.
To configure multiple Schema Registries, use the environment variable SCHEMA_REGISTRY_RESOURCE_IDS to define a comma separated list of Schema Registries. Kpow uses the resource
ID as a prefix in the environment variable.
Example configuration when configuring two Schema Registries:
SCHEMA_REGISTRY_RESOURCE_IDS=DEV1,QA2
DEV1_SCHEMA_REGISTRY_URL="https://dev1.schema-registry.mycorp.org"
DEV1_SCHEMA_REGISTRY_AUTH="USER_INFO"
DEV1_SCHEMA_REGISTRY_USER=""
DEV1_SCHEMA_REGISTRY_PASSWORD=""
QA2_SCHEMA_REGISTRY_URL="https://qa2.schema-registry.mycorp.org"
QA2_SCHEMA_REGISTRY_AUTH="USER_INFO"
QA2_SCHEMA_REGISTRY_USER=""
QA2_SCHEMA_REGISTRY_PASSWORD=""
In this example we have defined connections to two Schema Registry resources: DEV1 and QA2
The values for SCHEMA_REGISTRY_RESOURCE_IDS must be upper-cased like DEV1 and not dev1.
The sort order follows the sequence of resource IDs in the SCHEMA_REGISTRY_RESOURCE_IDS list.
For example, if SCHEMA_REGISTRY_RESOURCE_IDS=QA1,DEV1,DEV2, the order will be QA1, DEV1, then DEV2.
Observation version
To control how Kpow snapshots schemas, use the SCHEMA_REGISTRY_OBSERVATION_VERSION flag to set the observation version.
By default, when SCHEMA_REGISTRY_OBSERVATION_VERSION is set to 1, Kpow follows a two-step process to capture schema metadata. First, it retrieves all schema names with a single
query. Then, with the specified parallelism level, it makes two REST calls for each schema: one to fetch metadata and another to fetch compatibility.
This method provides the most context at an aggregate level, but can be resource-intensive for larger schema registries, as the number of REST calls increases proportionally to the number of schemas.
Alternatively, when SCHEMA_REGISTRY_OBSERVATION_VERSION is set to 2 (Confluent only), Kpow uses a single-step process to capture schema metadata. It makes a single REST call to
fetch all schemas, including their metadata. This approach can be much more efficient than version 1, but compatibility information is only available at the individual schema level
in Kpow's UI.
Access control
User permissions to Kafka cluster resources are defined by Schema actions. See: User Authorization.