I was hoping this would be about twelve-factor authentication
Please delete this comment I don't want anyone getting ideas.
The Twelve-Factor App (2011)
61–70 of 106 posts
Re: The Twelve-Factor App (2011)
#62One 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.
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.
Re: The Twelve-Factor App (2011)
#63I'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.
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…
> Relevant xkcd: https://xkcd.com/1053/
I'm one of the 10.000 today with this comic (well, actually no because I'm European). I really love the concept behind: focus on how cool is to for someone to discover some great new thing they will enjoy instead of focusing on how they missed it all this time.
Re: The Twelve-Factor App (2011)
#64One 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.
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.
Re: The Twelve-Factor App (2011)
#65Earlier 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.
I don't know and I don't need to know (I'm a mere dev -- no "ops" in my role). And, yes, this client has very high compliance requirements.
Re: The Twelve-Factor App (2011)
#66Earlier 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'm not sure which vault we're using. There's no identifying information in the server responses. The storage type shows as "Consul" so that suggests Hashicorp Vault.
I'm not the person to ask how to set it up but it's seamless in use and can return data in json format which makes it easy to parse. If it were my money I'd look very hard at this product.
Re: The Twelve-Factor App (2011)
#67Earlier 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.
There are often multiple sets of credentials that you need to pass to a microservice, some of which may be shared between multiple instances of the service or even between multiple services. Changing them would require plenty of case-specific updates to service configurations or just one update in the vault. By reducing the amount of work to update the credentials you also reduce security and quality-related risks.
Re: The Twelve-Factor App (2011)
#68I 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'm not sure how you can say it's meaningless. It's clearly not just a bunch of babble that you often see in business writing: each of these is a specific, concrete suggestion. I'm also fairly sure it wasn't just one guy's preferences, and in any case those preferences were born out of experience with the early days of the web.
I've worked on web services that did not follow those principles as well as ones that do, and it seems pretty clear to me these principles are all more or less correct. In my experience this is now more-or-less best practice* for web services.
*with maybe minor exceptions such as accessing secrets from an external vault service.
Re: The Twelve-Factor App (2011)
#69When i first found 12 factor i was really impressed, it was/is a collection of guidelines that suit their defined purpose really well, easy to read and implement. I always feel like there should be more parts of software/web dev with guidelines like this. An easily digestible format that is easy to discuss with colleagues other examples i can think. - https://refactoring.guru/ - not exactly a list of guidelines but a…
It's been a long time since I read this. I just did a mental audit of the services my company runs, and they all (more or less) match what's in this document. It's not even a conscious thing anymore.
I think any mid-level backend engineer (or any web-related software engineer, for that matter) would do well to read through this and dive deeper into each of these recommendations to understand why they were chosen.
Re: The Twelve-Factor App (2011)
#70One 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’ve generally found it much better to mount these into the filesystem and read from there. Is there a standardized/best practice way to do this? Some convention for file names or format?
There is docker secrets and some specialized convention for example to share the ssh control socket during build time etc.