Declarative Prometheus SA Token Secret

[paulfantom]

Description

Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request.
If it fixes a bug or resolves a feature request, be sure to link to that issue.

Since kubernetes 1.24 it is possible to declaratively configure Secret containing ServiceAccount token instead of only relying on kubernetes to create that Secret with generated name suffix. This in turn allows to reference the Secret (instead of using bearerTokenFile inside a container FS) from objects like ScrapeConfig to use for authentication against kubernetes API.

This is a prerequisite to migrate Kubelet ServiceMonitor to ScrapeConfig.

I am leaving this as a draft as I am still testing this out.

Type of change

What type of changes does your code introduce to the kube-prometheus? Put an x in the box that apply.

• CHANGE (fix or feature that would cause existing functionality to not work as expected)
• FEATURE (non-breaking change which adds functionality)
• BUGFIX (non-breaking change which fixes an issue)
• ENHANCEMENT (non-breaking change which improves existing functionality)
• NONE (if none of the other choices apply. Example, tooling, build system, CI, docs, etc.)

Changelog entry

Please put a one-line changelog entry below. Later this will be copied to the changelog file.

[liggitt]

Since kubernetes 1.24 it is possible to declaratively configure Secret containing ServiceAccount token instead of only relying on kubernetes to create that Secret with generated name suffix

This is actually supported against all Kubernetes versions >1.0