Instead of having CredentialStrategy specific to retrieving credentials from a host, with hard-coded fields for command/path/env/value, live up to the "strategy" aspect and allow for other mechanisms of finding the credential value.
I have moved the resolution of credential values to a new subpackage secrets/host which implements a new interface secrets.Store. This allows for clients, like Porter, to use plugins to retrieve secret values from external systems such as Vault while still using CredentialSets.
One breaking change is that only a single source can be specified now without fallbacks. Since this functionality was very limited to begin with, you could only specify one env, and then could only fallback to a value, and only in that order, I'm unsure if we can preserve it. If we do, it would require a breaking change to the format of the CredentialSet file structure.
Instead of having CredentialStrategy specific to retrieving credentials from a host, with hard-coded fields for command/path/env/value, live up to the "strategy" aspect and allow for other mechanisms of finding the credential value.
I have moved the resolution of credential values to a new subpackage secrets/host which implements a new interface secrets.Store. This allows for clients, like Porter, to use plugins to retrieve secret values from external systems such as Vault while still using CredentialSets.
One breaking change is that only a single source can be specified now without fallbacks. Since this functionality was very limited to begin with, you could only specify one env, and then could only fallback to a value, and only in that order, I'm unsure if we can preserve it. If we do, it would require a breaking change to the format of the CredentialSet file structure.
Part of #172