Hi everyone. I've bumped into an error I can't seem to resolve while trying to deploy on Azure via Service Principal. I would appreciate your help very much. Service principal is created and my stack yaml file has all the variables stated here in option 2: https://www.pulumi.com/registry/packages/azure-native/installation-configuration/ yet I keep getting the following error:

{
  "error": {
    "code": "AuthenticationFailed",
    "message": "Authentication failed. The 'Authorization' header is missing."
  }
}

Anyone with an idea what I might be doing wrong?

Do you have a bit of code (sanitized) you can share? And are you running locally or on a CI/CD system?

Did you get it working? I'm tackling this tomorrow and would love to know if any gotchas you had to work through.

Sorry @chilly-plastic-75584 I just managed to open this workspace and catch up on my slack correspondence, I've been working on something totally non-pulumi related in the last few days. Did you manage to connect properly?

@creamy-fall-88031 No, not yet. Not sure yet how I'll tackle this. If you want to jump on slack call let me know. where I am • It comes down to the types of azure devops service connections and how to use them. • I prefer to not use plugins, as I iterate locally and plug into CI. I am having to figure out with a very short time frame now how to pull out stuff that works and use plugins for the service connections instead (or figure out if it's even possible to retrieve the credentials in job using api in Mage). right now I wrap all my tasks in Mage (Go based task runner that replaces makefiles). • If I resort to using the azure devops plugin task for pulumi, it would only work for Azure RM type connectors. Only solutions I know of right now for Kubernetes type connectors • Figure out if service connection api actually lets code retrieve the credentials directly. I'm doubtful it would give the token or kubeconfig level info, but 🤷 I don't know till i look further • Figure out if azure devops Kuberenetes service connection kubectl "login" command actually generates a kubeconfig I could use in context ◦ And then change my job to stop looping over clusters and run I guess two duplicate stacks with just a different target cluster. In contrast, I had been doing what I wrote about in this post, looping through kubeconfig I had embedded.