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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trying to assign Service Principal manipulation rights to another Service Principal #341

Closed
r3-jerrysteele opened this issue Oct 6, 2020 · 4 comments
Labels

Comments

@r3-jerrysteele
Copy link

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

Terraform (and AzureRM Provider) Version

Terraform v0.12.29
+ provider.azurerm v2.21.0

Affected Resource(s)

azurerm_role_definition

Terraform Configuration Files

resource "azurerm_role_definition" "jenkinsmanipulatesps" {
  name        = "Manipulate SPs"
  scope       = data.azurerm_subscription.dev.id
  description = "Manipulate Service Principals within subscription"

  permissions {
    actions = [
      "microsoft.directory/servicePrincipals/allProperties/read",
      "microsoft.directory/servicePrincipals/allProperties/update",
      "microsoft.directory/servicePrincipals/create",
      "microsoft.directory/servicePrincipals/delete"
    ]
    not_actions = []
  }

  assignable_scopes = [
    data.azurerm_subscription.dev.id
  ]
}

Debug Output

Panic Output

Expected Behavior

Role definition should be created, ready to be assigned to service principal

Actual Behavior

Error: authorization.RoleDefinitionsClient#CreateOrUpdate: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="InvalidActionOrNotAction" Message="The resource provider referenced in the action is not returned in the list of providers from Azure Resource Manager."

It looks like this is because AD-related ("admin") roles are different from other custom roles - I have a couple of other custom role definitions related to "Microsoft.Authorization/roleAssignments/*/write" and they work fine. Is it possible to manipulate these AD-related roles with Terraform?

As far as I can see the permissions in the actions list are correct for this.

Steps to Reproduce

  1. terraform apply (terraform plan works fine)

Important Factoids

References

  • #0000
@magodo
Copy link

magodo commented Oct 12, 2020

Hey @r3-jerrysteele thank you for submitting this 👍

Only the permissions/actions listed in this view is supported for the azurerm_role_definition resource, whilst the actions you are trying to assign to the custom role is beyond this set.

What you are trying to do is to create the AAD custom role (rather than Azure custom role), as documented here. I guess that is the responsibility of terraform-provider-azuread (although it seems not supported yet).

@tombuildsstuff
Copy link
Contributor

Transferring this to the AzureAD Provider since this is an AzureAD issue

@tombuildsstuff tombuildsstuff transferred this issue from hashicorp/terraform-provider-azurerm Oct 26, 2020
@manicminer
Copy link
Contributor

manicminer commented Oct 27, 2020

@r3-jerrysteele As far as I know, there is no resource provider named "microsoft.directory". Permissions to edit directory objects such as service principals are usually assigned via Directory Roles (which are different to IAM Roles) or API scopes in the context of the tenant.

We don't currently support directory role assignments as they are not implemented by the current API. However we will be in a position to implement these in the near future and this feature request is currently being tracked in #50

I'm going to close this for now as a duplicate of #50, however if we have misunderstood your report please feel to comment further.

@ghost
Copy link

ghost commented Nov 26, 2020

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!

@ghost ghost locked as resolved and limited conversation to collaborators Nov 26, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants