Add eks service account mutator webhook

[Helen300]

What this PR does / why we need it:

This PR adds a new repository to the KubeVirt org. This repo will be used to host the source code for the mutator webhook for injecting virtiofs containers into virt-launcher pods that have an EKS service account token associated with it. The virtiofs containers will be used to share the tokens as filesystem mounts to the VM so that any changes/refresh to the token will also propagate to the VM.

This will be an extension of KubeVirt and specifically handles the case in which kube service account tokens containing EKS annotations are mounted as volumes to a kubevirt VM.

Related to kubevirt/kubevirt#13738 and kubevirt/kubevirt#13311

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

• Design: A design document was considered and is present (link) or not required
• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
• Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
• Community: Announcement to kubevirt-dev was considered

Release note:

[kubevirt-bot]

Hi @Helen300. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[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 phoracek 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

[brianmcarey]

Hi @Helen300

Thanks for creating this PR and your work on this so far.

Before adding a new repo, we generally like to introduce the new repo/project to the community on the mailing list and explain why this new repo is needed. This will help with getting wider community awareness and feedback.

Also I think you will need to find a couple of community members to volunteer to be maintainers for this repo as we will need to identify owners before we create the repo. Maybe you could include this request in the mailing list introduction?