[extensions/azureauth] Retrieve scope from Host/URL.Host instead of Header for client authentication

[ms-hujia]

Description

For client request, there won't be a Host entry in Header. The scope should be retrieved from Host or URL.Host.

Link to tracking issue

Fixes #40032.

Testing

Updated the existing test case.

Documentation

N/A.

[constanca-m]

This is not correct. This host is meant to be a Host header. If you look at the README file, the request is meant to have headers, of which one of them is Host (see azure documentation).

This host will then be used to define the scope of the authentication request.

[constanca-m]

For example, set the Host of your request to management.azure.com. Will your use case work now? Which azure service are you using? The host might change.

[ms-hujia]

This is not correct. This host is meant to be a Host header. If you look at the README file, the request is meant to have headers, of which one of them is Host (see azure documentation).

This host will then be used to define the scope of the authentication request.

No, it won't be added. I can give you a minimum example to reproduce the issue if you don't have a chance to verify this.

[ms-hujia]

For example, set the Host of your request to management.azure.com. Will your use case work now? Which azure service are you using? The host might change.

Not all exporters give user the opportunity to override the HTTP header.

[constanca-m]

can give you a minimum example to reproduce the issue if you don't have a chance to verify this.

I would that, if you could.

I'm very busy this week, so I am trying not to respond slow to this issue.

[ms-hujia]

No worries, take your time since I've already unblocked myself.

[constanca-m]

@ms-hujia Can you share with me the config.yaml you are using for the collector? So I can have a reference and test it Sorry, I see you have put the comment in the issue

[constanca-m]

Thank you for your example @ms-hujia. I think I understand the issue now.

I am not sure how to resolve this in an idiomatic way. I believe requests for authentication on azure should be in sync with what the user expects - so based on azure documentation, the host should be on the header.

But it is true that if you use azureauth, then you cannot set the headers of the request - there is headers_setter extension, but since you can only use 1 authenticator, you could not use it at the same time as azureauth.

I believe the best way would be to use a new component that could set the header Host, and then use azureauth right after. So, what headers_transform extension could possible do (this is not an approved component, it is just something we use internally at the company I work at, Elastic, to handle this exact same issue).

If we set the host the way this PR shows, then we are expecting the request to be hosted on azure, and I am not sure if that is always right. What do you think?

[ms-hujia]

For Golang's HTTP client implementation, the Host entry will be added to the HTTP header server received, even if it's not set in the Header field of http.Request. This is done in the base http.RoundTripper. Generally, user don't need to pass those basic HTTP headers explicitly, e.g., another example is Content-Length.

Going back to the issue itself, the issue happens due to the Host entry is checked before base http.RoundTripper add it to request.

[constanca-m]

@ms-hujia Could you add a changelog please? So we can start working on getting this merged :)

[ms-hujia]

@ms-hujia Could you add a changelog please? So we can start working on getting this merged :)

I've added the changelog and rebased my branch.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.