KEDA And Azure Workload Identity: Secure Prometheus Scaler Authentication

Jul 31, 2025 by Chloe Fitzgerald 74 views

Support Azure Workload Identity for Prometheus Scaler Authentication

Introduction

Hey guys! Let's dive into a crucial feature request for KEDA (Kubernetes Event-driven Autoscaling) that could significantly improve how we handle authentication with Prometheus scalers, especially when dealing with secured Prometheus-compatible endpoints like Cortex and Mimir. Currently, KEDA's Prometheus scaler supports basic authentication, TLS, and static bearer tokens. However, it lacks native support for dynamic tokens obtained via OAuth2, such as those provided by Azure Workload Identity. This limitation makes it challenging to securely and automatically scale workloads using KEDA without resorting to manual token provisioning or less secure static secrets. This article will explore the need for Azure Workload Identity support in KEDA's Prometheus scaler, its benefits, and a potential implementation strategy.

Current Limitations and the Need for Dynamic Token Support

The current Prometheus scaler in KEDA offers several authentication methods, including basic auth, TLS, and static bearer tokens. While these methods are suitable for many scenarios, they fall short when dealing with modern, secured Prometheus-compatible endpoints that require dynamic tokens. Services like Cortex, Mimir, and Prometheus often leverage OAuth2 for authentication, which necessitates the use of dynamically obtained tokens. These tokens, unlike static ones, have a limited lifespan and need to be periodically refreshed. Manually managing these tokens or relying on less secure static secrets can introduce significant operational overhead and security risks.

The absence of native support for dynamic tokens in KEDA's Prometheus scaler creates a gap in functionality. Users are forced to implement workarounds, such as manually provisioning tokens or using less secure methods, which can be cumbersome and error-prone. This not only increases the complexity of scaling workloads but also introduces potential security vulnerabilities. To address these challenges, KEDA needs a more robust and automated way to handle dynamic tokens, specifically those obtained via OAuth2.

Azure Workload Identity provides a secure and convenient way for Kubernetes pods to access Azure resources without needing to manage credentials directly. By integrating Azure Workload Identity with KEDA's Prometheus scaler, we can enable automatic and secure scaling of workloads that rely on Azure services. This integration would eliminate the need for manual token provisioning and reduce the risk of exposing sensitive credentials. The dynamic nature of the tokens obtained through Azure Workload Identity ensures that access to resources is always secured with the latest credentials, enhancing the overall security posture of the system.

Proposed Solution: Integrating Azure Workload Identity

The proposed solution involves integrating KEDA with Azure Workload Identity to dynamically fetch and inject bearer tokens at runtime. This approach leverages the existing podIdentity mechanism within KEDA, which already supports Azure Workload Identity. By extending this mechanism to the Prometheus scaler, we can provide a seamless and secure way to authenticate with Prometheus-compatible endpoints.

To achieve this, the implementation should build upon the existing workload identity framework in KEDA. This means that users can define a TriggerAuthentication resource that specifies the use of Azure Workload Identity, similar to how it's done for other scalers. The TriggerAuthentication resource would include details about the pod identity provider (in this case, azure-workload) and the user-assigned identity to be used. This approach ensures consistency with KEDA's existing authentication mechanisms and simplifies the configuration process for users.

The ideal configuration would allow users to reference the TriggerAuthentication resource in their scaled object definition. This reference would enable KEDA to automatically fetch the necessary bearer token at runtime and inject it into the Prometheus scaler. This dynamic injection of tokens eliminates the need for manual token management and ensures that the scaler always has a valid token for authentication. The configuration should be straightforward and intuitive, allowing users to easily configure Azure Workload Identity for their Prometheus scalers.

Here's an example of how the configuration might look:

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-azure-wi-auth
  namespace: foo
spec:
  podIdentity:
    provider: azure-workload
    identityId: <user-assigned-identity>

authenticationRef:
  name: keda-azure-wi-auth

metadata:
  serverAddress: https://mimir.mydomain.com/prometheus
  authModes: "bearer"

This configuration would enable KEDA to dynamically inject the bearer token into the scaler at runtime, ensuring secure and automated authentication with the Prometheus endpoint.

Benefits of Implementing Azure Workload Identity Support

Implementing Azure Workload Identity support for the Prometheus scaler in KEDA offers several significant benefits, including enhanced security, simplified management, and improved scalability. By leveraging dynamic tokens obtained through Azure Workload Identity, we can eliminate the need for static secrets and manual token provisioning, reducing the risk of security breaches and operational overhead.

Enhanced Security: The primary benefit of using Azure Workload Identity is the improved security posture. By using dynamic tokens, we eliminate the need to store and manage static secrets, which are a common target for attackers. Dynamic tokens have a limited lifespan, and they are automatically refreshed, reducing the window of opportunity for unauthorized access. This approach aligns with security best practices and helps organizations meet compliance requirements.

Simplified Management: Integrating Azure Workload Identity simplifies the management of authentication credentials. Instead of manually provisioning and rotating tokens, KEDA can automatically fetch and inject them at runtime. This reduces the operational burden on administrators and developers, allowing them to focus on other critical tasks. The automated token management also reduces the risk of human error, such as misconfigured or expired tokens.

Improved Scalability: By automating the token management process, we can improve the scalability of KEDA-based applications. The dynamic nature of Azure Workload Identity ensures that the scaler always has a valid token, regardless of the scale of the application. This is particularly important in dynamic environments where workloads are frequently scaled up and down. The automated token management ensures that authentication does not become a bottleneck in the scaling process.

Compliance and Best Practices: Using Azure Workload Identity aligns with industry best practices for securing cloud-native applications. It helps organizations meet compliance requirements by providing a secure and auditable way to manage access to resources. The use of dynamic tokens and automated token management reduces the risk of non-compliance and simplifies the audit process.

Use Cases

While the original feature request did not include a specific use case, the benefits of Azure Workload Identity integration for Prometheus scaler authentication are evident in various scenarios. Consider a microservices architecture where multiple services need to access Prometheus metrics securely. Each service can use its own Azure Workload Identity to obtain dynamic tokens, ensuring that access is properly segmented and controlled.

Monitoring and Observability: In a cloud-native environment, monitoring and observability are critical for ensuring the health and performance of applications. Prometheus is a popular choice for collecting and storing metrics, and KEDA can be used to automatically scale the resources required for monitoring based on the load. By integrating Azure Workload Identity, we can ensure that the Prometheus scaler can securely access the metrics endpoints without manual intervention.

Data Processing Pipelines: Many data processing pipelines rely on Prometheus to monitor the performance of various components. KEDA can be used to scale these pipelines based on metrics such as processing time or queue length. By using Azure Workload Identity, we can ensure that the scaling process is secure and automated, without the need for manual token management.

Event-Driven Applications: KEDA is designed for event-driven autoscaling, where applications are scaled based on events from various sources. Prometheus can be used to collect metrics about these events, and KEDA can scale applications based on these metrics. By integrating Azure Workload Identity, we can ensure that the event-driven applications can securely access Prometheus metrics and scale accordingly.

Community Involvement and Implementation Considerations

While the original feature request mentioned that the requester was not planning to implement the feature themselves, community involvement is crucial for the success of this integration. Developers and users who are interested in this feature can contribute by providing feedback, testing implementations, and submitting pull requests.

Implementation Considerations: The implementation of Azure Workload Identity support for the Prometheus scaler should be carefully considered to ensure that it is robust, secure, and easy to use. The implementation should build upon the existing podIdentity mechanism in KEDA and provide a seamless integration with the Prometheus scaler. It should also include comprehensive documentation and examples to help users get started.

Testing and Validation: Thorough testing and validation are essential to ensure that the integration works as expected and does not introduce any security vulnerabilities. The testing should cover various scenarios, including different Prometheus-compatible endpoints, different Azure Workload Identity configurations, and different scaling patterns. The testing should also include performance testing to ensure that the integration does not negatively impact the performance of the scaler.

Community Contributions: Community contributions are vital for the success of this integration. Developers and users can contribute by providing feedback on the design and implementation, testing the integration, submitting bug reports, and contributing code. The KEDA community is known for its collaborative spirit, and we encourage anyone who is interested in this feature to get involved.

Conclusion

In conclusion, supporting Azure Workload Identity for Prometheus scaler authentication in KEDA is a significant enhancement that addresses a critical gap in functionality. By enabling dynamic token management, we can improve the security, simplify the management, and enhance the scalability of KEDA-based applications. The proposed solution leverages the existing podIdentity mechanism in KEDA and provides a seamless integration with Azure Workload Identity.

This integration will benefit a wide range of use cases, including monitoring and observability, data processing pipelines, and event-driven applications. By automating the token management process, we can reduce the operational burden on administrators and developers and ensure that applications can securely access Prometheus metrics.

The implementation of this feature will require careful consideration, thorough testing, and community involvement. We encourage developers and users who are interested in this feature to get involved and contribute to its success. Together, we can make KEDA an even more powerful and secure platform for event-driven autoscaling.

By adding support for Azure Workload Identity, KEDA will be better equipped to handle modern, secured Prometheus-compatible endpoints, providing a more robust and secure solution for autoscaling in cloud-native environments. This feature will not only simplify the management of authentication credentials but also enhance the overall security posture of applications running on KEDA.

Keywords Fixed

Here are some of the keywords from the original discussion, rephrased for clarity:

Original: Support Azure Workload Identity for Prometheus Scaler Authentication
- Fixed: How can KEDA support Azure Workload Identity for Prometheus scaler authentication?
Original: Authentication Parameters
- Fixed: What authentication parameters does the KEDA Prometheus scaler currently support?
Original: Dynamic Tokens via OAuth2
- Fixed: How can KEDA fetch dynamic tokens via OAuth2 for Prometheus scaler authentication?
Original: Azure Workload Identity (podIdentity) mechanism
- Fixed: How to implement the existing workload identity (podIdentity) mechanism for azure-workload in KEDA?
Original: AuthenticationRef
- Fixed: How to use authenticationRef with Azure Workload Identity in KEDA for Prometheus?

SEO Title

KEDA and Azure Workload Identity Secure Prometheus Scaler Authentication