Proposal: Introduce a Parameter Set

[vdice]

This proposal is intended to cover the feature request in #878, while also adding a bit more functionality in the process.

#878 requests the ability to inject secrets into parameter values (similar to what is supported for a credential today). Here I propose accomplishing this via introducing a Parameter Set, very much like the existing Credential Set.

UX

• User can designate a parameter value as sourced from one of the following:

  • env var
  • command result
  • path
  • value
  • secret (if supported by plugin like the Azure plugin)

  Here would be an example for a parameter set file listing a parameter with a secret source:

  {
    "name": "mybunz",
    "created": "2019-11-27T15:50:58.194017952-07:00",
    "modified": "2019-11-27T15:50:58.194017952-07:00",
    "parameters": {
      "name": "myparam",
      "source": {
        "secret": "myparam"
      }
    }
  }

  We intend to re-use the same format as is currently used for a Credential Set (or more specifically, a CredentialStrategy).

  NOTE: in contrast to credentials, these (potentially secret) parameter values will be saved to the claim after a given action. Porter's current vision is to encrypt claims as a layer of protection.

• User can supply this parameter info at action runtime

  porter install --parameter-set myparam-set.json

High-level work items:

Separated into sections corresponding to separate PRs.

Addition of Parameter Set

• Introduce the concept of a Parameter Set, using the current Credential Set/CredentialStrategy as a model.

• Any parameters that require looking up their values via a source (one of the sources listed in the UX section above) must be listed in a Parameter Set.

• Parameters with raw value sources may be listed in a Parameter Set, but may also just be passed on the CLI via --param myparam=myparamvalue. (Or via both methods; see precedence rules mentioned below.)

• Add flag for all actions (porter install, etc.): -p/--parameter-set to supply the parameter set file.

  • Precedence for parameters: If a param is set via the CLI invocation (via --param), this value takes precedence over the same parameter value if listed in a supplied parameter set file. (Thought: or, should it simply boil down to the last supplied flag wins?)

Interactive Parameter Set Generation

• Interactive parameter set generation should be added. A separate PR may be preferable for this work, as it may involve refactoring for reusing the existing interactive credential set generation logic.

Replace/deprecate param file

• Proposal: Remove the existing --param-file functionality, to be replaced by the parameter set file.
  • Currently, --param-file allows only for a key=value listing for parameters
  • This same functionality will be retained in the parameter set file, as it has support for value source

Add Azure Plugin secret support

• Add support for deriving the secret source for applicable parameters in the azure plugin edit: this already is working!

Allow mixed sources when at least one is a secret

• Currently, Porter only allows all credential sources be of type secret (aligning with the use of the Azure plugin) or none
• The same would apply for the proposed/forthcoming parameter sources, currently. The work to enable mixed sources is encapsulated/tracked in Always have the filesystem plugin available #1050

[carolynvs]

💯 Let's do this!

[vdice]

All PRs associated with this epic have been merged; closing.