Skip to content

Hide secrets in configs of input output #116

@PaulKalho

Description

@PaulKalho

Currently, when the outputs are preconfigured, we set the secrets as cleartext strings, and also provide the frontend with those cleartext strings.

To handle secrets, we could proceed as follows:

  1. The configs in the cbc.yaml, if they are a secret, should be identified with: secret: true (or something like that)

In core, we could handle it like this:

  1. All config keys, that are secrets, will be treated as booleans (if core provides a default value for the key (e.g. provided over ENV variable DEFAULT_CB_CONFIG_PG_PASS or DEFAULT_CB_CONFIG_S3_ACCESS_KEY) or will be set as null by default.

  2. This lets the user to either check a box -> "use default" in the frontend, or to set a string manually.

  3. On create, we then know, if the user wants to take the default value we provide in the backend (if we provide one), or we can hash the string that he sent us and then insert it in the database.

  4. We will never send any secrets to the frontend

  5. The dag translator would need to decrypt the secrets gained from the db


This Issue requires changes at a fow location:

  1. The SDK must provide the option to define a config key as a secret (this could maybe be combined with cbc.yaml null values in configs & envs should be typed scystream-sdk#19
  2. The frontend, needs a "new" input component where the user can either tick a checkbox, or provide a string
  3. The response model of compute-block information & get compute block must be refactored (frontend & backend) -> We must know if a secret key has a default, or if the user HAS TO provide a value
  4. How would we handle autoconfiguration of inputs? -> TODO

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions