Introduce concept of "secrets" to tmt

[happz]

Some environment variables might be sensitive, and tmt dumping them in its log and other files might cause troubles, leaking credentials, and spreading headaches among users. Would it be possible to tag some envvars as sensitive, and replace them in the debug log and command like * export with asterisks, for example?

[thrix]

@janhavlin can you share please here some practices that could be maybe used? Like:

https://python-secret-type.readthedocs.io/en/latest/

[happz]

@janhavlin can you share please here some practices that could be maybe used? Like:

https://python-secret-type.readthedocs.io/en/latest/

Nice, I was thinking about something like this, and it demonstrates the actual usage patterns, cool.

I'll try to finish the transition from dict[str, str] to a full-fledged custom dictionary class, similar to what we have for FmfContext, which I saw always as a good idea on its own to better support logging, changes, and conversions from files or CLI.

Having that, we can easily add custom string-like type for secrets which would raise errors when improperly. E.g. Command.run() using a special method to inject it into the command's environment, str() emitting *****, and so on. I'm not sure whether we'd need generic in tmt, envvars are always strings, but maybe there's a use case.

And if I'm not mistaken, pyright should be able to validate NewType usage, so this might be relatively cheap implementation, built mostly with Python's typing annotations.

[happz]

A custom class to hold an environment has been proposed in https://github.com/teemtee/tmt/pull/2612. Once reviewed, we can add a subclass to hold secrets or implement custom type for values that are to be secret.

[happz]

A summary from the hacking session:

• secrets for tests
  • these would be passed to test environments, shall be redacted in tmt logs
  • tmt run will gain options mimicking -e/--environment/--environment-file options. These options would provide key & value pairs representing test secrets.
  • tmt run will gain the option to list envvar names. These would be extracted from tmt environment and added to the collection of test secrets.
  • test and plan specification would gain keys for the same purpose, i.e. listing envvar names that should be extracted from tmt environment and added among secrets.
  • test and plan specification would gain keys to control which secrets would be exposed to which test.
• secrets for tmt (various tokens, credentials, passed to plugins)
  • these we do not wish to log openly, most likely they would populate step data fields (RP credentials and similar)
  • tmt will gain option to list envvar names - these would be extracted from tmt environment, and added to the collection of tmt secrets

[lukaszachy]

• secrets for tmt (various tokens, credentials, passed to plugins)

Could tmt have the ability to read the secrets for a file as well? (eg. --secret-file) Seems that some environments (e.g. https://redhat-appstudio.github.io/docs.appstudio.io/Documentation/main/how-to-guides/configuring-builds/proc_creating-secrets-for-your-builds/) secrets are provided via r/o file

[happz]

• secrets for tmt (various tokens, credentials, passed to plugins)

Could tmt have the ability to read the secrets for a file as well? (eg. --secret-file) Seems that some environments (e.g. https://redhat-appstudio.github.io/docs.appstudio.io/Documentation/main/how-to-guides/configuring-builds/proc_creating-secrets-for-your-builds/) secrets are provided via r/o file

If you mean secrets for tmt itself, then yes, although it's not clear from the list above, mostly because there is no corresponding option for envvars. One simply runs TMT_FOO=1 tmt ....

[happz]

@kkaarreell IIRC, you proposed there should be keys that would allow developers to expose only some of the secrets to a particular test, correct? For example, something along the lines of the following, very artificial example:

/foo:
  test: /bin/true

  # Regular environment variables:
  environment:
    FOO: ...

  # Extract these from tmt environment and treat them as secrets:
  secret-environment:
    - BAR

  # Counteracts `secret-environment` above: yes, BAR is extracted
  # from tmt environment and made a secret internally, but it's not
  # allowed to be exposed to the test because `expose-secrets` does
  # not allow it:
  expose-secrets:
    - BAZ

# Tests would run with BAZ set, BAR would remain invisible to them:
$ BAR=... BAZ=... tmt run ...

[kkaarreell]

Right, but TBH, not sure if it Is not overengineering it. GitLab does it for actions.

[happz]

It can certainly be introduced later, first version can simply expose all secrets to all tests and plans, as it is done with envvars today.