Support for Azure resource role settings (related to/complementary to azurerm_pim_eligible_role_assignment)

[MohnJadden]

Is there an existing issue for this?

• I have searched the existing issues

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment and review the contribution guide to help.

Description

Privileged Identity Management has a series of settings for each role assignment at each scope: management group, subscription, resource group, or resource. These PIM settings govern details such as how long PIM eligibility lasts, approvals required, etc.

Terraform recently released the ability to assign Azure resource roles to PIM via azurerm_pim_eligible_role_assignment, but there's no way to set resource role settings from Terraform. Some use cases involve PIM eligible assignments that are permanent or longer than the 1 year default, and we have to create the resource group then manually change it in order to get PIM to work. The same goes for PIM assignments where different approval or notification workflows are required.

We should be able to set these role settings via Terraform. The settings should all be optional, with separate blocks for approvals or other future workflows that have more than just bool/int/string values.

New or Affected Resource(s)/Data Source(s)

azurerm_pim_eligible_role_assignment

Potential Terraform Configuration

resource "azurerm_resource_group" "test-rg" {
name = "foobar"
location = "test"
}

resource "azurerm_pim_eligible_role_assignment" "test-assignment" { 
scope = azurerm_resource_group.test-rg.name
role_definition_id = "/subscriptions/ourSubscriptionGUID/providers/Microsoft.Authorization/roleDefinitions/roleDefinitionGUID"
principal_id = "guidOfSecurityGroup"
  schedule {
    start_date_time = "2023-10-02T17:00:00Z"
    expiration {
      end_date_time = "2099-10-02T17:22:00Z"
    }
}

resource "azurerm_pim_eligible_role_settings" "test-settings" { 
activation_maximum_duration = "integerValueOfHours"
allow_permanent_eligible_assignment = "true"
require_mfa_on_activation = "true"
require_justification_on_activation = "true"
require_approval_for_activation = "true"
approval {
list_of_approvers = ["emailA","emailB"]
}

References

Identified via/related to #22766
#23432 is tangentially related

[drdamour]

@MohnJadden doesn't the proposed azurerm_pim_eligible_role_settings require some properties that define the scope of the policy/settings aka a subscription or a resource group?

fwiw #23295 looks to implement this as a azurerm_role_management_policy

[MohnJadden]

@drdamour When defining PIM settings for Azure resources, I'd argue that specifying the resource in TF defines the scope automatically.
For example, if you're setting a security group to have the Virtual Machine Local Admin PIM role for just one VM by targeting azurerm_virtual_machine.foobar, that has already defined the scope to just that one resource.

Meanwhile, if you're setting a security group to have that same role for an entire resource group via azurerm_resource_group, then the scope is defined to be done at that resource group.

Same thing applies for entire subscriptions, management groups, etc. If we require specifying additional scopes for settings, those scopes may or may not be managed by Terraform, and users may not want to import them into TF. I'd say the same process used to manage one or more resources as defined in TF should be used here, rather than making users do an additional step (which may require even more re-engineering to make happen in the first place for those of us onboarding TF in brownfields)

[drdamour]

@MohnJadden not sure what you're describing. Settings have ot apply to something, a resource group or a subscription. Your example terraform doesn't have an property that defines what that scope is. they can't just be set at root level.

ie you suggested:

resource "azurerm_pim_eligible_role_settings" "test-settings" { 
  activation_maximum_duration = "integerValueOfHours"
  allow_permanent_eligible_assignment = "true"
  require_mfa_on_activation = "true"
  require_justification_on_activation = "true"
  require_approval_for_activation = "true"
  approval {
    list_of_approvers = ["emailA","emailB"]
  }
}

and i'm saying it would need to be more like

resource "azurerm_pim_eligible_role_settings" "test-settings" { 
  # this is needed
  scope = azurerm_resource_group.test-rg.id
  
  
  activation_maximum_duration = "integerValueOfHours"
  allow_permanent_eligible_assignment = "true"
  require_mfa_on_activation = "true"
  require_justification_on_activation = "true"
  require_approval_for_activation = "true"
  approval {
    list_of_approvers = ["emailA","emailB"]
  }
}

thats whatended up being done in the pr https://github.com/hashicorp/terraform-provider-azurerm/pull/23295/files#diff-2625d6c1d3f739cd95745c6745af8e56396cd922c66d94c315c7dc905e69fdf2R38

[MohnJadden]

@drdamour Very true. Good point - my example specified a scope for the assignment, but not settings. If there's no resource to specify against, there's nothing to set. Thank you for taking the time to clarify!

Good to see the PR is in progress, thanks for linking it!

[knuterik-ballestad]

I would like to be able to use this module the same way we use "azurerm_role_assignment" - with constraints/filters applied to the roles. That would allow us to assign PIM-able "Owner" role (with constraints that only allows Owner to assign "Contributor", "Reader" and "Key Vault).

A syntax somewhat like this would be very nice to have (and consistent with "azurerm_role_assignment"):

resource "azurerm_pim_eligible_role_assignment" "eligible_role_assignment" {
  for_each           = var.subscription_owners # set
  scope              = "/subscriptions/${var.subscription_id}"
  role_definition_id = "/subscriptions/${var.subscription_id}${data.azurerm_role_definition.pim_owner.id}"
  principal_id       = each.value
  schedule {
    start_date_time = time_static.timestamp_now.rfc3339
    expiration {
      duration_days = 365     # Would like to be able to assign non-expiring roles as well
    }
  }
  justification     = "<text>"
  condition_version = "2.0"
  condition         = <<-EndOfInsertedJSON
    ((!(ActionMatches{'Microsoft.Authorization/roleAssignments/write'}))
      OR (@Request[Microsoft.Authorization/roleAssignments:RoleDefinitionId] 
        ForAnyOfAnyValues:GuidEquals {b24988ac-6180-42a0-ab88-20f7382dd24c, acdd72a7-3385-48ef-bd42-f606fba81ae7, f25e0fa2-a7c8-4377-a976-54943a77a395}))
    AND 
      ((!(ActionMatches{'Microsoft.Authorization/roleAssignments/delete'}))
        OR (@Resource[Microsoft.Authorization/roleAssignments:RoleDefinitionId] 
          ForAnyOfAnyValues:GuidEquals {b24988ac-6180-42a0-ab88-20f7382dd24c, acdd72a7-3385-48ef-bd42-f606fba81ae7, f25e0fa2-a7c8-4377-a976-54943a77a395}))
  EndOfInsertedJSON

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.