`meltano config set` is unsafe if setting or `setting.kind` is missing

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/2768

Originally created by @aaronsteers on 2021-05-26 19:22:54

---

We should considering altering how Meltano behaves when kind is missing from specific settings. The default behavior when kind is not know would be to treat the value as insensitive. We may instead want to prompt the user to specify the kind and/or the sensitivity level of an otherwise undeclared setting value.

For instance, prompting a user to specify it if configuring with meltano config <plugin> set <setting> <value>. Especially for custom taps (including many taps discovered from the hub), the kind` and therefor the sensitivity level is not known, and we should probably not automatically default to that value not being a secret.

This could also serve as a catch for typos or accidentally-incorrect setting names: rather than going through the wizard’s steps and storing under the provided setting name, the user may realize they’ve input an incorrect setting name and abort, then retry the process with the correct setting name.

Here’s an example invocation. The result of the below (using an unknown/incorrect setting name) is that the setting gets stored in yaml as clear text:

% poetry run meltano config target-jsonl set myset thisisnotasecret
Loader 'target-jsonl' setting 'myset' was set in `meltano.yml`: 'thisisnotasecret'

Proposal

• We should at minimum warn the user that kind is missing.
• If an interactive prompt is available, we can ask the user interactively what the proper kind value is before serializing the new setting value.
  • The setting’s kind entry would be serialized to yaml as well.
• We can add a --quiet flag optionally, to mute the new behavior and treat the setting as kind: string if not set. (Same as current status quo.)

Proposal (Updated 2022-04-16)

• Combining with #3227:
  • If --interactive is used, we can also prompt for setting config (including kind) at the same time as prompting for the new value.
  • If --interactive is not set, we can fail with a prompt to use --interactive or we can automatically switch to --interactive mode if kind is missing or the setting is not yet defined.

Update (2022-06-03)

⚠️ Now that we’re enabling adding directly from the hub, this is now a very unsafe default behavior and a pretty high risk for user impact. Users new to Meltano are now much more likely to end up storing sensitive data in yaml. An alternate - and simpler - path to at least mitigate the impact is to prompt the user:

Warning: setting definition for ‘my_secret_config_value’ not found. If this is unexpected, please double check the spelling and try again. (Ctrl+C to cancel.)

To add this as a new plugin setting, please indicate if this is a sensitive value. Sensitive values are stored in an appropriate storage location. For more information, see: https://docs.meltano.com/reference/command-line-interface#config

Is the value for ‘my_secret_config_value’ a sensitive field? [Y/n] > Y

Confirmed. The provided value for ‘my_secret_config_value’ is sensitive and will not be stored in yaml.

I think the ‘better’ option is still to collect the setting ‘kind’ and optionally ‘description’ from the user, but that requires a larger scope due to having to write new code to collect and then write back new settings definitions.

The ‘is this a sensitive value?’ prompt is faster to implement and still mitigates the high risk security issue here.

[DouweM]

@edgarrmondragon Thanks for confirming. Created a new issue: https://github.com/meltano/meltano/issues/6029.

@aaronsteers Ah, maybe! I’ll add that to my new issue.

[aaronsteers]

FYI - adjacent code for this fix was recently touched here:

• https://github.com/meltano/meltano/pull/6938