design-proposal: limit Live Migration initial permissions to cluster-admin

[tiraboschi]

What this PR does / why we need it:
In kubernetes we have two distinct pre-defined administrative roles:

• cluster-admin that is allowed to to perform any action on any resource
• admin that is allowed to read/write/amend almost all the resources in a namespace

We can assume that that granting to a developer/devops person the admin role to a namespace that he "owns" is a common practice.

In order to enqueue o cancel a live migration request, the user is supposed to create a VirtualMachineInstanceMigration object that is a namespaced resource that lives in
the same namespace of the VM object.
Till now, a namespace admin is allowed to create/delete VirtualMachineInstanceMigration objects in his namespaces.

The issue that this proposal is trying to address is that live migration is also a critical feature for cluster wide tasks such as upgrades, node drains and so on.
So today an unprivileged user can already easily delay a cluster upgrade or a node drain simply continuously enqueuing migrations or even block it by continuously deleting VirtualMachineInstanceMigration objects as soon as they appear on the cluster.

This proposal is about allowing, by default, only cluster-admin users to create/delete VirtualMachineInstanceMigration objects as a hardening measure (principle of least privilege).
Please notice that this is not an API change.

A cluster-admin will still be allowed to grant the migration role to selected users or groups.
Other actions like hotplugging that are only implicitly relying on a live migration are not going to be affected by this change.

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:
Please notice that this is not an API change but simply hardening (principle of least privilege) on the default KubeVirt roles.
A cluster-admin will still be allowed to grant the migration role to selected users or groups or even restore the previous behaviour.

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:

limit Live Migration initial permissions to cluster-admin

[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 rmohr for approval. For more information see the Kubernetes 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

[xpivarc]

Looks good overall

[xpivarc]

Note worthy would be that for smooth upgrades the admin is required to pre-deploy the cluster role and bind it.

[fabiand]

Should our operator actually do this if we see that it is an upgrade?

[tiraboschi]

Personally I think that aiming to have clusters deployed with an old version and then upgraded behaving by default exactly as fresh clusters is more than desiderable in terms of maintainability and harmonization.
Otherwise a cluster admin managing two different clusters deployed starting with different versions could be surprised by a different behaviour that is hard to track and justify.
A really conscious cluster admin could still pre-deploy a temporary clusterrole to grant migration rights to all the namespace admins (labelling it with rbac.authorization.k8s.io/aggregate-to-admin=true ) and remove it only when he is absolutely sure that all the users that needs to be able to trigger live migrations got bound to the new kubevirt.io:migrate cluster role.
I added it to the proposal.