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

The Twelve-Factor App (2011)

12factor.net

Post reply on HN
Print view View original

71–80 of 106 posts

Re: The Twelve-Factor App (2011)

#71

Post by holografix »

vemv wrote: post #52

I really dislike 12FA. It's meaningless. The name sounds neat, but it is undistinguishable from "some guy's twelve preferences". Of course advocating for "some guy's twelve preferences" would never be considered serious argumentation in an engineering context. Yet we do for 12FA. I might agree with this or that point, but taking the package as a whole just leads to weaponization and cargo-culting.

I can’t tell if you’re being sarcastic or not. In case your not, The 12 Factor App was a seminal piece of work that underpinned the foundation of so much we take for granted about “cloud native” today.

It was mostly written by the folks who started Heroku and were doing containerisation and elastic scalability before Docker existed.

It really isn’t “some guy’s preference”.

Re: The Twelve-Factor App (2011)

#72

Post by aliswe »

CameronNemo wrote: post #59
eriner_ wrote: post #24

Earlier quoted context omitted.

I agree completely. Storing secrets in environment variables is wrong: https://blog.forcesunseen.com/stop-storing-secrets-in-enviro... Even unsetting environment variables leaves them in /proc/self/environ. There isn't a thread-safe way to unset environment variables in POSIX, so even if you `unset TOP_SECRET` from within a program the contents of /proc/self/environ will remain unchanged and available.

How do you actually unmount the volume with kubernetes once the secrets are read and the process is ready? I've never heard of a feature like that.

you dont ... you remove the mapping and restart the pod.

Re: The Twelve-Factor App (2011)

#73

Post by kureikain »

jteppinette wrote: post #64
pjbster wrote: post #55

Earlier quoted context omitted.

The best approach I've seen is to have the secrets in a vault and to keep the vault URL in an env var (so different vaults can be used for dev and prod, for example). The secrets location within the vault is held in a variable defined in an application config file which is checked in to source control. At runtime, a piece of code consults the variable and queries the vault using the provided location and then dynamic…

How does the system authenticate with the vault? Why not use that same system to authenticate the database connection? A vault is only useful at scale or with additional compliance requirements. Otherwise, keep it simple. Very few systems actually need that additional level of indirection.

It's usually rely on some globa mechanims by the underlying architecture.

Example, if it's AWS it may rely on ec2 instance role, to allow it access to the secret manager.

If it's kubernetes, it can be done through k8s token mount, basically allow token in namespace access the vault, and the token(which is generated and manage by k8s, which is just a JWT btw) is mounted into your pod.

Re: The Twelve-Factor App (2011)

#75

Post by remus »

vojtad wrote: post #62
pjbster wrote: post #55

Earlier quoted context omitted.

The best approach I've seen is to have the secrets in a vault and to keep the vault URL in an env var (so different vaults can be used for dev and prod, for example). The secrets location within the vault is held in a variable defined in an application config file which is checked in to source control. At runtime, a piece of code consults the variable and queries the vault using the provided location and then dynamic…

Do you have any particular vault in mind? We are looking for a simple solution which would work exactly like you described. We just need couple of different sets of variables for our web server, workers and other services.

I've used GCP secrets manager and it worked well. Pretty simple API and the option for providing your own encryption keys if you want it.

Re: The Twelve-Factor App (2011)

#76

Post by mrslave »

eriner_ wrote: post #41
josephcsible wrote: post #31

Earlier quoted context omitted.

Sure, but if you have one of them, then you can read the secret files out of /vault or whatever too.

Correct! This is why I explicitly said the following in the blog post I linked above: > Once the application hits “readiness” status (as determined by health endpoints or the load balancer), the secrets volume should be unmounted and made inaccessible.

I really like my applications to at least try to reestablish dropped connections though. But I do appreciate the minimization mindset with respect to secrets.

The last time I was responsible for the scaffolding of a new software service it supported reading secrets from a file. It confused the operations team and I was just told to include support for an environment variable. Oh well, I tried.

Re: The Twelve-Factor App (2011)

#77

Post by tosh »

KennyFromIT wrote: post #2

I'm interested to know what causes submissions like this - content that is years old and posted with no context - to hit the first page on a random day.

In this specific case: I stumbled upon Craig's tweet/poll yesterday https://twitter.com/craigkerstiens/status/151949609064658944...

  The killer feature of Heroku was/is:
  * git push heroku main
  * Review apps
  * Heroku postgres 
  * Add-ons
& this reply

https://twitter.com/srinathkrishna/status/151949673020236185...

  I'd say the 12factor manifesto was the biggest thing to come out of Heroku. There's a lot of wisdom in there.

Re: The Twelve-Factor App (2011)

#79

Post by nickjj »

I really like this methodology and it still applies today across techs, such as with Docker and Kubernetes. It feels like one of those things that'll be around for another 10+ years.

If anyone is interesed in seeing each pattern applied directly to an open source code base I made a video on that at: https://nickjanetakis.com/blog/creating-a-twelve-factor-app-...

Re: The Twelve-Factor App (2011)

#80

Post by ge96 »

nickjj wrote: post #79

I really like this methodology and it still applies today across techs, such as with Docker and Kubernetes. It feels like one of those things that'll be around for another 10+ years. If anyone is interesed in seeing each pattern applied directly to an open source code base I made a video on that at: https://nickjanetakis.com/blog/creating-a-twelve-factor-app-...

Your podcast is great btw
Post reply on HN