Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for role PIM Role Assignments #19912

Open
1 task done
biggles007 opened this issue Jan 9, 2023 · 4 comments 路 May be fixed by #25900
Open
1 task done

Support for role PIM Role Assignments #19912

biggles007 opened this issue Jan 9, 2023 · 4 comments 路 May be fixed by #25900

Comments

@biggles007
Copy link

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

Description

Through the Terraform AzureRM provider it isn't currently possible to assign PIM roles to Azure resources. Using AzAPI you can use the Microsoft.Authorization/roleEligibilityScheduleRequests resource type, but that then means all deployments required the AzAPI provider configuration.

It would be really helpful to have this natively in AzureRM to easily allow the zero trust/secure by design environments to easily be deployed.

Having separate resource type for the assignment would be beneficial, as the same API/resource type can be used to both assign a PIM role and also activate it.

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

azurerm_role_eligibility_assignment

Potential Terraform Configuration

resource "azurerm_role_eligibility_assignment" "demo" {
  name = "string"
  scope = "string"
  principalId = "string"
  requestType = "string"
  roleDefinitionId = "string"
}

References

https://learn.microsoft.com/en-us/azure/templates/microsoft.authorization/roleeligibilityschedulerequests?tabs=bicep&pivots=deployment-language-terraform

@LemurDaniel
Copy link

LemurDaniel commented Jul 3, 2023

Hi,

is there any info about more progress regarding PIM?

It is needed by the company I currently work for, as of now we implemented a workaround by using null_resources to call the PIM-Api via terraform.


Note: We already tried the AzApi-Provider which was only semi-useful.

It worked for deploying PIM-ScheduleRequests, but problems came as soon as something needed to be replaced or destroyed.
Since the 'azapi_resource' by default calls a DELETE-Request on the 'roleEligibilityScheduleRequests'-Endpoint. This isn't supported by the roleEligiblityScheduleRequest-API, it is actually expecting a PUT-Request of type 'AdminRemove'.

image


I noticed that the azure-sdk-for-go used for the authorization resources in this provider doesn't yet support pim.

However the go-azure-sdk used in other parts of the AzureRm-Provider already implements functions to call and create scheduleRequests, etc: go-azure-sdk: Create eligiblityScheduleRequest

As already mentioned by the user above we would need resources for both schedule-Requests:

resource "azurerm_role_eligibility_schedule_request" "demo" {
  # name                 = "string" # maybe optional as it is always a random GUID
  scope                = "string"
  principal_id         = "string"
  request_type         = "string" # AdminAssign, AdminRemove, etc.
  role_definition_name = "string"

  justification = "string"


  # Possibly a block with different parameters for the different expirations

  # My company uses the current workaround to only deploy Permanent-Assignments
  # Variant for NoExpiration.
  schedule {
    type = "NoExpiration"
  }

  # Variant for Duration
  schedule {
    type          = "NoExpiration"
    startDateTime = "YYYY-MM-DDTHH:mm:ss.0000000+02:00"
    duration      = "P90D"
  }
}

resource "azurerm_role_assignment_schedule_request" "demo" {
  # name                 = "string" # maybe optional as it is always a random GUID
  scope                = "string"
  principal_id         = "string"
  request_type         = "string" # AdminAssign, AdminRemove, etc.
  role_definition_name = "string"

  justification = "string"
}

As well as the PIM-Settings:

# Possibly sperate resources for the rules, since those can only be defined on scopes and not per individual PIM-Assignment.
resource "azurerm_role_management_policy" "demo" {
  scope                = "string"
  role_definition_name = "string"

  # Maybe seperate blocks per rule
  activation_settings {
    maximum_duration = "string" # optional
    enabled_rules = [
      "MultiFactorAuthentication",
      "Justification",
      "Ticketing"
    ]

    justification_required = bool
    approval_required      = bool
  }

  assignment_settings {
    maximum_duration = "string" # Permanent or P365D, etc.
  }


  notification_settings_eligible {}
  #  .
  #  .
  #  .
  # etc.

}

@tim-krehan
Copy link

tim-krehan commented Jul 18, 2023

Hi Together :)

this topic got implemented with v3.64.0.
BUT:
There are still the settings missing for

  • activation
  • assignment
  • notification

Is there any plans to implement them as an additional resource?

@LemurDaniel
Copy link

LemurDaniel commented Jul 18, 2023

Aside from the missing settings the terraform-resource also doesn't seem to allow for permanent-assignments.

There seems to be no permanet option, since with the ScheduleRequest-API you could also create permanent-assignment by providing 'NoExpiration'.

@MohnJadden
Copy link

I noticed this behavior in 3.67.0 and opened #22756 - it looks like it's in the final stages of implementation, so hopefully we'll see it in 3.68.0.

@oWretch oWretch linked a pull request May 8, 2024 that will close this issue
13 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants