feat: support multi account Datadog metrics provider

[ariadnarouco]

Summary

This pull adds ability to use namespaced credentials for Datadog metrics provider.

Background

Our use case involves an Argo Rollout that operates across multiple namespaces, each managed by tenants with distinct Datadog accounts. As a result, multiple credentials are needed to integrate seamlessly with Datadog.

Implementation

This setup will allow users to use different credentials than the one setup as default, which is a secret named "datadog" deployed in the same namespaces as the rollouts controller [refer to doc].

This way the users can manage their datadog credentials with the name they want and in their own namespace.

The process suggested within this PR for retrieving Datadog credentials is as follows:
1. If a secretRef is defined in the AnalysisTemplate: Argo Rollouts will search for the secret with the specified name in the namespace where the template resides.
2. If the secret is not found in the specified namespace: Argo Rollouts will then check the environment variables.
3. If the credentials are not found in environment variables: Argo Rollouts will look for a secret named "Datadog" in the namespace where Argo Rollouts itself is deployed.

Notes:
Based on the code, to have more than one set of credentials is not possible. I also created a question for this which remains unanswered

Checklist:

• Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this is a chore.
• The title of the PR is (a) conventional with a list of types and scopes found here, (b) states what changed, and (c) suffixes the related issues number. E.g. "fix(controller): Updates such and such. Fixes #1234".
• I've signed my commits with DCO
• I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
• My builds are green. Try syncing with master if they are not.
• My organization is added to USERS.md.

[codecov]

Codecov Report

Attention: Patch coverage is 93.65079% with 4 lines in your changes missing coverage. Please review.

Project coverage is 83.89%. Comparing base (23e186e) to head (52dc2e6).
Report is 56 commits behind head on master.

Files with missing lines	Patch %	Lines
metricproviders/datadog/datadog.go	90.90%	1 Missing and 1 partial ⚠️
metricproviders/metricproviders.go	50.00%	1 Missing ⚠️
pkg/kubectl-argo-rollouts/info/pod_info.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3787      +/-   ##
==========================================
+ Coverage   83.87%   83.89%   +0.02%     
==========================================
  Files         162      163       +1     
  Lines       18524    18548      +24     
==========================================
+ Hits        15537    15561      +24     
+ Misses       2119     2117       -2     
- Partials      868      870       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

Published E2E Test Results

  4 files    4 suites   3h 13m 39s ⏱️
113 tests 104 ✅  7 💤 2 ❌
458 runs  424 ✅ 28 💤 6 ❌

For more details on these failures, see this check.

Results for commit 52dc2e6.

♻️ This comment has been updated with latest results.

[github-actions]

Published Unit Test Results

2 270 tests   2 270 ✅  2m 58s ⏱️
  128 suites      0 💤
    1 files        0 ❌

Results for commit 52dc2e6.

♻️ This comment has been updated with latest results.

[zachaller]

I knid of think we just drop this field namespaced, i think the presence of a secretRef just means look up secret in the namespace of the AnalysisTemplate. At a later date we can then add a namespace field to secretRef if we want to support cross namespace lookups. Thoughts?

[tjamet]

Hi @zachaller
Thanks for the review and the input.

When implementing this feature we discussed the different use-cases and we thought about the following ones:

1. As an argo rollout owner, you also own the integration with a single DataDog account.
2. As an argo rollout owner, you also own the integration with several DataDog accounts
3. As an argo rollout owner, you only own argo rollout and your users own the DataDog ones.

The first case is the currently supported case.

The second case corresponds to namespaced: false, and let the "rollouts administrator" to manage different DataDog integrations by providing well-known secret names to the namespace users.

The third one corresponds to namespaced: true, where namespace users were completely autonomous to manage the DataDog account integration.

We did consciously exclude the option to have a configurable namespace string to maximise security.
Indeed, we want the owners of, say, namespace-a AnalysisTemplates and DataDog integrations to have confidence that they will control who can access their metrics.

Having a configurable free text namespace would allow users of any other namespace to indirectly access DataDog metrics, which would then break the namespace principles.

WDYT?

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.8% Duplication on New Code

See analysis details on SonarCloud