Store sensitive data in a secret store, not Porter's database

[carolynvs]

Claims store sensitive data (parameters) and should not be stored in the database. We should come up with a way to store sensitive data from claims and other tables in the user's secret store, then when we retrieve the data, look up the sensitive values if needed to get a full document.

For some calls, maybe we don't need the data, we are just listing claims, but others like retrieving outputs and showing the values, will need to get the real values from the secret store.

[VinozzZ]

The current plan is to allow users to specify a destination for porter output through the same secrete plugin they use for resolving secrete values that needed to run bundle.
It would look something like this
`
default-secrets = "mysecrets"

[[secrets]]
name = "mysecrets"
plugin = "azure.keyvault"

[secrets.config]
input-vault = "myinputvault"
output-vault = "myoutputvault"
`

After checking the limitations on Azure key vault and Hashicorp vault, it looks like the upper limit for number of keys stored in a vault is only affected by the underlying storage space. However, Hashicorp does have a per object size limit. Therefore, I plan to store each installation output separately using installation id or run id.

[carolynvs]

This sounds like a good plan, looking forward to your PR! 🚀

[carolynvs]

Here's a list of additional content we need to properly document this feature (and yeah it's backfilling missing content we have always been missing!) It doesn't have to all be done in a single PR and we can work on some of this together.

• Task document under Tasks -> End Users -> Create a Porter Config File. It should explain how to create a config file, what the defaults are (e.g. the host plugin for secrets, and the mongodb-docker plugin for storage). It should then explain how to configure the filesystem plugin for secrets, and point out which plugins are suitable for production for both storage and secrets.
• Quickstart document under Get Started -> QuickStarts -> Configuration. It should explain the default plugins, how to configure porter for trying it out, link to the production plugins. Link to the Config file doc page in the Next Steps.
• Blog post announcing how we store secrets in v1 and walking them through how to configure both the filesytem plugin, and link to the docs for how to configure a production plugin.
• Update the configuration page with the new defaults and a link to configure secrets and storage plugins.

[VinozzZ]

I will start work on the Quickstart document

[VinozzZ]

Started on the Task document

[VinozzZ]

After looking at the example output from azure keyvault, we probably should add an dash in the secret key to make it more friendly to users to see

[carolynvs]

Is this okay to close?