Skip to content

Conversation

paulfantom
Copy link
Member

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
Copy link

liggitt commented Oct 18, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants