VEP94: add projected volumes in Volume API

[vladikr]

VEP Metadata

Tracking issue: #94
SIG label: /sig compute

What this PR does

This VEP extends KubeVirt's Volume API to support Projected Volumes, enabling dynamic mounting of service account tokens with custom audiences and paths, addressing limitations for scenarios like AWS IRSA. Exposing these tokens to the guest OS via virtioFS

Special notes for your reviewer

N/A

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign xpivarc for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[germag]

I'll take this one.

[germag]

I'm thinking that maybe the API should be:

volumes:
- name: irsa-volume
  serviceAccount:
    serviceAccountName: service-account-irsa
    serviceAccountToken:
        audience: "sts.amazonaws.com"
        expirationSeconds: 3600
        path: "token"

The only drawback (that I can see) is it will not be integrated with
the rest of projected volume sources (e.g., configMap) if we support
those in the future.

Let me explain:

The current Kubevirt API is:

volumes:
- name: irsa-volume
  serviceAccount:
    - serviceAccountName: service-account-irsa

I don't really like this API because it suggests it can be more
than a single serviceAccount volume, so it's confusing. For instance,
the k8s API is explicit about that:

kind: Pod
...
spec:
  serviceAccountName: build-robot
  automountServiceAccountToken: false

So, if we use the proposed API in this VEP we also must define the
serviceAccountName somewhere, so we have few options:

1- define both the volume and the projection:

volumes:
- name: irsa-volume
  serviceAccount:
    serviceAccountName: service-account-irsa

- name: irsa-volume-projected
  projected:
    sources:
    - serviceAccountToken:
        audience: "sts.amazonaws.com"
        expirationSeconds: 3600
        path: "token"

Even if this option will allow more projected sources in the future, and
is more similar to k8s API, I think it's not an option because both
have volumes.name which one we should mount?, is very confusing.

2- Add serviceAccountName under serviceAccountToken

volumes:
- name: irsa-volume
  projected:
    sources:
    - serviceAccountToken:
        serviceAccountName: service-account-irsa
        audience: "sts.amazonaws.com"
        expirationSeconds: 3600
        path: "token"

I also don't think this is a good API, it's not consistent with the
actual API, so what happens if the user defines this and
volumes.serviceAccount.serviceAccountName, which one should have
priority?. The only "pro" I can see is it will allow sharing other projected
sources in the future (if we want to support them)

That is the reason I think

volumes:
- name: irsa-volume
  serviceAccount:
    serviceAccountName: service-account-irsa
    serviceAccountToken:
        audience: "sts.amazonaws.com"
        expirationSeconds: 3600
        path: "token"

is a bit better, even if it will not be shared with others projected
sources in the future, and is not close to the k8s API. I also have
the advantage that the current admitter code will still prevent
multiple serviceAccount's

@vladikr wdyt?