Live data from Hacker News

The Twelve-Factor App (2011)

12factor.net

21–30 of 106 posts

Re: The Twelve-Factor App (2011)

#21
post #6
post #5

Earlier quoted context omitted.

Many of us recall with great fondness the first time we read about 12 factor apps. In particular, those of us that had been working on systems like this, but hadn’t codified it with explicit guidelines. It just made sense. The pleasantness of things just working consistently from scratch on a brand new server. Replacing the concept of pet servers with cattle. It’s all related. I’m sure every time this makes the front…

Is HN a search engine for xkcd? Honestly people, do you have them indexed somewhere? I'm amazed by your ability to find the appropriate xkcd whenever it's needed. Me, I'd have to spend at least half an hour on Google trying to find it, and then give up or see that someone else already posted it. I love this community.

You can find most iconic xkcd comics easily with Google. This one shows up with "xkcd new things" or "xkcd first time".

Re: The Twelve-Factor App (2011)

#22

One thing that I think could be updated in the 12F approach is the use of env vars for config, especially secrets. I’ve generally found it much better to mount these into the filesystem and read from there. It helps with, for example, secret rotation for long running processes. Relying on process restarts can be ugly in some setups, especially if startup time is expensive.

In kubernetes I run external secrets, which is nice. I store The secrets in key value or file format in AWS Secrets Manager, which gets synchronized to the cluster into a secret. From there it gets mounted into the running pod via the envFrom or volume mount method.

Re: The Twelve-Factor App (2011)

#23
post #4

Earlier quoted context omitted.

Sometimes it's people who feel like posting oldies/perennials/classics, and sometimes it's people running across a thing for the first time. We've had to learn not to crack down on these too heavily because there's always an up-and-coming cohort of new users who've never seen them before, and HN should be a place to run across them. Once a year seems to be an acceptable maximum rate ( https://news.ycombinator.com/new…

Thanks for the explanation. Now for my next question: Out of all the other posts out there right now, how on Earth did my little inquiry catch your eyes? ;-)

Purest randomness.

Re: The Twelve-Factor App (2011)

#24

One thing that I think could be updated in the 12F approach is the use of env vars for config, especially secrets. I’ve generally found it much better to mount these into the filesystem and read from there. It helps with, for example, secret rotation for long running processes. Relying on process restarts can be ugly in some setups, especially if startup time is expensive.

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.

Re: The Twelve-Factor App (2011)

#25
post #24

One thing that I think could be updated in the 12F approach is the use of env vars for config, especially secrets. I’ve generally found it much better to mount these into the filesystem and read from there. It helps with, for example, secret rotation for long running processes. Relying on process restarts can be ugly in some setups, especially if startup time is expensive.

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.

But /proc/*/environ is only readable by the user the process is running as and root, so if you can read it, you're already on the other side of the airtight hatchway.

Re: The Twelve-Factor App (2011)

#26

One thing that I think could be updated in the 12F approach is the use of env vars for config, especially secrets. I’ve generally found it much better to mount these into the filesystem and read from there. It helps with, for example, secret rotation for long running processes. Relying on process restarts can be ugly in some setups, especially if startup time is expensive.

Check out the Secretless Broker at https://secretless.io. It's a cool open source project that allows applications to not need to know secrets which adheres to 12-factor app guidelines.

Re: The Twelve-Factor App (2011)

#27
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.

But /proc/*/environ is only readable by the user the process is running as and root, so if you can read it, you're already on the other side of the airtight hatchway.

Arbitrary file read vulnerabilities are extremely common.

Re: The Twelve-Factor App (2011)

#28

One thing that I think could be updated in the 12F approach is the use of env vars for config, especially secrets. I’ve generally found it much better to mount these into the filesystem and read from there. It helps with, for example, secret rotation for long running processes. Relying on process restarts can be ugly in some setups, especially if startup time is expensive.

Check out the Secretless Broker at https://secretless.io . It's a cool open source project that allows applications to not need to know secrets which adheres to 12-factor app guidelines.

hmmm.... im trying to understand the benefit of secretless broker... if someone compromises thisnwouldnt they have access to all credentials for everything?

now we are just moving from trusting a bunch of distinct services to trusting this single broker... just moving the responsibility of trust to a single point of potential failure no?

Also dont credentials have to be passed to secretless broker? how does it know the application has access to the service? isnt that still at risk of being leaked.

i like the idea of not thinking about secrets but it seems to good to be true.

Re: The Twelve-Factor App (2011)

#29
post #4

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.

Sometimes it's people who feel like posting oldies/perennials/classics, and sometimes it's people running across a thing for the first time. We've had to learn not to crack down on these too heavily because there's always an up-and-coming cohort of new users who've never seen them before, and HN should be a place to run across them. Once a year seems to be an acceptable maximum rate ( https://news.ycombinator.com/new…

Hey dang. I have a question too.

Does it really need a 2011 tag?

I thought only blog posts and news articles got year tags. 12FA is guidelines website that is mostly timeless.

What's the criteria for a year tag?

Re: The Twelve-Factor App (2011)

#30

One thing that I think could be updated in the 12F approach is the use of env vars for config, especially secrets. I’ve generally found it much better to mount these into the filesystem and read from there. It helps with, for example, secret rotation for long running processes. Relying on process restarts can be ugly in some setups, especially if startup time is expensive.

It's the part of 12 factor that makes me giggle a bit; like it how does it get into the environment?

Reminds of the "Front fell off" comic sketch. "No, we towed it out of the environment"

https://www.youtube.com/watch?v=3m5qxZm_JqM

Post reply on HN