Closed jessehouwing closed 4 months ago
+1, PAT tokens must be rotated manually and long-lived PATs are a potential security risk. My team would find it very helpful if there was a built-in way to use AD/Entra tokens for these tasks.
+1, especially now as MSI and service principal authentication are out of preview in Azure DevOps
@michvllni Make sure you check out the blog, it allows you to already switch over.
@jessehouwing there are some scenarios where overriding service connection values using task.setendpoint is blocked due to restricted commands.
It would be really great to have this as part of the task itself for those scenarios where the workaround doesn't work.
Is there an ETA for merging https://github.com/microsoft/azure-devops-extension-tasks/commit/204ae1836e54ff5d03409768b0e075a4f00eec7a to main branch? This help for those that uses version query.
Is there an ETA for merging https://github.com/microsoft/azure-devops-extension-tasks/commit/204ae1836e54ff5d03409768b0e075a4f00eec7a to main branch? This help for those that uses version query.
Version query should work fine with the workaround described in my blog.
I originally started with this hack, but I don't want to support yet another sneak-solution to infinity.
@jessehouwing Yea the workaround in your blog is helpful, but for me the setendpoint doesn't work. I suspect it is because my WIF is connecting to a different tenant. And due to policy/design I can't move the service principal to the same tenant with my azure devops.
Then the environment variables override isn't going to help you I'm afraid.
From the public preview blog post, it looks like Azure is the only service connection that supports WIF right now.
With that in mind, @jessehouwing do you think it would make sense to create a new major version of the tasks that also allow AzureRM
service connections? (I could take a stab at this)
I'd love that. There is an existing npm package that already contains all the magic to get the access token.
Ideally the Azure DevOps Service connection would have an option to select Azure or the existing service connection and optionally a text box for a token input.
Be sure to set the defaults in such a way that existing tasks don't break.
Just merged #905 through #906. Made a few more changes. Awaiting publication of test builds. Thanks @50Wliu <3
@jessehouwing Sorry I am not familiar with the flow of release of this task. When will the v5 be available to use? Can't wait to use it :)
First pipelines now running v5. Doing a bit more testing, then shipping tomorrow
https://github.com/jessehouwing/azure-pipelines-variable-tasks/commit/a994947ee154606607f9c55f09dd42aba42c831c https://dev.azure.com/jessehouwing/azure-devops-extensions/_build/results?buildId=5743&view=results
Shipped: https://github.com/microsoft/azure-devops-extension-tasks/releases/tag/v5.0.37 Marketplace: https://marketplace.visualstudio.com/items?itemName=ms-devlabs.vsts-developer-tools-build-tasks Sample workflow: https://github.com/jessehouwing/azure-pipelines-variable-tasks/blob/main/azure-pipelines.yml
Please upgrade your projects and report back with any issues you find.
Hmm. I successfully log in, but then I get ##[error]__dirname is not defined
when trying to publish a VS extension.
Oh, because https://github.com/microsoft/azure-devops-extension-tasks/blob/main/BuildTasks/PublishVSExtension/v5/Utils.ts#L10. I'll send in a PR later.
With 5.0.65 I was able to publish both a VS & ADO extension to the Marketplace 🥳
I've created a sample workflow that uses a AzureCLI step to overwrite the PAT with a OIDC job token:
https://jessehouwing.net/publish-azure-devops-extensions-using-workload-identity-oidc/
In the future I want to move that functionality straight into the task.