Hello I'd like to propose a topic for the next dev summit related with authentication methods supported to scrape metrics:
I'm helping STACKIT people with their integrations and I'm struggling with their metric APIs. Currently, they only support jwt-bearer flow (RFC7523) and now prometheus common supports it, so it works fine but I'm wondering if would be acceptable to create another authentication section in common for STACKIT and managing the flows using the STACKIT-SDK.I know that this can sound tricky, but STACKIT is working on zero trust approach (the typical workload identity federation) and at this point, that flow doesn't fit with the current oauth2 section (because sadly, there isn't any RFC for workload identity yet, WIMSE <https://www.ietf.org/archive/id/draft-levy-wimse-headless-jwt-authentication-01.html> is working on that).My proposal is to add another section under http_config named stackit that receives the parameters for the authentication. The blueprint of adding the SDK is not a real impact because it's modular and we just need core pkg <https://github.com/stackitcloud/stackit-sdk-go/blob/main/core/go.mod>, which doesn't add any extra dep than the already existing in common: module github.com/stackitcloud/stackit-sdk-go/core go 1.21 require ( github.com/golang-jwt/jwt/v5 v5.3.0 github.com/google/go-cmp v0.7.0 github.com/google/uuid v1.6.0 ) I see that there are other vendored options for remote write and so on, but it's true that they aren't part of common. For example, the sigv4 pkg has it's onw repo to not make common bigger, but it has a lot of extra deps meanwhile the STACKIT one has just 3 and they are already in common. -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/prometheus-developers/9bdccd0d-342a-45b9-85ef-d175b5bbc936n%40googlegroups.com.
