While testing the backport of Azure Reserved Capacity Group support a customer observed that they lack permissions required when operating with Workload Identity (token and role based auth). However this is a curious one where it's likely that the target group may not necessarily be part of the group in which the cluster runs so it would require input from the admin in some use cases.

4.17.0    

100%    

    1. Install 4.17 in Azure with Workload Identity configured
    2. Create an Azure Reserved Capacity Group, for simplicity in the same resource group as the cluster
    3. Update a machineset to use that reserved group
    

    Permissions errors, missing Microsoft.Compute/capacityReservationGroups/deploy/action

    Machines created successfully

As mentioned in the description it's likely that the reserved capacity group may be in another resource group and thus in order to create the role it requires admin input, ie: cannot be computed 100% of the time. Therefore that specific use case may be a documentation concern unless we can come up with a novel solution.

Further, it also brings up the question of whether or not we should include this permission in the default cred request or not. Customers may not use that default for reasons mentioned above, or they may not even use the feature entirely. But, I think for now it may be worth adding it to the 4.17 CredRequest and treating use of this feature in backported versions as a documentation concern, since we wouldn't want to expand permissions on all 4.16 or older clusters.