Release v2.26.0

Summary

Replicas can now share one Data Protection key ring through Azure Blob Storage or Redis instead of a mounted volume, so sessions and tokens survive restarts and load balancing on platforms without shared persistent disks.

Added

• Cratis:AuthProxy:DataProtection:Store selects where the key ring is persisted: FileSystem (the default, still driven by DataProtectionKeysPath), AzureBlob or Redis. Azure Blob Storage supports managed identity authentication through DefaultAzureCredential. Existing deployments are unaffected. (#151)
• Cratis:AuthProxy:DataProtection:KeyVault:KeyIdentifier encrypts newly generated Data Protection keys with an Azure Key Vault key before storage, in any of the three stores. Existing plaintext keys remain usable and are not retroactively encrypted; existing encrypted keys still require their original vault keys and versions. (#151)
• AuthProxy refuses to start when the key store configuration is incomplete, contradictory or names an unsupported store, including undefined numeric values, and the message names the setting. Configuring an AzureBlob or Redis section requires selecting that store explicitly rather than leaving Store at its FileSystem default. (#151)
• Documentation of the multi-replica setup for each store and how to retain an existing ring or deliberately start a fresh encrypted ring. See Data Protection keys. (#151)

Changed

• Data Protection readiness warnings point operators to the configured key store and optional Key Vault key rather than always suggesting a file-system path. (#151)