All Posts
KEDA 2.21: More Signals, Less Overhead, Safer Authentication
by Kedify Team
September 24, 2026
KEDA 2.21 adds new ways to scale from databases and change feeds, reduces duplicate metric queries for eligible workloads, and lets external-push scalers update their HPA targets dynamically. It also changes how service account tokens are used outside the Kubernetes API, with an important compatibility check before upgrading.
As KEDA maintainers, these are the changes we think deserve your attention and the checks to make before rolling out the release.
Breaking Change: Service Account Token Audiences
The service-account-token CVE fix addresses a privilege-escalation path: authentication configuration could cause KEDA to send a Kubernetes API-valid token to a tenant-controlled endpoint. KEDA 2.21 requires explicitly approved token audiences by default. Choose audiences the Kubernetes API does not accept, so an exposed integration token cannot be replayed against that API.
The breaking change affects Vault Kubernetes authentication and all boundServiceAccountToken (BSAT) authentication. Using Prometheus, Loki, metrics-api, or Datadog alone does not require migration; using a BSAT to authenticate does. Ordinary Vault tokens and Datadog API/app keys are not affected by this audience change.
For Vault’s file-based path, the chart provides a dedicated projected token with the vault audience; existing custom mounts need explicit audience approval. Named-service-account Vault authentication and other BSAT consumers need a namespace/service-account audience mapping. Configure the receiving service to accept its intended audience, too: a chart setting cannot add receiver support.
An operator-wide legacy mode temporarily restores compatibility but opts out of this protection. It is not a per-scaler exception. Vault destination filtering remains optional hardening, separate from audience enforcement.
Follow the audience migration guide
for complete secure and legacy configurations. The security advisory provides affected versions and reporter credits.
More Ways to Scale on Actual Work
KEDA 2.21 adds ClickHouse and Google Cloud Spanner scalers, plus a native Azure Cosmos DB change-feed scaler:
| New scaler | What it measures | Where it helps |
|---|---|---|
| ClickHouse | A numeric result from a SQL query | Scale workers from a business or processing metric already available in ClickHouse. |
| Google Cloud Spanner | A SQL query returning an integer | Scale consumers from pending work held in a Spanner table without building an intermediate metrics exporter. |
| Azure Cosmos DB Change Feed | Estimated change-feed processor lag | Scale change-feed workers with a native KEDA scaler rather than a separately deployed external scaler. |
Fewer Duplicate Queries and Lookups
When a ScaledObject has a positive minReplicaCount, no idleReplicaCount, and no cached-metric triggers, KEDA can use the HPA’s fresh observations instead of independently querying the same trigger sources on every polling tick. It falls back to querying when those observations are unavailable or the configuration needs the existing path. This is a targeted reduction in duplicate requests, not a promise that every scaler will poll less. The polling change explains the conditions.
Admission validation now uses indexed lookups for conflicting workload targets and HPA names instead of full-namespace scans. Kafka also gains the optional fullMetadata setting, allowing topic-scoped triggers to avoid retaining metadata for the whole cluster. See the admission indexing change and Kafka scaler configuration.
More Adaptable External Scalers
For teams building their own integrations, 2.21 adds an optional StreamMetricSpec RPC. An external-push scaler can send updated HPA target values without requiring a ScaledObject edit. That lets a scaler update the target as its operating conditions change instead of requiring a separate process to rewrite Kubernetes configuration.
This streams metric specifications, not a replacement for the metrics-value path. Existing external scalers that do not implement it keep their current GetMetricSpec behavior. Read the external-scaler extension for the protocol details.
Scaler and Reliability Improvements
The Temporal scaler gains opt-in includeRunningWorkflowCount behavior to keep workers active when the backlog briefly reaches zero but workflows are still running. It affects activation, not the backlog metric itself, and is not a general guarantee against every scale-down. For busy workflow systems, that distinction matters. The Temporal documentation covers versioned workers, activity queues, and visibility limitations.
Other fixes improve how failure and concurrency are represented. Solr errors are no longer treated as an empty queue, GitHub Runner job caching is corrected for concurrent workflow runs, and recreating a ScaledObject after an HPA-creation failure no longer reuses stale scaler cache state. Those changes are less visible than a new scaler, but they help keep errors from becoming misleading scaling inputs. The upstream changelog and cache lifecycle fix have the details.
Authentication also gets more flexible: Azure Pipelines gains service-principal authentication through a reusable Azure provider, and MSSQL can select the azuresql driver to use the Microsoft Entra ID authentication methods that driver supports. These are new choices for those integrations, not a requirement to change every existing credential. See the Azure Pipelines and MSSQL changes.
2.21 Compatibility Changes
Two 2.21 changes may require action before upgrading:
- Service account token audiences. Vault Kubernetes authentication and BSAT consumers need the audience configuration described above. Legacy mode is available only as an operator-wide compatibility option and disables the new protection.
- Temporal and Liiklus scalers. The Temporal scaler removes
buildId,selectAllActive, andselectUnversioned; useworkerDeploymentNameandworkerDeploymentBuildIdfor the replacement versioning model. Liiklus is deprecated in 2.21, with removal planned for a later release.
The KEDA 2.21 migration guide contains the complete configuration changes.
The Ecosystem Is Growing
A Kafka Scaler for Dense Installations
Kedify 2.21 also offers a new kedify-kafka scaler for environments with many Kafka triggers. The upstream Kafka scaler creates a separate Sarama client for each trigger; kedify-kafka shares compatible clients, coordinates topic-metadata refreshes, and coalesces overlapping producer-offset requests. In an AKS benchmark with 50 ScaledObjects, three brokers, 96 partitions, and a five-second polling interval, the final implementation produced these results over a ten-minute measurement window:
| Mean metric | KEDA (kafka) | Kedify (kedify-kafka) | Reduction |
|---|---|---|---|
| Kafka connections | 206.0 | 20.7 | 89.9% |
| Metadata requests/s | 10.16 | 0.278 | 97.3% |
| Scaler-related requests/s | 50.15 | 36.62 | 27.0% |
| Operator memory | 53.15 MiB | 44.83 MiB | 15.7% |
The scaler uses the same Kafka lag semantics while reducing duplicate broker work across compatible triggers.
Tenant Boundaries for 2.21 Authentication
KEDA 2.21’s audience enforcement prevents an integration token from being replayed against the Kubernetes API when it uses a non-Kubernetes audience. It does not make credentials tenant-specific inside one shared operator: a user who is allowed to create a TriggerAuthentication or ClusterTriggerAuthentication can still try to route an approved BSAT to another endpoint, such as Vault.
In Kedify multitenant KEDA, separate operators own non-overlapping namespaces. A BSAT configured for a Prometheus scaler in one tenant is not available to another tenant’s operator, so that tenant cannot route the token through a Vault configuration. This isolation complements the 2.21 audience checks; it does not replace correct audience configuration.
Planning your KEDA 2.21 upgrade?
Talk with the KEDA maintainers at Kedify about your scaling and authentication setup.
Get StartedThanks to the KEDA community, contributors, and security reporters who helped shape this release.
