proposal: Deep Links

[gdsoumya]

This is a proposal to add support for Deep Links in the Argo CD UI to integrate and provide easy access to third-party systems directly from the UI.

Checklist:

• Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this does not need to be in the release notes.
• The title of the PR states what changed and the related issues number (used for the release note).
• I've included "Closes [ISSUE #]" or "Fixes [ISSUE #]" in the description to automatically close the associated issue.
• I've updated both the CLI and UI to expose my feature, or I plan to submit a second PR with them.
• Does this PR require documentation updates?
• I've updated documentation as required by this PR.
• Optional. My organization is added to USERS.md.
• I have signed off all my commits as required by DCO
• I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
• My build is green (troubleshooting builds).

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 46.14%. Comparing base (30cab3b) to head (030e27a).
Report is 2647 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #10278      +/-   ##
==========================================
+ Coverage   46.10%   46.14%   +0.04%     
==========================================
  Files         228      228              
  Lines       27958    28004      +46     
==========================================
+ Hits        12889    12923      +34     
- Misses      13322    13327       +5     
- Partials     1747     1754       +7     

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

[crenshaw-dev]

I'd recommend using go text templates + sprig for templating. That would provide a massive feature set and a consistent experience with ApplicationSet go templates.

[crenshaw-dev]

go templates also provide a urlquery function which would allow admins to url-query-encode variables at link generation time instead of in the external data source.

[crenshaw-dev]

I'd consider go text templates + sprig for this as well. expr is good, but it's one more templating language we'd have to document and support.

[crenshaw-dev]

I'm curious about the use cases which would require a token in the URL. I'd worry that most use cases are neglectful of security best practices. The URL will live in plaintext in a lot of places including proxy logs and browser histories.

Assuming there are valid use cases which we should support, I'd recommend two restrictions:

1. the secret must have an allow-listing label like argoproj.io/can-be-used-in-deep-links to avoid granting accidental access to unrelated secrets in the argocd namespace
2. we always block access to the argo-cd secret, because it contains the server secret key and therefore access to admin tokens - we might always want to always block access to the contents of repo and cluster secrets

As an implementation detail, I'd recommend augmenting the go template with a getSecret(name, key) function so that we don't have to fetch all allow-listed secrets for every link construction. Responses should probably be cached for a given ListLinks call to avoid unnecessary k8s API calls.

Using go template + this function would allow dynamic secret/key names, e.g. https://mycompany.splunk.com?token={{getSecret "link-secret" (.app.spec.project + "-splunk")}}.

[jannfis]

I don't see any good reason for having secret data as part of the URL, because that obviously makes it not a secret anymore.

I'd prefer the implementation of this without having access to any secret.

[crenshaw-dev]

Yep! I think that if we substituted ConfigMaps for Secrets, some of my comments would still apply (blocking Argo CD ConfigMaps, allow-listing other ConfigMaps, providing a get function, and caching).

[gdsoumya]

Would it be better to have the initial version without any access to secrets/configmaps? If there appears to be a need for access to configmaps we can add it.

[crenshaw-dev]

Yep, I think no ConfigMaps or Secrets access would be a significantly easier starting point!

[crenshaw-dev]

We should consider how to handle templating errors, such as nil value references. Should we return all but the failed link and then log the error? Or should the API simply return an error code?

[gdsoumya]

I think we can either log error in the server and return only valid links or we can send error response when the frontend calls the endpoint.

[notfromstatefarm]

@crenshaw-dev basically covered everything I could think of. just some small typos I noticed.

[gdsoumya]

@crenshaw-dev @notfromstatefarm @jannfis as per the above discussion I have removed the secret access from the proposal.

[gdsoumya]

@crenshaw-dev I looked into sprig but couldn't find a compelling enough set of operators to evaluate conditionals as we need for the above proposal. expr on the other hand has better support for constructing complex conditionals in a more user friendly manner. I am not sure if sprig will be enough for our needs.

Also tagging @alexmt for his opinion on this.

[alexmt]

Agree, looks like sprig won't be helpful

[alexmt]

LGTM!