Confirm that `env_vars` contains no keys before writing pipelines

When creating piplines, it is important to strip out any access keys or secret from the env_vars data.

 "pipelines": [
    {
      "id": "primary",
      "nodes": [
        {
          "id": "...",
          "type": "execution_node",
          "op": "execute-notebook-node",
          "app_data": {
            "component_parameters": {
              "filename": "notebooks/notebook_filename.ipynb",
              "outputs": [],
              "env_vars": [ NO KEYS HERE ]

[kevin-bates]

Yeah, I agree about the confusion with regular envs, but given Patrick’s use case he raised in the community meeting regarding the Local (“JupyterLab”) use case, I think we should leave it alone and was wondering if the following might be worth a look.

Clearly, the local runtime doesn’t know about this three-part “Kubernetes Secret” stuff, nor do I think we should make or try to massage 3-parts into 2-part (env name and value) that the local runtime would consume. Instead, if we let envs just flow (from pipeline defaults to node envs) AND let the 3-part “Kubernetes Secret” env replace normal envs, then, assuming we can detect the target runtime at the time of “default propagation”, NOT propagate “Kubernetes Secrets” when its a local runtime, else perform the replacement. By “replacement”, I mean to remove the duplicated env from the “envs list” and add it to the “secrets list” (where the latter uses the necessary operations for conveying secrets information).

This will still be confusing for users to see their k8s secret env listed in their “detected” envs, but perhaps we can name and/or document the “Kubernetes Secrets” header (and/or help text) as “Kubernetes Env Secrets” or somehow convey this too is an env and let the user know these values will replace the regular envs where applicable.

We should also note that for things like DB credentials, each of these “secret envs” will very likely have a “normal env” that denotes the user name corresponding to the credential. So in that respect, having the pair in the env list won’t be too much of a surprise. We just need to let the user know from where (and when) the actual value corresponding to the “secret env” is derived.

[kiersten-stokes]

What would be the purpose of the button? Elyra does not have any Kubernetes connectivity and wouldn’t be able to auto-detect or validate secrets.

It would behave just like the env vars one currently does. Basically, parse the notebook or script for certain uses (e.g. os.getenv) and populate the name of the env var only - the secret name and key still have to be entered manually (like the value does for ‘vanilla’ env vars now). Right now, these cases will appear in the ‘Environment Variables’ property area but not the ‘Kubernetes Secrets’ area, which could be a potential cause for confusion.