feat request: use secret value from provider config's secret ref to authorize requests

[tenstad]

What problem are you facing?

Unable to use the ProviderConfig's Credentials.SecretRef as authorization for Request requests.

Appears it should be supported, based on this comment:

provider-http/internal/controller/request/request.go

Line 101 in 0aa30d5

// 3. Getting the credentials specified by the ProviderConfig.

How could Crossplane help solve your problem?

Implement fetching the ProviderConfig's Credentials.SecretRef Secret and using that value to authorize Request requests.

Similarly to how it's implemented in other providers, such as https://github.com/crossplane-contrib/provider-gitlab/blob/31c53bce00c2e9b809716425c530bdc5e6fd4947/pkg/clients/gitlab.go#L109

Could add the header Authorization: Bearer <token from ProviderConfig's Credentials specification> if Credentials is specified, or extend the ProviderConfig with some additional fields for how the secret should be used in requests.

[arielsepton]

Hi 👋 @tenstad

The comment you referenced should indeed be removed, as it can be misleading.
While storing credentials in ProviderConfig works for most providers, it’s not the ideal approach for provider-http. In this case, each Request can manage different resources with unique sensitive data, making it too dynamic for ProviderConfigs.

Instead, using secrets within each Request offers better flexibility and control over credential usage.

You can inject data from secrets using the following syntax, which works for both body and headers:

headers:
  Authorization:
    - "Basic {{ secret-name:secret-namespace:secret-key }}"

This method should help you manage your secrets effectively. If you have any further questions or need further assistance, feel free to reach out. Let me know how it works for you!

[tenstad]

Thanks for the quick reply! Yeah that definitely works, and is what we're now using. Just seemed like a single provider config would be even cleaner when having multiple Request resources using the same endpoint and auth token.

But we can for sure just remove the misleading comment and call it a day! :)

[tenstad]

Follow up question; Is the Credentials of a Crossplane provider something that comes by default (seems to be the same in many providers), or is it specifically added? If it could be removed from the http ProviderConfig, that could also avoid confusion, as it's not used for anything right?