Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Environment variables are a legacy mess: Let's dive deep into them

allvpv.org

Post reply on HN
Print view View original

161–170 of 194 posts

Re: Environment variables are a legacy mess: Let's dive deep into them

#161

Post by fragmede »

stackskipton wrote: post #84
Nilocshot wrote: post #74

Earlier quoted context omitted.

This is where I like things like Tilt. If you're deploying to a k8s cluster, it's probably a good idea to do local dev in as close to a similar environment as possible. Bit more of an initial hurdle than "just run the docker image"; however.

I've look at Tilt and it's another abstraction for Kubernetes which rarely ends well at scale. However, most of time, Devs don't need to develop on Kubernetes since it's just Container Runtime and Networking Layer they don't care about. They run container, they connect to HTTP endpoint to talk to other containers, they are happy. Details are left to us Ops people.

It seems contradictory to say that Tilt is an abstraction over kubernetes and say that won't work at scale, but then volunteer ops to be a layer of abstraction over kubernetes as a solution.

FWIW, Skaffold.dev is similar to Tilt, and has been working out great. "skaffold dev" on the cli or the corresponding button in the users IDE starts up a local kube cluster (minikube), the dev code in a container, any other configured containers, optionally opening a port to attach a debugger, and watches the code for changes and restarts the container with the dev code when there's changes. Developers aren't beholder to the capacity of whoever's on call on the ops team to manage the containers they need to be productive. The details of pods and CRDs and helm and ArgoCD and kubectl are abstracted away for them. They just run "skaffold dev" and edit code. Ops gets to run "skaffold render" to build and tag images, and generate the corresponding kubernetes manifest.

Re: Environment variables are a legacy mess: Let's dive deep into them

#162

Post by julianz »

sureglymop wrote: post #100

On another note, does anyone know how this blog/website was created? I am in general very curious about ssgs hence why I am asking. My guess would be either Jekyll or hand rolled, due to the url structure.

The RSS feed has an attribute that suggests Hugo.

Re: Environment variables are a legacy mess: Let's dive deep into them

#163

Post by amluto »

icedchai wrote: post #156
amluto wrote: post #142

Earlier quoted context omitted.

> It's not your (unprivileged user account's) place to decide the security posture of the entire system, that's why you're running into issues with root. Tell that to literally any unprivileged user who would like to run any sort of software without exposing their entire account to any possible code execution bug or malicious code in the software they're running. > The real security barrier on most operating systems…

Apple's "App Sandbox" stuff helps quite a bit with this sort of thing. I realize that doesn't solve the Linux / generic Unix case. https://developer.apple.com/documentation/security/app-sandb...

I skimmed the docs. It appears that this is a mechanism whereby a developer can restrict what their app can do via some configuration in Xcode. This seems almost unbelievably weak — developers want more privileges for their app, not fewer (especially developers of semi-malicious tracker-style SDKs), and the app sandbox seems entirely capable of, say, allowing a document editor app to open a document in a separate sandbox.

Re: Environment variables are a legacy mess: Let's dive deep into them

#164

Post by ori_b »

monocasa wrote: post #139
cbsmith wrote: post #61

Earlier quoted context omitted.

An infinitesimal leak becomes a problem if it is done an infinite number of times... execve seems like the preferable choice on a lot of grounds.

Which is why I said > frequency of data Practically, if you're moving enough data through setenv that the memory leaked versus the steady state fluctuation of the program is at all visible, you've got much bigger problems.

You don't need setenv. It's just a particularly broken way of assigning to a global char*.

Re: Environment variables are a legacy mess: Let's dive deep into them

#165

Post by nrds »

sureglymop wrote: post #48
nrds wrote: post #35

Earlier quoted context omitted.

I think it's worth specifically calling out that the right way to set environment variables is in execve() only, as communication across an exec() is the precise niche for which they are the right tool.

Why are they the right tool for that instead of passing data with program args or another way of IPC?

I do not claim they are the only or even best tool :)

Re: Environment variables are a legacy mess: Let's dive deep into them

#166

Post by stackskipton »

fragmede wrote: post #161
stackskipton wrote: post #84

Earlier quoted context omitted.

I've look at Tilt and it's another abstraction for Kubernetes which rarely ends well at scale. However, most of time, Devs don't need to develop on Kubernetes since it's just Container Runtime and Networking Layer they don't care about. They run container, they connect to HTTP endpoint to talk to other containers, they are happy. Details are left to us Ops people.

It seems contradictory to say that Tilt is an abstraction over kubernetes and say that won't work at scale, but then volunteer ops to be a layer of abstraction over kubernetes as a solution. FWIW, Skaffold.dev is similar to Tilt, and has been working out great. "skaffold dev" on the cli or the corresponding button in the users IDE starts up a local kube cluster (minikube), the dev code in a container, any other confi…

Ops is not a layer of abstraction over Kubernetes no more then Dev is layer of abstraction over Python. We both have different responsibilities and thinking that Ops is just missing one more library is why it goes so wrong.

Kubernetes is massive beast and I get it. It feels extremely overcomplicated for "Please for the love of all that holy, just run this container." However, trying to abstract away such complexity is like trying to use Golang with some Python to Golang cross compiler. It works until it you need some feature and then oh god, all hell breaks loose.

I have not played with scaffold either but I will say. scaffold render should not be Ops job, I find it goes best when Devs present artifact they believe is ready for production and I can slot into the system. Otherwise, the friction between Devs handing Ops what they think is possibly buildable artifact quickly becomes untenable.

Re: Environment variables are a legacy mess: Let's dive deep into them

#167

Post by SoftTalker »

bjourne wrote: post #157
SoftTalker wrote: post #116

Earlier quoted context omitted.

They are (should be) encrypted though, and not usable by someone who might somehow gain access to your ~/.ssh files.

No, the private keys are not encrypted. If there were, where would you store the encryption key for decrypting them?

My ssh private keys are encrypted. The keys are stored in my brain.

Re: Environment variables are a legacy mess: Let's dive deep into them

#168

Post by yukinon »

stackskipton wrote: post #45

SRE/Sysadmin/DevOps/Whatever here, while blog didn't talk about doing anything difficult but setting ENVVAR standards, I will point out all replacements are just as frustrating especially when talking about secrets. Anything involving vaults where Application reaches out to specific secret vault like Hashicorp Vault/OpenBao/Secrets Manager quickly becomes massive vendor lock in where replacement is very difficult due…

I am not sure if this considered an anti-pattern, but in one of my teams, we wrote a lightweight generic Secrets library with configurable/pluggable backends (such as AWS Secrets Manager). It had a configurable local cache, with per-parameter overrides to bypass the cache. It meant vendor specific fetch logic was in the pluggable backends, while the app and the secrets lib remained vendor neutral.

When we moved it to Vault, it was seamless. Just meant adding our Vault backend wrapper as a dependency and updating the config to use the Vault backend.

Re: Environment variables are a legacy mess: Let's dive deep into them

#169

Post by akvadrako »

bjourne wrote: post #158
akvadrako wrote: post #136

Earlier quoted context omitted.

The command line can be read by any user on the host (with `ps auxww` for example) while the environment cannot. You should never pass secrets on the command line.

Environment variables are not more secure than command line parameters! It's such a common misconception that because environment variables are "not seen" they can serve as a secure channel. They emphatically cannot.

Secrets being hidden ("not seen") is really their main quality...

Re: Environment variables are a legacy mess: Let's dive deep into them

#170

Post by zzbn00 »

Many comments here focusing on secrets and problems. But here is another way to look at this:

Environment variables are the "indefinite scope and dynamic extent" variable bindings to make structured programs out of Unix processes. To compare them to a text file is like writing that a program needs no variables because it can read all the values it needs from an input data file when it needs them.

Environment variables are precisely to be used in situation where sub-processes need to be passed information in a way that is not necessarily affecting subsequent calls to that subprocess from another section of a program. Sometime the subprocesses are sequences of nested shells, and sometimes other more complex programs, but the same idea applies.

Post reply on HN