Security Discussion: Managing sensitive fields in dynamically created Connectors

[arun-kandasamy]

Hi Dex community,

thanks for creating and maintaining Dex, we are using it to integrate with external IdPs to authenticate users into our system.
We manage our connectors (OIDC, LDAP, etc.) via the api.v2 gRPC interface. In doing so, we've identified a concern regarding the handling of sensitive fields (like clientID, clientSecret, bindPW ..) for these dynamically created connectors and we'd like to know if there is any suggestions regarding this issue from the community.

The Concern: Plaintext Secret Storage
The api.v2.Connector message uses a bytes config field to store the connector's configuration. This configuration, which is sent in the gRPC payload, contains sensitive credentials like the clientSecret for OIDC or bindPW for LDAP. Our concern is that this entire configuration, is serialized and stored without encryption in Dex's storage backend (e.g. PostgreSQL).

Our Constraint
Because we create and update connectors on-the-fly via the API, solutions that rely on static, pre-configured secrets are not viable. For instance, we cannot use a system where secrets are pre-loaded into Dex's environment variables at startup, because we don't know what connectors (or their secrets) will be needed in the future.

Potential way forward ?
how about the possibility of implementing transparent encryption-at-rest within Dex. This could work by allowing Dex to be configured with a master encryption key. Dex would then use this key to automatically encrypt the config field before writing it to storage and decrypt it upon retrieval
follow up questions :

• Are there any existing best practices or workarounds for this dynamic scenario that we may have missed?
• What are the community's thoughts on adding a transparent encryption feature to Dex to address this?

Thanks for your time and any suggestions you may have!

[arun1587]

@nabokihms, @sagikazarmark, @bonifaido , @rithujohn191 do you have any thoughts on this ?
and btw, i have a branch on my fork with the implementation based on fernet encryption of sensitive fields in the connector's config and tested for postgres and sqlite3 storages.
I can work on to raise a PR to the repo if we agree on the proposition.
thanks!