The Azure cloud node manager uses a service account with a cluster role attached that provides it with cluster wide permissions to update Node objects.

This means, were the service account to become compromised, Node objects could be maliciously updated.

To limit the blast radius of a leak, we should determine if there is a way to limit the Azure Cloud Node Manager to only be able to update the node on which it resides, or, to move it's functionality centrally within the cluster.

Possible paths:
* Check upstream progress for any attempt to move the node manager role into the CCM
* See if we can re-use kubelet credentials as these are already scoped to updating only the Node on which they reside
* See if there's another admission control method we can use to limit the updates (possibly https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/) 

4.14.0

Always

1.
2.
3.