search

vmware-tanzu / kubeapps

A web-based UI for deploying and managing applications in Kubernetes clusters
https://kubeapps.dev
Other
4.87k stars 702 forks source link

[Repository] add a request flag to control at which level credentials are redacted when fetching a repository #4867

Open dlaloue-vmware opened 2 years ago

dlaloue-vmware commented 2 years ago

When doing a GET on a given repository, plugins will ensure that credentials are marked as redacted. The current setting is to do full redaction, but some users may want to be able to view more useful data (e.g. see the username but not the password), or all data.

the proposal is to pass an option/flag to the GET request to indicate what level of redaction to apply, something like FULL | MIXED | NONE.

absoludity commented 2 years ago

Thanks, this will be helpful as a pattern in other areas too so that we don't send the actual secret data across the network unless explicitly requested to do so: for example, when fetching the resources for an installed app, currently we fetch the secrets in full (though they are not displayed unless the reveal/eye icon is clicked in the UX). This pattern will allow us to fetch redacted secrets initially (so the UX can display the secrets along with other resources as it does currently) and only fetch the actual secret data for a particular secret if the user explicitly requests it.

smerschjohann commented 2 years ago

It would be great if the values are hidden by default as well. In some cases, there are secrets/passwords in there as well, so it would be good to hide them behind a "show helm values" toggle or something.

antgamdia commented 2 years ago

Do you mean from the API response as well?

Currently, the repos API is doing it, so the UI (still in progress) shows the REDACTED value by default.

image

However, the packages API does send the secret values, although the UI hides them by default:

image

In case you mean also using a config-level flag to disable that feature (in the packages API, not the repos one), I think it's worth opening a separate issue for that. From memory, I don't know how easy it would be, but certainly worth discussing.

smerschjohann commented 2 years ago

Oh sorry, this is about the repos api. my bad, I meant those values:

grafik

dlaloue-vmware commented 1 year ago

before implementing a solution for a flag, i think we need to fix the following 2 bugs: issue #5746 issue #5747

The current UI does not provide a "view" UI, so the only time we would see the data is during an edit/update. This diminishes the need for such a flag as the UI would not be using it.

Finally, we would need to decide how we want to use this flag in the UI. For example, do we have an install flag that defines the default option, do we use a preference settings, or just a toggle on the view/update page (which would reload the page).