You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For organizations which have adopted other secret stores, having the option to set environment variables in the Dagster UI can be confusing and misleading. Organization admins could have the ability to disable the environment variable UI entirely so that it isn't used in place of the other secret store.
The text was updated successfully, but these errors were encountered:
A similar "compliance" flavored request is to have the env var page act as "write once, read never". While it'd be possible to deploy code to print secrets, some security orgs just get really turned off by the ability to view the set secrets on that page
There are a few reasons we are trying to stay away from the current behavior:
First and foremost we can't verify and control that users won't use Env variables as a secret store.
Even though envVars can be scoped to deployment groups/code locations, we find management and isolation of these env variables a bit difficult as there would be numerous users on the platform and each have access to multiple code locations and deployment groups.
It also makes sense to me if the OrgAdmins were the only ones allowed to see/set these Env Variables.
For organizations which have adopted other secret stores, having the option to set environment variables in the Dagster UI can be confusing and misleading. Organization admins could have the ability to disable the environment variable UI entirely so that it isn't used in place of the other secret store.
The text was updated successfully, but these errors were encountered: