https://pulumi.com logo
Join Slack
Powered by
Hi there. Looking to setup Azure OIDC using ESC. ...
# azure
w
Hi there. Looking to setup Azure OIDC using ESC. Made a small project to create the credential and save it in esc. That project successfully ups, but when I add the resulting environment into a consuming Pulumi project and run an up there I get the following error: 
AADSTS70025: The client '04b07795-8ddb-461a-bbee-02f9e1bf7b46'(Microsoft Azure CLI) has no configured federated identity credentials.
Which feels like either the login isn't getting loaded, or maybe I'm missing some baseline config for Az CLI in general? I've seen similar errors in docs and issues but they all seem to be related to the audience in the configured ESC and not the 1st party az cli. This seems like I'm overriding or not correctly consuming the ESC environment entirely but I can't see how. Anybody seen anything like this before?
The resulting ESC is created, looks correct to me (has minor drift from code due to my manual troubleshooting), and does show it's being pulled in my the expected project.
m
OIDC also requires some one-time setup in Entra, have you done that? I’m not sure how to do it for the Azure CLI, though, I’ve only done it for service principals I own.
w
I think this is part of what my pulumi code is provisioning. Creating the app and the credential for ESC. Here's there result:
My expectation is that the pulumi up uses the ESC auth and generates the env variables for any Az CLI needs. I would expect that the auth is actually already done so I'm not clear on where the az cli even comes into play to get into the error response. Previews work without issue, so it would appear that least some part of the auth is happening as I expect
m
Hi Zachary, I took a look at your linked project and couldn’t see an obvious issue at first glance, but I spotted one difference to the Azure ESC docs, which is 
ARM_OIDC_REQUEST_URL
. I think it shouldn’t be set in this scenario (details about it here). Not sure if it makes a difference or if it’s ignored, though.
w
Nah that was something I added in troubleshooting. I took it out. Also tried going with a pure config approach since I'm not purposefully trying to use az cli for anything and the result is the same.
That got me back to basics and I figured it out. The bug is in my ESC provisioning code. In trying to make this fully scripted I'm populating the ESC variables based on current context (which since it's foundational is the az cli) I need to revise and update to use the clientId from the app I just created vs current context. That's why it keeps trying to sign on with az cli lol.
m
Ah! Glad you were able to figure it out! The Azure provider falls through to az cli auth when no other method is fully configured (missing client id in this case). It’s convenient for local development but also confusing for troubleshooting. Maybe we should have a flag to turn this fall-through off.
w
That is kind of you to consider, but honestly it was just bad code on my part. Got a little hasty with some AI copy/paste instead of thinking through lining up the context of the thing I was creating with what I actually wanted to login. I might have found a quirk or bug on the pulumi end though. Not sure. Here's my new ESC: https://github.com/zacdirect/core-infrastructure/blob/main/infra/index.ts#L81 I ditched the ARM environment variables since I don't intend to use this environment for anything but Pulumi programs. Went with native Pulumi config entries instead. I have working previews and ups 🎉. https://github.com/zacdirect/zac.direct/actions/runs/12443364094/job/34742473658
The bug(?) is specific to the --refresh command. It looks to me like for whatever reason, the OIDC token is actually being generated outside of the valid window. Here's the output in the console:
Copy code
Error: Preview failed: ClientAssertionCredential authentication failed.
    POST <https://login.microsoftonline.com/bd7bdc93-155e-4397-b497-dc3986efaeb0/oauth2/v2.0/token>
    --------------------------------------------------------------------------------
    RESPONSE 401: 401 Unauthorized
    --------------------------------------------------------------------------------
    {
      "error": "invalid_client",
      "error_description": "AADSTS700024: Client assertion is not within its valid time range. Current time: 2024-12-21T20:43:03.5148190Z, assertion valid from 2024-12-21T18:25:48.0000000Z, expiry time of assertion 2024-12-21T19:25:48.0000000Z. Review the documentation at <https://learn.microsoft.com/entra/identity-platform/certificate-credentials> . Trace ID: b28bcc3c-6b53-42f3-bc69-69d603d33200 Correlation ID: a5fb163a-ebfe-4dd9-8574-9aeb221dc7ee Timestamp: 2024-12-21 20:43:03Z",
      "error_codes": [
        700024
      ],
      "timestamp": "2024-12-21 20:43:03Z",
      "trace_id": "b28bcc3c-6b53-42f3-bc69-69d603d33200",
      "correlation_id": "a5fb163a-ebfe-4dd9-8574-9aeb221dc7ee",
      "error_uri": "<https://login.microsoftonline.com/error?code=700024>"
    }
    --------------------------------------------------------------------------------
I tried changing my system time to UTC to see if maybe it was a daylight savings timezone math thing or something, but doesn't make a difference. Ups and Previews work fine for me locally so it doesn't seem like it's something specific to my machine. I haven't tried sending a --refresh to the github actions to reproduce on the runners.
@melodic-tomato-39005 a short post holiday bump to review that time/token error. Let me know if I should open a GitHub issue.
m
Sorry for the holidays-induced delay. Yes, please open an issue on https://github.com/pulumi/esc/issues.
18 Views
Open in Slack
PreviousNext
Powered by