Goal

Cloud providers are injecting automatically tokens into pods. VM guests required access to these tokens in order to to speak to the hyperscaler API (not Kube, but the hyperscalers API).
The difference to ie CNV-18227 is: In CNV-18227 kubevirt assumes that the token of this SA has to be injected into the VM. However, hyperscalers are using non-standard way s(i.e annotations) to piggy back on an existing SA, but then inject the token provided as an annotation. Thus, this epic makes less assumptions and is allowing a VM owner to pass through a selected file from the container side into the VM (using virtio-fs, read-only). Thus this implementation allows to pickup tokens in the container's file-system reagrdless how they got there.

Key is: These tokens (we care about in ROSA/AWS/GCP) after we create the pod, and we do not know how they get there.

User Stories

• As a VM owner, I want to hae access to the hyperscaler provided hyperscaler-API tokens, so that I can authenticate against and use the hyperscaler's API.
• another user story

Non-Requirements

• List of things not included in this epic, to alleviate any doubt raised during the grooming process.

Notes

• If this is scoped to managed services, then managed services should do QA.