License

Koldan requires a license document supplied through the Helm chart. Obtain it through the Koldan distribution channel for the installed release and required capabilities, and manage it as sensitive commercial configuration.

Prerequisites

Before installation or renewal, confirm the intended environment, installed Koldan version, license validity period, enabled capabilities, cluster time synchronization, renewal owner, and escalation contact. Keep the replacement and current license available through the approved secret store until the rollout is verified.

Load the license

The chart accepts the license through the top-level license value:

license: |
  <license document>

Populate this value only in a protected deployment context. Do not commit it, add it to an ordinary values repository, paste it into documentation or tickets, or include it in support output. The chart renders the document into a Kubernetes Secret, but the supplied value also remains in Helm release data. Restrict read access to both Secrets and Helm release objects.

Render or lint the chart without retaining populated output in an unsecured location, then apply the release:

helm upgrade koldan ./koldan \
  --namespace koldan \
  --values operator-values.yaml \
  --atomic \
  --timeout 15m

The chart annotates affected pod templates with a license checksum, so a Helm change to license triggers their rollout. Wait for every enabled Koldan workload to become Ready; checking only one API pod can miss a workload that rejected the document.

Verify

After loading or replacing a license:

• Confirm the Helm release completed and the expected revision is active.
• Confirm every enabled Koldan workload rolled and is Ready.
• Review startup logs for license parsing, validity, or capability errors without printing the license itself.
• Exercise a representative operation for each capability intended to be enabled.
• Confirm cluster and node clocks are synchronized.

Do not decode or print the license Secret merely to prove it exists. Verify the Secret metadata and workload health without exposing its content.

Renew or replace

1. Obtain and validate the replacement before the maintenance window.
2. Preserve the current license in the approved secret store and record the current Helm revision.
3. Supply the replacement through the same controlled path and perform an atomic Helm upgrade.
4. Verify all workloads and licensed operations.
5. Retire the prior document only after the new release is stable and according to license-handling policy.

Avoid editing the generated Kubernetes Secret directly. A direct edit is not recorded in the intended Helm state and will be overwritten by a later upgrade.

Recover from rejection

Check document integrity, release and environment compatibility, validity dates, intended capabilities, time synchronization, Helm rendering, Secret creation, and pod rollout. If the replacement is rejected, restore the prior valid document through Helm while it is still authorized for use.

helm history koldan --namespace koldan
helm rollback koldan <previous-revision> --namespace koldan --wait --timeout 15m

A rollback helps only if that revision contains a license that remains valid. If no valid document is available, keep the deployment isolated as appropriate and contact the Koldan distribution channel; repeatedly restarting pods cannot repair an invalid or expired license.