Use authorisation if present, regardless of environment

[lucasfcosta]

Summary

This PR allows Kibana to use the Authorization keys in its configuration file regardless of the environment in which its running.

Before this change you wouldn't be able to use Basic Auth in Elastic Cloud because it would be ignored due to this extra check.

Now, if the username and password settings exist, we do use them. That should be fine because it shouldn't be possible to set those keys unless doing tests on a particular region which allows for those keys to be set. Furthermore, one does need to have the credentials anyway.

How to test this PR

Locally

1. Add valid username and password fields to your Kibana configs (xpack.uptime.service.username and xpack.uptime.service.password) and remove TLS settings.
2. Try to access the service and create monitors

Once it goes to cloud (POST FF)

1. Ensure you've deployed a SNAPSHOT version to Kibana to a CFT region
2. Edit Kibana configs, add username and password keys (xpack.uptime.service.usernameandxpack.uptime.service.password) and use the service's dev manifest as the value for xpack.uptime.service.manifestUrl`.
3. Try to access the service and create monitors in dev. They should all work okay.
4. Remove the username and password keys, but keep the manifest URL. Everything should still work (monitors can be created and display results).
5. Remove the manifest URL too and connect directly to the prod. version of the service (without username and password). Everything should still work (monitors can be created and display results).

Checklist

Delete any items that are not applicable to this PR.

• If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list — the configurations we want to use are not in that list

Risk Matrix

• Please do double check whether there's anything I'm missing here which could make this a problem. I couldn't find any reasons not to do this change, especially considering valid credentials would be needed anyway.

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

Pinging @elastic/uptime (Team:uptime)

[dominiqueclarke]

@elasticmachine merge upstream`

[dominiqueclarke]

@elasticmachine merge upstream

[dominiqueclarke]

LGTM.

Works great on dev and qa. Continues not to work on prod and staging, as they are prohibited from using basic auth on the service side.

[dominiqueclarke]

@elasticmachine merge upstream

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 7589da2

Metrics [docs]

✅ unchanged

History

• 💛 Build #66171 was flaky e138d5a
• 💚 Build #65095 succeeded cb7104b

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[awahab07]

Post FF Testing

• On a prod cluster, with the following Kibana config:

  xpack.uptime.service.manifestUrl: <dev-service-url>
  xpack.uptime.service.username: <correct-ussername>
  xpack.uptime.service.password: <correct-password>
  xpack.uptime.service.showExperimentalLocations: true

  it works, whereas with the following config (when credentials are incorrect):

  xpack.uptime.service.manifestUrl: <dev-service-url>
  xpack.uptime.service.username: <correct-ussername>
  xpack.uptime.service.password: <incorrect-password>
  xpack.uptime.service.showExperimentalLocations: true

  it fails.

• Only providing a manifest URL also works i.e.

  xpack.uptime.service.manifestUrl: <dev-service-url>
  xpack.uptime.service.showExperimentalLocations: true

Thus, the PR changes work as expected.