-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Storing complex secrets #749
Comments
I think your second example is almost correct, just omit the now secret add google-private-key "$(cat my-keyfile | base64)" Unfortunately, whatever the intention behind the |
Use @sholladay's method to put the secret in PROD:
then in
then in your code:
Locally, you can use the following to load your secrets:
then use this script in
IMPORTANT!
|
Definitely - action item for this issue is to make sure we're elegantly handling different types of secrets. I'm not sure environment variables are a silver bullet here. This definitely deserves some investigation. |
Anything on this issue lately? Fixing this is kind of vital for apps like GitHub’s own Probot to be deployed successfully with Now. |
@hakusaro Did you try the workaround above? (e.g. for |
I feel like I've been endlessly repeating this. I don't have this issue personally anymore, but it violates the principle of least surprise that the following works:
but the following, which is stupidly close in syntax, does not:
Similarly, |
Sorry did not see it before... I agree with you on "principle of least surprise", but it is NOT a blocker, is it?
|
It's not a blocker by the strictest definition, but the probot maintainers (of which I am regrettably not) currently provide three solutions for deploying probot to the internet. They go to admirably extreme lengths to make the deployment process as simple as possible on the platforms they support. Having this issue introduces enough friction that they would rather exclude the entire platform. I think the fear is that this response:
and no movement on patching this gives an indication that Speaking from my own experience, I knew already that probot was a GitHub product, so I took the suggestion to use The problem is that I have a soft spot for Notice that I'm not even caring about Google API private keys. For every person who reports an issue or comments on an issue about a bug, there are ten others who sigh, drop the platform, and move on to the next. There's no way of telling how many people don't use |
Indeed! Hope the path gets smoother... If only I had time to create a PR... CC @rauchg ? |
As of #1033, the The recommended way to store complex and/or binary data with secrets is with the
Then in your Node.js server code you can use const key = new Buffer(process.env.GOOGLE_PRIVATE_KEY, 'base64'); Or if it's a Docker deployment then do something like:
I hope that helps! |
Closing this after @TooTallNate's answer – please do it like he described 😊 |
great so everyone has to waste hours trying things that don't work as expected and consulting expensive consultants before hopefully discovering this issue and proposed workaround. |
Thanks for raising this issue. I'm having the same problem.
|
@VincentTam a node deprecation isn't an issue with now, and in the page you linked there's a guide on how to do this in a non-deprecated way, which looks like this:
|
There is actually much easier way of storing complex secrets in now. Just do this: now secret add google-private-key -- "`< my-key-file`" The I've tested this and it works for me. This also resolves #80. |
Here's my take on storing Firebase private key on Vercel secrets: Take 1: store long secrets with unescaped newlines (does not work) ❌As like everyone else, tried storing the private key as-is and resulted with this error log which I assume is because the unescaped newlines. View command line log
Take 2: store the whole json as the secret (does work, but exceeds size limit) ❌Tried storing the actual JSON content of the Firebase credentials to Vercel secrets by running something like: vc secrets add firebase-creds-json "$(< ./creds.json)" Then do a Take 3: store long secret as json-compliant secret (does work) 🎉🎉🎉Since take 2 works but it exceeds the secret size limit, now I tried only storing the private key but also as a JSON-compliant value (either a basic quoted string or an object): # as a single string value, note the extra quote
vc secrets add firebase-private-key '"-----BEGIN PRIVATE KEY-----\nXXXXXXXXXXXXXXXXXXXXXXXX\n-----END PRIVATE KEY-----"'
# as a json object
vc secrets add firebase-private-key '{"privateKey":"-----BEGIN PRIVATE KEY-----\nXXXXXXXXXXXXXXXXXXXXXXXX\n-----END PRIVATE KEY-----"}' Then same as take 2, retrieve the value using # firebase env vars
FIREBASE_PRIVATE_KEY_ID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
FIREBASE_PRIVATE_KEY='"-----BEGIN PRIVATE KEY-----\nXXX\n-----END PRIVATE KEY-----"' # make sure to double wrap with quotes Hope this helps! 🎉 |
Thanks @grikomsn, I finally could configure the @grikomsn 's Take 3 and this blog post GOOGLE_APPLICATION_CREDENTIAL without JSON FILEgetAuthToken.tsimport { google } from 'googleapis'
export const SCOPES = ['https://www.googleapis.com/auth/spreadsheets']
// pega credentials das variáveis de ambiente
export async function getAuthToken() {
if (typeof window !== 'undefined') {
throw new Error('NO SECRETS ON CLIENT!')
}
const { privateKey } = JSON.parse(process.env.GOOGLE_PRIVATE_KEY || '{ privateKey: null }')
const auth = new google.auth.GoogleAuth({
scopes: SCOPES,
projectId: process.env.GOOGLE_PROJECTID,
credentials: {
private_key: privateKey,
client_email: process.env.GOOGLE_CLIENT_EMAIL,
},
})
const authToken = await auth.getClient()
return authToken
} env.localGOOGLE_PROJECTID=sheets-xxxxxxxxxxxxxx
GOOGLE_PRIVATE_KEY='{"privateKey":"-----BEGIN PRIVATE KEY.........-----END PRIVATE KEY-----\n"}'
GOOGLE_CLIENT_EMAIL=conta-sheets-de-servi-o@xxxxxxxxxxxxx.iam.gserviceaccount.com |
I finally can store my private Firebase key on Vercel
I was using windows for my development and cmd for the default terminal. After 8 hours trying to repeat the same thing, I decided to use git bash instead and then it just works in less than 1 minute. 😄 |
Honestly, I've been using this solution proposed on SO https://stackoverflow.com/a/41044630/10833201 for quite some time and never had any issue with it. In a nutshell:
PROS:
CONS: none that I can think of. Hope this helps. |
@tlays life saver!!! Thank you I like that I can add my env var from the Vercel dashboard while using this method. According to Vercel's CLI doc, storing env vars as secrets is deprecated. They recommend using their UI |
What I did was simply store the key of the service account via Vercel's UI inside double quotes:
And then simply use |
Hello everyone 👋 We made some changes to the Environment Variables page today: https://vercel.com/changelog/environments-variables-per-git-branch I think a lot of the confusion around these private keys is that the docs assume you are adding the key in a json file so it has escaped newlines instead of literal newlines. However, the Environment Variable page accepts real newlines so you can hit Enter to add a newline where appropriate. You can also use Vercel CLI to add Environment Variables with a value from a file. For example: vercel env add FIREBASE_PRIVATE_KEY production < firebase.txt This will use the contents of Hope that helps 👍 |
Private keys are too large for Lambda AWS. :(
Any way to copy a file to the output directory at build time but not have the file public? |
Here's a workaround for that problem: https://leerob.io/blog/vercel-env-variables-size-limit |
Looks like people are tackling this a whole lot of different ways, but I think a common problem is not understanding how Vercel parses secrets when they are stored in the web UI. I think I have figured some things out. In summary what you put in the web editor is exactly what you get.
Putting these together, the format that worked for my PEM key looked like this: So you could store your secrets like this, but it might be easier to use the same format in vercel's web editor as in your .env.local, in which case you should use the JSON-compatible form as described in part 3 of @grikomsn's comment above: #749 (comment) |
As I struggled hard gluing pieces together and debugging Vercel env variables/JSON.parse etc I created an article that explains how to store the service account json file directly in Vercel and just use JSON.parse on it. Here it is: https://dev.to/vvo/how-to-add-firebase-service-account-json-files-to-vercel-ph5 tl;dr; remove line breaks (not the ones from the Dear Vercel: should the default of vercel env pull be to use single quotes instead of double quotes for env variable values? So this works by default instead of having to manually fix it. |
I headed down this path and ended up writing my own implementation based on @leerob's solution article. Much like @mate-h I wanted a way to persist a file during artifact compilation. I'm hoping this is helpful to others looking for a solution.
Repository: https://github.com/ian/next-secrets Commnents and pull-requests appreciated! |
In summary, as this article points out, my case was solved by encrypting the file. So I ran the AES on the private key, stored the encryption secret key in my vercel secrets, and decrypted it at runtime. This is a workaround because the file is still public, without sharing the contents of it. Using redis is smart, since it reduces the memory overhead! |
This actually did the job in a clean and easy way. Thank you |
Hi same issue here. Not enough space left to add a private key to Vercel Env Vars. If I understand this approach here correctly? https://leerob.io/blog/vercel-env-variables-size-limit Isn't this a big security hole? An api endpoint returns the decrypted private key. Anyone can look at the client side http request to the /api endpoint. See the encrypted key. Seems to defeat the purpose of encrypting it in the first place. |
Check this comment, this was working like charm. https://dev.to/vvo/how-to-add-firebase-service-account-json-files-to-vercel-ph5 |
Thanks. Setting a Vercel Env Var does not work for me because Vercel has a max 4kb size for env vars and this google service account json key file is too big. |
@jamiegood take a look at https://github.com/ian/next-secrets and let me know if that's what you're looking for. This was our usecase too. |
@ian I ended up freeing up some space for the next env vars. But that will not last long so will have a look at next-secrets above. Thanks for that. |
How can I do this with Netlify ? |
Thanks for the solution - work for me with ANY quote on vercel UI console |
Nice! @leerob I don't suppose the 4K max size has been solved has it? |
It has! Very excited to share: https://vercel.com/changelog/16x-larger-environment-variable-storage-up-to-64kb 🎉 |
This is the only thing that worked for me after hows on this. https://dev.to/vvo/how-to-add-firebase-service-account-json-files-to-vercel-ph5 @grikomsn are you have to manually update the quotes in your env.local every time you do a |
This one worked for me after trying multiple solutions from this issue (key in base64 format): https://github.com/orgs/vercel/discussions/219#discussioncomment-128702 |
Solution: #749 (comment)
Hello,
I can't figure out how to store my Google API private key for use in a now deployment.
The key looks something like:
What I've tried:
now secret add google-private-key "<full key>"
now secret add google-private-key -b $(echo "<full key>" | base64)
now --dotenv=.env
How should it be done?
The text was updated successfully, but these errors were encountered: