Application database should be able to store encrypted credentials

[ThomasLaPiana]

trafficstars

Is your feature request related to a specific problem?

We currently have no way to persist sensitive credentials

Describe the solution you'd like

An encrypted database table that allows users to store credentials for various third-party systems safely

Describe alternatives you've considered, if any

Not allowing any kind of configuration storing

Additional context

Must be encrypted

[SteveDMurphy]

After a quick chat in office hours today, it felt like some extra scope/detail could be added.

Some initial questions that came out of it (feel free to add anything I missed or got wrong @allisonking and @earmenda):

• It sounded like fidesops has likely solved part of this, is there someone specific to work with over there that can be reached out to?
• Are there other issues we can link that help refine the use-case? (e.g. loading a form on the front end for all required credentials, usage of persisted credentials)
• Is there a known complexity we want to account for (such as having multiple snowflake accounts / regions)
• #529 may have some overlap here as well worth reviewing (for what it's worth, I feel like Meltano does a great job of balancing the storage of secrets on your own hosted infrastructure along with env var options, etc.)

[ThomasLaPiana]

The primary intent of this feature is to allow organizations to store credentials within the server, so that the server itself can run regular coverage checks without someone needs to input these values directly. However, it seems like going the route of environment variables might be a better/easier first iteration for now given that we already natively support them.

We can wait until we get more user feedback to prioritize this, unless anyone else thinks we need it now

[SteveDMurphy]

The primary intent of this feature is to allow organizations to store credentials within the server, so that the server itself can run regular coverage checks without someone needs to input these values directly. However, it seems like going the route of environment variables might be a better/easier first iteration for now given that we already natively support them.

We can wait until we get more user feedback to prioritize this, unless anyone else thinks we need it now

I do think it's quite nice to have, even as a starting point to scan a snowflake instance repeatedly, but understand if it is a lower priority at this point while we get a fuller plan in place.

Also, I could be wrong but does our env var usage totally cover the case of having lots of instance of the same infrastructure?

If we had something like (borrowing from Meltano again):

- config_name: snowflake_1
     config_type: snowflake
     config_values: 
      - snowflake_user: user
      - snowflake_password: pass
      - snowflake_account: account
      - ...
- config_name: snowflake_2
     config_type: snowflake
     config_values: 
      - snowflake_user: other_user
      - snowflake_password: other_pass
      - snowflake_account: other_account
      - ...

then you could reference the config name and either pull it from the persistent layer, env vars, or the config file?

[ThomasLaPiana]

No our env var/config setup doesn't support multiple of the same type, true. We could overhaul our config to include sets of credentials, that seems like a ticket that is a prerequisite to this one as well

[ThomasLaPiana]

solved via ops merger