https://pulumi.com logo
Join Slack
Powered by
Using ESC and OIDC to Azure. Things stopped workin...
# azure
b
Using ESC and OIDC to Azure. Things stopped working this morning: Trying to deploy a stack to Azure cloud, I'm getting the following error "AADSTS700024: Client assertion is not within its valid time range". Has anyone seen this before?
Looking at the generated OIDC token the claims look fine and are updated on each attempt but the rejection message from Azure indicates that the token expired earlier today (iat claim is the time which I think was my last successful deploy).
I'm dead in the water here. I've tried passing turning on verbose logging (level 11) but it doesn't seem to affect the output at all. It appears that ESC is submitting an expired/cached token to authenticate with Azure. Does anybody have ideas on how to debug this?
s
I've seen this with pulumi destroys that are not performed with 
--run-program
, is that possibly your scenario?
➕ 1
The provider by default is stored in state, which is refreshed for normal up, but not destroys. So in the case of a destroy, even if the pipeline handshakes and gets a new token the provider in state will use the old/previously saved credential.
I've also seen this kind of thing on particularly long-running ups that overrun the time the token is valid for. Could either of these be a factor in what's going on for you?
b
definitely not a long-running up. not refreshing the provider at time of destroy seems like what's happening, and very much seems like a problem/bug - especially since the token is only good for 1 hour.
i did stumble upon a workaround - by doing a pulumi up before a refresh/destroy I could then execute a destroy.
seems like behavior has changed recently. I've been regularly making use of refresh and destroy outside of the hour-long window. Now I'm having to use my workaround (which is rather awkward) whenever i walk away for an hour.
s
The behavior may have changed but I'm not sure if it's on the Pulumi side or not. Potentially a default session length got tighter somewhere? In any case, you're right to call this out as a pain point. There are improvements to the engine: https://www.pulumi.com/blog/improved-refresh-destroy-experience/ The 
--run-program
flag essentially forces the providers to refresh before a destroy, so you don't have to run an up then destroy to get a new token. This is planned to be a default at some future milestone though I don't know if it's expressly roadmapped yet. It's a significant change to how the Pulumi engine works and calls for a conservative rollout.
b
ill give it a shot next time the error pops up
👍 1
9 Views
Open in Slack
PreviousNext
Powered by