Panics when running azidentity.(*ClientSecretCredential).GetToken

[jcmanzo]

Bug Report

• import path of package in question:

  github.com/Azure/azure-sdk-for-go/sdk/azidentity

• SDK version e.g. master, latest, 18.1.0:

  github.com/Azure/azure-sdk-for-go/sdk/azcore v1.11.1
  github.com/Azure/azure-sdk-for-go/sdk/azidentity v1.5.2

• output of go version:

  go version go1.21.8 linux/amd64

• What happened? While authenticating with Azure using a client secret, I observed panics due to: panic: runtime error: invalid memory address or nil pointer dereference. This error was observed only on certain k8s hosts. It looks the error originates in from this location where the c.client or c.client.azClient are possibly nil at runtime. Below is a partial excerpt of the stack traces I encountered:

  panic: runtime error: invalid memory address or nil pointer dereference
  runtime.gopanic
  	/usr/local/go/src/runtime/panic.go:770
  runtime.panicmem
  	/usr/local/go/src/runtime/panic.go:261
  runtime.sigpanic
  	/usr/local/go/src/runtime/signal_unix.go:881
  github.com/foo/bar.com/Azure/azure-sdk-for-go/sdk/azidentity.(*ClientSecretCredential).GetToken
  	/go/src/github.com/foo/bar.com/github.com/foo/bar/app/vendor/github.com/foo/bar.com/Azure/azure-sdk-for-go/sdk/azidentity/client_secret_credential.go:69
  github.com/foo/bar.com/Azure/azure-sdk-for-go/sdk/azcore/runtime.acquire
  	/go/src/github.com/foo/bar.com/github.com/foo/bar/app/vendor/github.com/foo/bar.com/Azure/azure-sdk-for-go/sdk/azcore/runtime/policy_bearer_token.go:39
  github.com/foo/bar.com/Azure/azure-sdk-for-go/sdk/internal/temporal.(*Resource[...]).Get
  	/go/src/github.com/foo/bar.com/github.com/foo/bar/app/vendor/github.com/foo/bar.com/Azure/azure-sdk-for-go/sdk/internal/temporal/resource.go:95
  github.com/foo/bar.com/Azure/azure-sdk-for-go/sdk/azcore/runtime.(*BearerTokenPolicy).Do.(*BearerTokenPolicy).authenticateAndAuthorize.func1
  	/go/src/github.com/foo/bar.com/github.com/foo/bar/app/vendor/github.com/foo/bar.com/Azure/azure-sdk-for-go/sdk/azcore/runtime/policy_bearer_token.go:67
  github.com/foo/bar.com/Azure/azure-sdk-for-go/sdk/storage/azblob/internal/shared.(*storageAuthorizer).onRequest
  	/go/src/github.com/foo/bar.com/github.com/foo/bar/app/vendor/github.com/foo/bar.com/Azure/azure-sdk-for-go/sdk/storage/azblob/internal/shared/challenge_policy.go:34
  

• What did you expect or want to happen?

  I expected neither of the clients to be nil.

• How can we reproduce it?

  I'm not sure myself. I don't always happen, at least not initially.

• Anything we should know about your environment.

  The code runs in a k8s pod

[github-actions]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[chlowell]

The context is

azure-sdk-for-go/sdk/azidentity/client_secret_credential.go

Lines 67 to 69 in 2a321f6

	func (c *ClientSecretCredential) GetToken(ctx context.Context, opts policy.TokenRequestOptions) (azcore.AccessToken, error) {
	var err error
	ctx, endSpan := runtime.StartSpan(ctx, credNameSecret+"."+traceOpGetToken, c.client.azClient.Tracer(), nil)

Assuming your app gets the credential from NewClientSecretCredential, I think the nil pointer here must be c *ClientSecretCredential because both c.client and c.client.azClient are assigned once only, during construction, and all the constructors involved return a nil pointer if and only if they also return a non-nil error. Another way to put it is that when NewClientSecretCredential returns an error, it always returns a nil *ClientSecretCredential. You would see this panic if your app passed that pointer to a client despite the error. Is there a case in which it could do that?

[github-actions]

Hi @jcmanzo. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[jcmanzo]

Thank you @chlowell I was just about to come here and close the issue since I found the problem to be on my side with a misconfigured environment 😅 Apologies for waisting your time on this and thank you for looking into it! I'll go ahead and close this now.