111–120 of 147 posts
Earlier quoted context omitted.
Using AppRoles and consul-template. And if you're on Kubernetes, you can use https://github.com/sethvargo/vault-kubernetes-authenticator in an init container.
And how does k8s pass that value to the app?
Earlier quoted context omitted.
Cloud lock-in (not being able for example to manage cross-platform credentials) and cost. By itself AWS Secrets Manager is fine, but as with everything AWS, billing is pretty opaque. If you couple this with a poorly planed Lambda setup, costs can potentially uncontrollably scale. For what you are paying, AWS Secrets Manager seems too barebones/rigid.
Lock in shouldn't be too bad. It's create, get, set, list, delete, describe. I imagine the API footprint isn't much different if you switch over to something else. Most apps will just use get().
If you think that putting secrets in ENV is bad, you probably shouldn't take the advice of running ' docker service create --secret="secure-secret" redis:alpine ' either! Putting secrets in a command line makes them just as visible, in fact more so, to other processes. It also makes the secrets available to anyone regardless of permissions, since everyone can monitor the currently running processes and their args (e.…
Also this pattern makes path traversal vulnerabilities (a thing not uncommon in web frameworks) have the potential to allow for privilege escalation on Linux via the /proc/self/environ file. I've been on a pentest where a recently disclosed path traversal bug in Rails was not patched in the environment I was testing and I thought I would get at least some credentials from at least one service, but every host used a d…
Any chance they documented that setup publicly? Would be interested to dive in to how all that works and gain any new insights
Can't say much more due to NDAs.
Edit: this service handles credentials and rotation for hundreds of thousands to millions of hosts.
Earlier quoted context omitted.
This comes back to where does the config file live and how is it managed?
The plain config file must live in memory (tmpfs). The encrypted config file on a hard drive that is accessed only to decrypt the file to memory.
I am progressively adopting Hashicorp Vault as the secrets manager of choice. It can be used by a variety of different scenarios -- directly into the application using AppRole, with Terraform using it's secrets provider, by developers, during vault authentication when they get their secrets and access regenerated. This way I am not bound to docker swarm, or keywhiz, or god forbid AWS Secrets Manager. As of now, I am…
Vault looks cool, but looking at the reference architecture [1] my guts tell me it's much easier to fuck up setting up a Vault cluster than environment variables. [1] https://learn.hashicorp.com/vault/operations/ops-reference-a...
Earlier quoted context omitted.
> not checked into the source code repository Or checked-in, for easy distribution, just encrypted: https://github.com/sobolevn/git-secret
I mean anything encrypted needs to be decrypted, meaning you have to... have the key stored in an environment variable on the server?
The advice is good. But why is ENV capitalized? The term is just "environment variable". One heuristic I use for evaluating technical material is orthography: if you spell or capitalize or spell something improperly, it's likely you'll get a lot else wrong too. As for secret storage: didn't we solve this problem with keyrings? If I must put a secret in long-term plaintext storage, I might as well put it in a file, wh…
And while the program env is lowercase, the environment is commonly referred to as ENV in technical literature, APIs and so on. If you didn't know that, it's likely you are getting a lot else wrong too...
Plus, the "heuristic" is bogus anyway. Though it might be fine for evaluating candidates for secretarial roles though...
Earlier quoted context omitted.
Maybe he's got a history of working with PHP? $_ENV is an autoglobal array that gets filled with environment variables. https://www.php.net/manual/en/reserved.variables.environment...
The example they use at the top of the article is in bash/shell, and seeing it written as in the article (as "ENV variables") is kinda like a code smell, indicating the author isn't really familiar with what they're criticizing. I think that's what GP is getting at, and it threw me as well - the article really only makes sense when looking at it from the perspective of the author not knowing how env vars are scoped.
Sorry, but technical knowledge/experience is not about particular spelling conventions and word proofing, anymore than they are about wearing "business" clothes...