Set oidc variables for use in pre/post scripts and elsewhere #8367
Conversation
benbp
added
the
Central-EngSys
|
The following pipelines have been queued for testing: |
danieljurek
left a comment
danieljurek
left a comment
There was a problem hiding this comment.
This seems reasonable given the dependency on both Az PowerShell modules and az CLI in some of the pre and post scripts.
It probably also makes sense to Delete the credentials after the test resource provisioning script has finished.
| inlineScript: | | ||
| Write-Host "##vso[task.setvariable variable=ARM_CLIENT_ID;issecret=true]$($env:servicePrincipalId)" | ||
| Write-Host "##vso[task.setvariable variable=ARM_TENANT_ID;issecret=true]$($env:tenantId)" | ||
| Write-Host "##vso[task.setvariable variable=ARM_OIDC_TOKEN;issecret=true]$($env:idToken)" |
There was a problem hiding this comment.
Should this be called OIDC? In other places we are calling it Federated token for example.
There was a problem hiding this comment.
I was copying this off the task you added. Want me to edit both and normalize?
There was a problem hiding this comment.
Which task are you referring to? I don't remember using OIDC naming anywhere.
There was a problem hiding this comment.
@weshaggard net apiscan - Azure/azure-sdk-for-net#43912
There was a problem hiding this comment.
lol... Ok I don't remember why I called it that. What do you think is a good name for this value?
There was a problem hiding this comment.
It wasn't an issue with my manual tests running the identity pipeline, and we have a fairly complex arm deployment.
There was a problem hiding this comment.
Also, at least in Identity's case, we only need the token in the -pre script, so that is well before the long part of the arm deployment. So perhaps we should document a best practice for deployments that need this, they should az login in a pre script.
There was a problem hiding this comment.
Even if they az login, the token used for login will still expire right? But maybe similar to what Wes said in the other comment thread we can possibly renew the access token in the deploy script if it becomes a problem for people.
There was a problem hiding this comment.
No, the OIDC token is exchanged for a regular access token, and that token would typically be good for at least an hour.
| - template: /eng/common/TestResources/setup-environments.yml | ||
|
|
||
| - ${{ if eq('true', parameters.UseFederatedAuth) }}: | ||
| - task: AzureCLI@2 |
There was a problem hiding this comment.
Do you know if there is a way to get similar values in the PS context? Also should we make this an opt-in as I'd hate for everyone to have to spend time logging into Az CLI and Az Powershell and not even end up needing these values.
There was a problem hiding this comment.
From what I could tell there is not. It's really unfortunate. Although maybe it's just the addSpnToEnvironment field that's specific to az cli and it's always there for az powershell? I can test.
I agree re: opt-in. I can add the parameter plumbing.
There was a problem hiding this comment.
Couldn't we call Get-AzAccessToken to get another token to use with az cli?
There was a problem hiding this comment.
Looks like the JWT is coming from a helper library from the service connection https://github.com/microsoft/azure-pipelines-tasks/blob/63938db07a732c279ace3a71b6da3321db636d1a/Tasks/AzurePowerShellV5/azurepowershell.ts#L85
There was a problem hiding this comment.
I can't find any of the inner source for that call :(
There was a problem hiding this comment.
You can definitely get the client id and tenant from https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/AzurePowerShellV5/InitializeAz.ps1#L121 the question is how do you get a token. I'm guessing we could call Get-AzAccessToken to get one as needed depending on the resource type.
|
Closing in favor of #8377 and |
5 participants
Some pre/post test resources scripts require az login to run setup commands (e.g. for identity). It seems useful to propagate the oidc token variable across the pipeline context regardless.
We could unset the variables after the pre/post script runs as well if we think we don't want it available everywhere.