Introduce secrets CI config interpolation paradigm

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Problem

In #395639 (closed) we describe a problem of using secrets with the recently implement string interpolation mechanism for CI templates / CI components. To pass secrets safely as input parameter to a template the only option today is to use environment variables since they are persisted unexpanded and only expanded when requiring evaluation.

Environment variables are overloaded with responsibility. We use them as secrets, information passing, rules evaluation, runtime environment variables, etc.

We need a mechanism that more explicitly deals with secrets.

Proposal

In order to solve that we can introduce a new paradigm: $[[ secrets.your_secret.access_type]], for example:

$[[ secrets.token.variable_name ]]
$[[ secrets.token.file_path ]]
$[[ secrets.token.vault_key ]]
$[[ secrets.token.encrypted ]]
$[[ secrets.token.plan_text! ]]

This will allow us to provide a mechanism of explicit access to the secrets, depending on what capabilities are configured for a given secret.

slack:
  script: slack-cli $[[ inputs.channel ]] -t "$[[ secrets.token.variable_name ]]"

# or

slack:
  script: slack-cli $[[ inputs.channel ]] -t $(glab decrypt $[[ secrets.token.encrypted ]])

# or

slack:
  script: slack-cli $[[ inputs.channel ]] -t $(vault kv get $[[ secrets.token.vault_key ]])

More details in #395639 (comment 1308609335)

/cc @fabiopitino @dhershkovitch @morefice @ayufan @marshall007 @jreporter