Azure Reservations and the RBAC dilemma

Cloud computing underlies a constant change. Things you take today for granted are different tomorrow. Surprisingly, even designs and implementations on the same platform can be different.

Welcome to today’s topic of Azure Reservations and the RBAC dilemma.

As I have written in my brief introduction, designs and implementations can be different. Azure RBAC is one example here. Being the owner of an Azure subscription does not mean you have access to everything. Access to the Azure Cost Management and Azure Reservations are not part of your permission set. Especially for Azure Reservations this might be surprisingly new for some folks as the RBAC roles Owner and Reservation Purchaser on subscription level have the permissions to purchase reservations.

Overview Azure Reservations

Let us have a look at the Azure documentation.

The user who purchases a reservation and the account administrator of the subscription used for billing the reservation get the Owner role on the reservation order and the reservation.
-> https://docs.microsoft.com/en-us/azure/cost-management-billing/reservations/save-compute-costs-reservations#permissions-to-view-and-manage-reservations

Per default only the user who purchases the reservation and the account administrator have Owner permissions on the reservation itself and its parent the reservation order.

Working in a team of cloud engineers or in a cloud center of excellence, this approach is counterproductive. A single user should not have exclusively access to the purchased Azure Reservations.

Implementation:

You can purchase reservations in two ways. Programmatically or through the Azure portal.

The programmatic way uses a PowerShell or bash script executed by an Azure Service Principal for purchasing the reservations.

-> https://docs.microsoft.com/en-us/powershell/module/az.reservations/?view=azps-5.1.0#reservations
-> https://docs.microsoft.com/en-us/cli/azure/reservations?view=azure-cli-latest

This ensures a decoupling from a real user as several cloud engineers have access to an Azure Service Principal for instance.

But in the end, you end up in the same situation whether you purchase the reservations programmatically or via the Azure portal. Not everyone from the cloud engineering team can see the reservations in the portal. Especially in the case of using a script with an Azure Service Principal. Nobody sees them.

So, you should assign the Owner role to an Azure AD group on the reservation order after you purchased the reservation.

This can be easily done with the following bash script.

RESERVATION_ORDERS=$(az reservations reservation-order list --query '[].id' -o tsv)
for ITEM in $RESERVATION_ORDERS; do
  az role assignment create --assignee "{AZURE_AD_GROUP_OBJECT_ID}" --role "Owner" --scope $ITEM --verbose
done

For the programmatic way using a script executed by an Azure Service Principal it is part of the automated workflow.

Doing it via the Azure portal, the role assignment is part of a defined process. But in the end a manual task that sometimes might be forgotten to be executed.

Summary:

Whatever way you choose a necessary step in the process of ordering a new Azure Reservation should be the assignment of the Owner role on the reservation order to an Azure AD group.

Facebooktwitterlinkedinmail