Allow secret environment variables values to be hidden from the dashboard UI #6592
The problemI have a Nextjs project on Vercel which contains environment variables that are highly sensitive, meaning that the values should not be exposed as plain text on the Vercel dashboard. Currently, anyone on the Vercel Team with access to the project can view the values by clicking the "show" icon like in this screenshot:
The ideaAllow environment variables values to be permanently hidden from the dashboard so that once they're added, their plain text values can not be seen again. This could be just an optional checkbox when adding the variable through the dashboard UI. Vercel previously supported "secrets" which behaved just like this - they were encrypted and their values in the dashboard were displayed as |
Replies: 4 comments 5 replies
|
This is a major problem and I honestly don't know how this made it into production. We can no longer add contractors to our vercel environment because vercel now exposes all of our secrets to them without This breaks vercel for us and may result in us switching service provider despite loving the rest of the features. |
|
This seems like a huge flaw, please address ASAP! |
|
Looking back through some older projects, I can still see env variables that were added as secrets meaning that the value is never displayed in the UI. For these env variables, Vercel is still showing the old UI (where you can choose between "plaintext" and "secret"), which is exactly what I would like to still be able to do.
|
|
@cviphone is correct, this is the desired and in my opinion correct behavior Actual secrets should never be exposed as plain text anywhere once encrypted, especially in a web ui |
|
You no longer need to specify the type of Environment Variable because all values are now encrypted by default. Previously, it was difficult to retrieve the encrypted value of the secret after it was created. With the new design, values are still encrypted but are more easily accessible and decrypted through the UI.
We will eventually be migrating all secrets to use the encrypted by default Environment Variables.
They're still encrypted at rest and in-transit 👍
We will be adding additional access/roles to lock down access in the dashboard for Vercel Teams. Note: You can still fetch Environment Variables locally with https://vercel.com/changelog/environments-variables-per-git-branch |
|
If a value is readable in plain text by users of your org then encryption doesn't really matter. My org can no longer add contractors to any of our projects because any member of the org can just use the web UI to see all of our production secrets in plain text. As @cviphone described above you already had a working solution. You should revert to that until you can actually deliver a solution that doesn't leak production secrets. |
@leerob any approximate timeframe for this being released? And should it solve our case of preventing certain team members from seeing env variable values? Even if it's just preventing access to the entire env variables page on the dashboard. |
|
@defigjolund @cviphone
Fact: The previous implementation of "secrets" also shares a similar level of security threat as the current implementation. Anyone with access to your code and rights to deploy (even contractors added to your project) can have access to your secrets. They can simply do a console.log in your code to dump out these secrets and then delete the deployment to remove any trace of this attempt. The previous implementation adds an extra layer of false sense of security over the use of secrets. Until Vercel rolled out the additional access/roles to lock down access, this limitation will always be there so the current implementation does a better job of making this limitation known to everyone. |
|
@williamli thank you for clarifying this, I guess it will be back to my implementation of branch deploys with GitHub actions for sensitive secrets. This seems like a pretty major oversight for an organization like vercel, github and several other CI providers I have used handle this problem well and I will stick with them until this is resolved. At the very least keep secrets out of logs, that seems pretty trivial to solve at this point. |
You no longer need to specify the type of Environment Variable because all values are now encrypted by default. Previously, it was difficult to retrieve the encrypted value of the secret after it was created. With the new design, values are still encrypted but are more easily accessible and decrypted through the UI.
We will eventually be migrating all secrets to use the encrypted by default Environment Variables.
They're still encrypted…