AzureRM Service Endpoint specify Resource Group scope with Credentials

[josh-barker]

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 Azure DevOps Provider) Version

terraform version v0.13.2

Affected Resource(s)

• azuredevops_serviceendpoint_azurerm

Terraform Configuration Files

resource "azuredevops_serviceendpoint_azurerm" "endpointazure" {
  project_id            = azuredevops_project.project.id
  service_endpoint_name = "TestServiceRM"
  credentials {
    serviceprincipalid  = "xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx"
    serviceprincipalkey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
  }

  resource_group = "/subscriptions/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx/resourceGroups/my-resource-group"

  azurerm_spn_tenantid      = "xxxxxxx-xxxx-xxx-xxxxx-xxxxxxxx"
  azurerm_subscription_id   = "xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx"
  azurerm_subscription_name = "Sample Subscription"
}

Expected Behavior

I expect that I can create a Service Connection scoped to a resource group when I provider credentials.

Actual Behavior

terraform plan
Error: "credentials": conflicts with resource_group

References

• https://github.com/microsoft/terraform-provider-azuredevops/blob/master/azuredevops/internal/service/serviceendpoint/resource_serviceendpoint_azurerm.go#L25
• https://github.com/microsoft/terraform-provider-azuredevops/blob/master/azuredevops/internal/service/serviceendpoint/resource_serviceendpoint_azurerm.go#L34

[xuzhang3]

@josh-barker I afraid we cannot do it in this way. Currently, azurerm support two types of AzureRM service connections: service principal (automatic) and service principal (manually)

If you choose to create in automatic way, you need specify the resource group name and subscription, no need to configure the service principal, service will create a new service principal in AzureRM, you can find the new created service principal in Azure Active Directory -> App registrations.

Due to the different creation mode of the AzureRM service connection, resource group and spn is conflict with each other in ADO provider.

[josh-barker]

Hi @xuzhang3,

There's another situation where I can configure a Service Principal Manually and set a resource group scope.

To do this from the portal, the process is:

1. Click on "Service Principal (Automatic)"
2. Set the Resource Group,
3. Press back
4. Click on "Service Principal (Manual)"
5. Fill in the service principal details
6. Press Verify & Save

You can call this endpoint https://dev.azure.com/{organization}/{project}/_apis/serviceendpoint/endpoints?api-version=6.1-preview.4 to verify the resource group has been configured in the scope.

{
  "data": { 
    "scopeLevel": "Subscription",
  },
  "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "name": "demo",
  ...
  "authorization": {
    "parameters": {
      "authenticationType": "spnKey",
      "scope": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/demo",
      "serviceprincipalid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
      "tenantid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
     }
  },
  ...
}

Scenarios:

1. resource_group has a value => Automatic
2. credentials has a value => Manual
3. credentials has a value and resouce_group has a value => Manual and scope is assigned.

To allow for all 3 scenarios, I think it could be changed from ConflictsWith to AtLeastOneOf: []string{"resource_group", "credentials"}.

Hope that makes sense. Cheers

[xuzhang3]

@josh-barker Which environment and scope level are you use, current environment and scope level are fixed to Azure Cloud and Subscription in ADO provider.

[josh-barker]

@xuzhang3 In the portal, I set the scope to the Subscription and chose a Resource Group.

Yep, the environment is AzureCloud and scopeLevel is Subscription.

[xuzhang3]

@josh-barker I get your point, more like a trick. I need to confirm this with service team whether this is normal.

[veyu]

I stumbled upon this ticket when looking for information how I should configure service connection to AML workspace. I think I have similar problem - I am trying to configure AzureRM service connection with resource_group and credentials (and probably AML workspace name as well). In portal I am using the same "trick" as @josh-barker (to not enter all stuff by myself) but in my case every field is explicitly shown.

@xuzhang3 Is configuring service connection to AML workspace somehow different than configuring standard AzureRM service connection? How can I do it using Terraform? If it's not possible, should I create ticket for it? Or it would be part of ticket submitted by @josh-barker ?

[josh-barker]

@xuzhang3 How did you go with the service team?

[josh-barker-coles]

Hi @xuzhang3, just following up on this issue.

Cheers,

Josh

[xuzhang3]

@josh-barker @josh-barker-coles Sorry for the late reply. I got no reply from service team but get the information from the support team that this is not a bug. Based on the information I can get, I think we can introduce this feature to the ADO provider.

[alphabetagamma314159]

Hi all,

I am facing the same issues as @veyu.

@josh-barker @veyu @josh-barker-coles Have you found a solution on how to automate this step with terraform?

@xuzhang3 is this feature already introduced in the ADO provider? Unfortunately I was not able to find it. If not, can you estimate the timeline of when this feature will be implemented?

Edit: If there is no plan to implement this specific feature, is it planned to introduce a way of creating machine learning workspace connections?

Thank you very much in advance!

Best,

Niclas

[stormshaun]

To do this from the portal, the process is:

1. Click on "Service Principal (Automatic)"
2. Set the Resource Group,
3. Press back
4. Click on "Service Principal (Manual)"
5. Fill in the service principal details
6. Press Verify & Save

This 'trick' doesn't work, or doesn't work anymore. I am also trying to look into having a Resource Group scope with credentials as I want to avoid the service creating a new service principal in AzureRM for each connection if possible