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

The azuredevops_user_entitlement resource doesn't work with the System Token provided in an Azure DevOps pipeline #1089

Open
JustinDroege opened this issue Jul 3, 2024 · 4 comments
Labels

Comments

@JustinDroege
Copy link

JustinDroege commented Jul 3, 2024

Terraform (and Azure DevOps Provider) Version

Terraform Version: 1.8
Azure Devops Provider Version: 1.1.1
Azure Devops Services & Managed Build Agents

Affected Resource(s)

  • azuredevops_user_entitlement

Terraform Configuration Files

resource "azuredevops_user_entitlement" "this" {
  principal_name       = 'user@user.de'
}

Expected Behavior

Currently, we are using the Terraform provider in the context of an Azure DevOps Services pipeline. We are using the $System.AccessToken to set the environment variable AZDO_PERSONAL_ACCESS_TOKEN. In the provider configuration, we apply the Azure DevOps Organization ID. When the pipeline is executed, we expect to be able to authorize users from the same Entra instance, which is also used by the Azure DevOps Organization, to be part of the Organization.

Actual Behavior

We receive an error stating that it is not possible and that the users are not part of the directory. The output looks like this:
Error: Creating user entitlement: Adding user entitlement: (5102) You are trying to invite a user from outside your directory, but something went wrong. Please contact Azure DevOps support.

With a personal token (PAT), everything works fine, so the user is part of the directory. We also tried giving the Build Service account all permissions.

Steps to Reproduce

  1. Use the azure_devops_entitlement resource and set a valid UPN.
  2. Set the organization ID in the provider configuration block:
provider "azuredevops" {
  org_service_url = 'bla'
}
  1. Execute the apply in an Azure DevOps Pipeline with the given $System.AccessToken: AZDO_PERSONAL_ACCESS_TOKEN=$(System.AccessToken) terraform apply

References

@JustinDroege JustinDroege changed the title azuredevops_user_entitlement doesn't work with the System Token provided in a pipeline The azuredevops_user_entitlement resource doesn't work with the System Token provided in an Azure DevOps pipeline Jul 3, 2024
@JustinDroege JustinDroege changed the title The azuredevops_user_entitlement resource doesn't work with the System Token provided in an Azure DevOps pipeline The azuredevops_user_entitlement resource doesn't work with the System Token provided in an Azure DevOps pipeline Jul 3, 2024
@xuzhang3
Copy link
Collaborator

xuzhang3 commented Jul 4, 2024

PAT is a bit different from the System.AccessToken, they have different permission scopes
More details:
https://registry.terraform.io/providers/microsoft/azuredevops/latest/docs/guides/authenticating_using_the_personal_access_token

@JustinDroege
Copy link
Author

@xuzhang3 Thx for the fast answer. We already knew that and therefore tried adding the Build Service to the Project Collection Administrators and disabled the feature "Limit job authorization scope to current project for non-release pipelines", but this didn’t help us. Do you know if it’s even possible to set the scope for inviting users on a System Token?

@xuzhang3
Copy link
Collaborator

xuzhang3 commented Jul 8, 2024

@JustinDroege you may need to update the permission for collection build service accounts
More details:
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/access-tokens?view=azure-devops&tabs=yaml

The token's permissions are derived from (a) job authorization scope and (b) the permissions you set on project or collection build service account.

@JustinDroege
Copy link
Author

Hey, I did some research and it seems that Azure DevOps currently doesn't support this use case. I tried all the different configurations mentioned in your link. I also tried the same with the CLI and got the same error. I guess our solution will be to use a technical user with the correct permissions and use the PAT from that user. Thanks for your help. I think we can close this now :)

@xuzhang3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants