DEV Community: suvankit

Azure MFA Enforcement and Service Principal Migration

suvankit — Sat, 18 Oct 2025 14:36:23 +0000

Microsoft has announced that by October 1, 2025 all Azure sign-ins (including CLI, PowerShell, REST, and IaC tools) will require MFA for user accounts. This means existing automation scripts that use user credentials will break, since MFA cannot be completed non-interactively. To address this, Azure recommends switching any “service accounts” to workload identities – namely service principals or managed identities – which do not require MFA and support non-interactive login.

Impact on automation: Any script doing az login with a user/password will fail with an “Interactive authentication needed” error once MFA enforcement begins. For example, ROPC flows or unattended logins become incompatible with MFA.
Solution: Use Service Principals (or Managed Identities) for automation instead, as these are intended for apps/scripts and aren’t affected by the MFA mandate.

By moving to service principals, our automation can continue running unattended without MFA prompts. Below we explain what service principals are (in plain terms), how they differ from managed identities, and what roles we can assign to them (both Azure RBAC and EA/billing roles). We also give sample Terraform and Azure CLI snippets for creating SPNs and assigning roles.

What Is an Azure Service Principal (Layman’s Terms)

An Azure service principal is essentially a “robot identity” in our Azure AD tenant. Instead of creating a real user for automation, we create an application registration which in turn creates a service principal object. This service principal has its own client ID (app ID) and credential (client secret or certificate) which our scripts can use to authenticate. In simple terms, it’s like giving our script its own login account.

According to Microsoft, a service principal is “An application whose tokens can be used to authenticate and grant access to specific Azure resources”. In practice, using a service principal lets us avoid “fake user” accounts (legacy service accounts) and instead use a dedicated non-human identity for automation. Its permissions are controlled by Azure RBAC roles, so we can tightly restrict exactly what resources it can access. Common use-cases include Terraform deployments, CI/CD pipelines (e.g. Azure DevOps service connections), or any third-party tool that needs Azure tokens.

In contrast, managed identities are a special type of service principal automatically created and managed by Azure for a specific resource (like a VM or App Service). The key differences are: managed identities are tied to one or more Azure resources and Azure maintains the credentials (we never see the secret). This makes managed identities very secure but only useful when our code runs on an Azure resource. A general service principal (unlike a managed identity) is not bound to any resource and is managed by us – giving more flexibility (multi-tenant use, cross-subscription) at the cost of having to securely manage its secret. In summary:

Service Principal – a standalone Azure AD identity (with client ID/secret) for automation. Flexible: can access many resources or subscriptions, but we must create and store its credentials.
Managed Identity – an automatically managed service principal tied to a specific Azure resource. Less flexible: only usable from that resource, but more secure since Azure handles the credentials.

Authenticating with a Service Principal

Once we have a service principal, our automation can log in with it instead of a user. For example, with the Azure CLI we would use:

az login --service-principal -u <APP_ID> -p <CLIENT_SECRET> --tenant <TENANT_ID>

This command signs you in as the service principal non-interactively. The output (as shown below) includes the appId, password (the secret), and tenant we will need to store securely:

After logging in, we can run az commands just like a user. Our SPN’s actions are governed by its assigned roles (below), and it will not be prompted for MFA.

Azure RBAC Roles for Service Principals

A service principal can be assigned Azure RBAC roles at any scope (management group, subscription, resource group, or resource) to grant it permissions to Azure resources. The built-in RBAC roles work the same for SPNs as for users. Common roles include:

Owner – Full access to manage all resources and assign roles (highest privilege).
Contributor – Manage all resources (create/update/delete), but cannot assign RBAC roles.
Reader – View-only access to all resources.
User Access Administrator – Can manage user and service principal access (role assignments), but not resources.

We can also assign service principals any specialized built-in roles (e.g. Key Vault Contributor, Storage Account Contributor, Azure Functions Contributor, etc.) depending on the tasks they need to perform. The principle of least privilege applies: give the SP only the roles it needs. For example, an SPN that only deploys resources might be a Contributor on a resource group; an SPN that only needs to read metrics could be a Reader.

Terraform can create these assignments. For example, after creating an SPN, we can assign roles like this:

data "azuread_service_principal" "example" {
  application_id = azuread_application.example.application_id
}

resource "azurerm_role_assignment" "assign_contributor" {
  scope                = azurerm_resource_group.example.id
  role_definition_name = "Contributor"
  principal_id         = data.azuread_service_principal.example.object_id
}

This snippet looks up the SPN by its application_id and assigns it the Contributor role on a resource group. The same pattern works for any built-in or custom role (using its name or ID). We can also iterate (for_each) over a list of role names if the SP needs multiple roles in the same scope.

Azure EA/Billing Roles for Service Principals

For organizations on an Enterprise Agreement (EA), Azure defines special billing and administrative roles that govern costs, subscriptions, and billing data across the enrollment hierarchy. These roles differ from RBAC roles: they control EA-level resources (like enrollments, departments, accounts) rather than Azure resource groups. Notably, EA roles (such as Enrollment Reader, Department Reader, Subscription Creator, EA Purchaser) can be assigned to service principals via APIs for automating billing tasks. These roles are not visible in the Azure portal and must be assigned programmatically.
Key EA roles we can grant to a service principal include:

EnrollmentReader – View usage and charges across the entire enrollment (all accounts and subscriptions) and see remaining commitment balance.
DepartmentReader – View usage and charges within a specific department scope.
SubscriptionCreator – Create new subscriptions under an enrollment account. (This maps to the EA Administrator’s permission to add subscriptions)
EA Purchaser – Purchase reservation orders and view all enrollment usage (inherits EnrollmentReader and DepartmentReader rights).
PartnerAdmin Reader – (For EA partners) View data for all enrollments under the partner organization. Each EA role has a fixed role-definition ID that we use when assigning it. Unlike RBAC roles, an SP can only hold one EA role at a time.

Use cases: For example, an automation that needs to create Azure subscriptions on demand would use the SubscriptionCreator EA role. A reporting service that pulls cost details could use EnrollmentReader. These roles ensure the SP can manage billing entities without being a full EA admin.

Because EA roles aren’t yet supported in Terraform, we assign them with Azure REST APIs or Azure CLI. For example, using Azure CLI’s az rest command we can PUT a billing role assignment:

# Assign SubscriptionCreator role to SP on an EA enrollment account
az rest --method put \
  --uri "https://management.azure.com/providers/Microsoft.Billing/enrollmentAccounts/{enrollmentId}/billingRoleAssignments/{guid}?api-version=2020-05-01" \
  --body '{
    "properties": {
      "principalId": "<SERVICE_PRINCIPAL_OBJECT_ID>",
      "roleDefinitionId": "a0bcee42-bf30-4d1b-926a-48d21664ef71",  # ID for SubscriptionCreator:contentReference[oaicite:42]{index=42}
      "scope": "/providers/Microsoft.Billing/enrollmentAccounts/{enrollmentId}"
    }
}'

We would replace {enrollmentId} with our EA enrollment’s ID, use the SPN’s object ID, and the role-definition ID from the table above. Similarly, EnrollmentReader is ID 24f8edb6-1668-4659-b5e2-40bb5f3a7d7e, etc. (The Azure CLI also provides billing-specific commands under az billing, but the REST approach is more direct for EA roles).

Creating a Service Principal with Terraform

As a concrete example, here’s how we might provision a service principal using Terraform. We typically use the azuread provider to create an Azure AD application and SPN, and optionally a client secret:

terraform {
  required_providers {
    azuread = { source = "hashicorp/azuread" }
  }
}

# 1. Create the Azure AD application (registration)
resource "azuread_application" "app" {
  display_name = "example-service-principal"
}

# 2. Create the service principal linked to that application
resource "azuread_service_principal" "sp" {
  application_id = azuread_application.app.application_id
}

# 3. Create a client secret for the SP (rotating monthly, for example)
resource "time_rotating" "month" {
  rotation_days = 30
}

resource "azuread_service_principal_password" "password" {
  service_principal_id = azuread_service_principal.sp.object_id
  rotate_when_changed  = { rotation = time_rotating.month.id }
}

# Output the credentials (client_id and client_secret)
output "client_id" {
  value = azuread_application.app.application_id
}
output "client_secret" {
  value     = azuread_service_principal_password.password.value
  sensitive = true
}

When we run this, Terraform will create an AAD App and a corresponding SPN, and then generate a client secret. The outputs client_id and client_secret can be used by our scripts to authenticate. (Always keep the secret safe, e.g. store it in Azure Key Vault rather than plaintext).

Once the SPN exists, we can use the Azure CLI or Terraform (as above) to assign roles to it. For example, to give this SPN Contributor rights on a subscription or resource group, use an azurerm_role_assignment as shown earlier.

TL;DR

With Azure’s new MFA mandate, any automation using user accounts will break. The fix is to use service principals (or managed identities) for non-interactive authentication. A service principal is like a “service account” for our code: it has its own Azure AD identity and credentials. Managed identities are similar but tied to a specific Azure resource. We then control what the SPN can do by assigning Azure RBAC roles (e.g. Contributor, Owner) at the resource level, and if we’re on an Enterprise Agreement, by assigning EA billing roles (e.g. SubscriptionCreator, EnrollmentReader) at the enrollment level.

In practice, we would create the SPN (via Terraform, CLI, or portal), assign it the minimum necessary roles, and update our automation scripts to log in with the SPN’s credentials (e.g. az login --service-principal …). This approach maintains secure automated workflows while complying with the new MFA requirements.

Sources:
Microsoft documentation-
Mandatory MFA
Impact of MFA on automation
Service principals
Built in RBAC roles
EA Roles assignment

Smart Subnet Allocation: Optimizing Your AWS Infrastructure with Terraform

suvankit — Sat, 13 Jul 2024 19:17:04 +0000

Picture this: You're orchestrating a complex AWS infrastructure, juggling multiple subnets and a fleet of instances that seem to multiply overnight. Suddenly, you're faced with a puzzle - how do you efficiently allocate these instances across your subnets without turning your VPC into a digital traffic jam 😵?

Ahh total mess!! Let's understand the problem statement clearly.

Imagine you're the conductor of a grand cloud orchestra. You've got a VPC with more than two subnets, and you're tasked with deploying a variety of servers, including those sneaky auto-scaling groups that grow and shrink on a whim. The question that keeps you up at night: "How can I ensure each instance finds its perfect subnet home, automatically 🤔?"

Sure, AWS offers auto-allocation of IP addresses within a CIDR block, but when you're dealing with a complex VPC architecture, you need something smarter. Something that can look at the big picture and make decisions that keep your network balanced and efficient.

Ta-daa, here enters The Smart Subnet Allocator 🤓.

After much head-scratching and coffee-fueled brainstorming, I stumbled upon an elegant solution. Here's the secret sauce:

Subnet Reconnaissance: First, we scout out all available subnets in our target VPC. It's like taking inventory of all possible homes for our instances.
IP Usage Analytics: We then put on our detective hats and calculate how many IPs are being used in each subnet. This gives us a clear picture of which neighborhoods are bustling and which are quiet.
The Great Subnet Sort: Armed with this information, we sort our subnets from least crowded to most crowded. It's like arranging your closet from emptiest shelf to fullest.
Round-Robin Magic: Finally, we assign our instances to subnets in a round-robin fashion, starting with the least crowded subnet. It's like dealing cards, ensuring everyone gets a fair shot at the best spots.

This approach ensures that we're always placing new instances in the subnets with the most room to breathe, automatically balancing our network load and making the most efficient use of our VPC real estate.

By implementing this logic in Terraform, we can automate this entire process, making our infrastructure not just code, but smart code. It's like having a tiny, efficient robot organizing your cloud resources for optimal performance.

We'll next dive into the Terraform code that makes this happen. We'll show you how to implement this smart subnet allocation strategy, turning your VPC from a chaotic city into a well-planned metropolis of cloud resources.

terraform {
  required_providers {
    aws = {
      version = ">= 2.7.0"
      source  = "hashicorp/aws"
    }
  }
}

We first configured Terraform and required providers. For our use case we took AWS as the cloud provider

# Fetch VPC details
data "aws_vpc" "vpc" {
  filter {
    name   = var.vpc_name
    values = var.vpc_values
  }
  state = "available"
}

# Get all subnet IDs inside the VPC
data "aws_subnet_ids" "subnets" {
  vpc_id = var.vpc_id
  tags = {
    Type = "my-vpc"
  }
}

# Fetch details for all available subnets
data "aws_subnet" "available_subnets" {
  for_each = data.aws_subnet_ids.subnets.ids
  id       = each.value
}

# Get instance allocation details for each subnet
data "aws_instances" "instances_in_subnets" {
  for_each = data.aws_subnet.available_subnets
  filter {
    name   = "subnet-id"
    values = [each.value.id]
  }
}

For the next, we defined our data section in order to get the subnet details from our VPC.

locals {
  # Calculate available IP count for each subnet
  subnet_counts = {
    for subnet in data.aws_subnet.available_subnets : subnet.id => 
      tonumber(split("/", subnet.cidr_block)[1]) - length(data.aws_instances.instances_in_subnets[subnet.id].ids)
  }

  # Sort subnets based on available IP count (ascending order)
  sorted_subnet_counts = sort([
    for subnet_id, count in local.subnet_counts :
    { subnet_id = subnet_id, count = count }
  ])

  # Reverse the sorted list to get descending order
  sorted_subnet_counts_desc = reverse(local.sorted_subnet_counts)
}

This code snippet encapsulates the core logic of our solution:

The subnet_counts map calculates the number of available IPs in each subnet, addressing points 1 and 2 of our solution.
sorted_subnet_counts transforms this information into a sorted list, implementing point 3.
Finally, sorted_subnet_counts_desc reverses the list, preparing us for the round-robin allocation described in point 4.

Now that we have our sorted list of subnets, let's look at how we can use it to deploy multiple instances with smart subnet allocation.

# Considering simplest approach to deploy multiple instances 
variable "instance_count" {
  type    = number
  default = 50
}

# Create EC2 instances with dynamic subnet allocation
resource "aws_instance" "instance" {
  count         = var.instance_count
  instance_type = "t2.micro"
  subnet_id     = local.sorted_subnet_counts_desc[count.index % length(local.sorted_subnet_counts_desc)].subnet_id

  tags = {
    Name = "instance-${count.index + 1}"
  }

  # Other configuration...
}

This code demonstrates the practical application of our subnet allocation strategy:

We define a variable instance_count to specify how many instances we want to deploy.
The aws_instance resource uses Terraform's count parameter to create multiple instances.
The subnet_id assignment is where the magic happens. We use the modulo operator (%) to cycle through our sorted subnet list in a round-robin fashion, implementing the fourth point of our solution.
Each instance is tagged with a unique name for easy identification.

This approach ensures that our instances are evenly distributed across the available subnets, starting with those that have the most available IPs. It's a simple yet effective way to maintain balance in your VPC as you scale your infrastructure.

Let's not forget, in the world of cloud infrastructure, a little automation goes a long way 😋.

Happy terraforming 🤗!