What does the little "Public" badge mean, next to my environment variables? Can I put secret keys here?

I’m building a React app which will have a simple auth flow via a netlify function/lambda.

The lambda will need a secret token, which I was going to supply via environment variable. Obviously I need the env var to be readable by the lambda, and NOT anywhere on the frontend or anywhere public. Ideally it wouldn’t even be present when building the frontend app, but so far everything I’ve read indicates that all env vars are present during both build and lambda runtime. I can live with that.

Anyway, I was happily defining my env vars through the netlify web app, when I noticed a little badge on the right-hand side, next to each variable, that says “Public”? What does that mean? Is it safe for me to define secrets here or will they be publicly visible somehow? See screenshot below:

Screen Shot 2020-04-24 at 9.41.30 pm

Related, the docs here talk about settings for sensitive variables, but I can’t find any such settings in netlify app. Which is weird.

I tried playing around with a few different settings, and the ‘Public’ badge seems to have disappeared.

Though I’ve spoken to someone else who was seeing the badge a couple of hours ago, and they are also now not seeing it, without having changed anything.

So maybe this was a bug in netlify which has just been fixed? That would be amazing if so!

Hey @camjackson, thanks for reporting this! Turns out we were testing a hard-coded “Public” badge in production since we ultimately do want to make more obvious which environment variables are private and which are not. But we are no longer testing that and it did not actually correspond to your site settings- apologies for the confusion.

If you are deploying from a public repo, you will want to review that “Sensitive variable policy” doc you linked above for which settings you want. And just so you know, the default is to require your approval before external committers to your repo can deploy with your environment variables.

Please let us know if there are any other questions on this!

Ahh, great to hear. Thanks @jen!

Yeah so I figured out that the sensitive variable policy settings only show on projects built from a public repo, which is why I couldn’t see it. One thing that is still a bit unclear to me - is there a distinction between variables which are private/sensitive and ones that are not? Or does netlify treat all variables the same?

From various mentions in the docs it does sound like netlify draws a distinction between public and private variables, but I don’t think that’s laid out explicitly anywhere. More importantly, I can’t see anything that tells me how I can label a variable as sensitive? I’ve been looking for a checkbox or a flag that says private = true but haven’t come across one yet. My best guess was that netlify will infer that a variable is sensitive if I override its value in the [context.deploy-preview.environment] section of my netlify.toml, but that seems very implicit.

Thanks again for your help :slight_smile:

Hi @camjackson Apologies for the confusing UI. That was a small part of a feature that is still in development, and was not intended for customers.

As mentioned in the sensitive variable policy doc you linked, Netlify currently detects which variables could potentially be sensitive. The methods we use for this detection are not public, but you can see which ones we have identified if you select “Deploy without sensitive variables,” and trigger an untrusted deploy. The deploy log will identify the variables excluded from the build environment.

Thanks @verythorough! No apologies needed! :slight_smile: (Also I love your title, more companies should have Documentation Engineers!)

That makes sense now you explain it. That’s really cool that netlify will automatically detect things that are potentially sensitive. I feel that it might be better if the “secret-ness” of the variables were surfaced a little more obviously in the UI when I’m defining my secrets, but that’s good to know that I can check it by triggering an untrusted deploy. Thanks again :slight_smile:

2 Likes