Live data from Hacker News

Mozilla SOPS with KMS and Git is underrated (2019)

oteemo.com

31–36 of 36 posts

Re: Mozilla SOPS with KMS and Git is underrated (2019)

#31
Until you dig into deeper use cases, it's easy to get hung up on Vault as JUST a KV store. Honestly, if that's all you want, and you're on a cloud provider, using a combo of their storage + KMS or other services (i.e. SSM Parameter Store) is probably the more practical approach.

That said, the proposed drawbacks aren't necessarily ... drawbacks? Granted my perspective is from deploying Vault to the Cloud vs. on-prem.

1. Yeah, Vault needs a separate place to do its storage. However, that's a strength if you're following an immutable infrastructure pattern. You store the data in something like DynamoDB and still have the freedom of tearing down and re-creating the Vault servers themselves.

2. Vault may be more expensive right out of the gate, but if you're trying to cover ALL of its functionality with cloud services, it'll start saving you money eventually. Furthermore, many of the cloud alternatives have service limits and quotas. I mean geez, if you want an internal CA through AWS, you're paying a flat $400 a month + costs per certificate.

3. Vault has a learning curve, but it's not worse than having to memorize the buffet of CLI commands through your cloud provider. Yes, getting it set up for the first time can be a jigsaw puzzle, but when everything is up and running, it's smooth sailing. (Plug - I have a project that automates setting up Vault on AWS: https://github.com/jcolemorrison/vault-on-aws)

4. As for vulnerabilities of the "default implementation" - Yes, the public cloud presents more opportunities for exposure, but that's not limited to just Vault. Furthermore, if someone gets root access to your vault servers...that's not a vault thing. 80% of the 2019 massive cloud breaches are the result of misconfigurations and account compromises (source: https://www.paloaltonetworks.com/resources/research/unit42-c...).

Re: Mozilla SOPS with KMS and Git is underrated (2019)

#32

Earlier quoted context omitted.

> We have integrated storage as an option now, so you don't need separate storage mechanisms. Off topic, but seeing as you mentioned it - do you see the integrated Raft storage becoming the preferred solution? Without it, there's (IMHO) a bit of a chicken-and-egg bootstrapping problem between Vault and Consul.

Yes it will become the preferred solution. We just went GA with it (after a year of testing) in our last release. We’re now recommending this to customers. We’ll continue to provide support for Consul indefinitely and aren’t forcing customers to switch over. (Note “support” above is literal human support. “Support” in terms of enabling that use case will be around indefinitely but planned forever, we’ll always suppor…

GA? And what kind of customers?

Re: Mozilla SOPS with KMS and Git is underrated (2019)

#33

I'm one of the creators of Vault. I read this back when it was posted and I'd be happy to share my thoughts. I'll note its worth reading through to the last paragraph and into the comments, the title is a bit bait-y and the article does a better job than the title gives itself credit for. Broadly speaking, if you're looking at Vault to solve a specific problem X for a specific consumption type Y on a specific platfor…

Would you mind comparing Vault to Keycloak? https://www.keycloak.org/ I need an equivalent to Windows' Active Directory in Linux world that ideally can also federate with/masquerade as AD. Can Vault be such thing?

You might find FreeIPA useful. Its CA component (dogtag) has a KRA component that FreeIPA exposes as 'vaults' for secret storage.

You can even do cross-forest trust to AD, log into your Linux systems as users who live in AD...

Re: Mozilla SOPS with KMS and Git is underrated (2019)

#34
post #32

Earlier quoted context omitted.

Yes it will become the preferred solution. We just went GA with it (after a year of testing) in our last release. We’re now recommending this to customers. We’ll continue to provide support for Consul indefinitely and aren’t forcing customers to switch over. (Note “support” above is literal human support. “Support” in terms of enabling that use case will be around indefinitely but planned forever, we’ll always suppor…

GA? And what kind of customers?

GA = general availability

Re: Mozilla SOPS with KMS and Git is underrated (2019)

#35
post #9

Anyone here used Vault to secure a Phoenix application? In particular, the idea that a short lived database credential can get auto-refreshed and then notify the Repo's supervisor to restart the repo with new credentials? That's how I'd probably do it but I'd rather not reinvent the wheel if someone's already done it.

At the end of the day, what's the difference between restarting the app because you updated an environment variable, or restarting the repo? In both cases you might have short service interruptions. So why not simply restart the app which is definitely more technology agnostic.

This would amount to potentially "restarting" the app every hour? That would cause potential errors every hour.

I think I saw somewhere that it's actually quite easy to do this with OTP. You can just tell the supervisor to kill the children and when they respawn, they'll pick up the new credentials.

Re: Mozilla SOPS with KMS and Git is underrated (2019)

#36
If you have a handful (say less than 10) repos, the article is right – Vault is an overkill. You can and should just check-in encrypted secrets with git-crypt or SOPS. Whenever master enc/dec keys are rotated, you can afford to make a dozen PRs and commits. Note here - I'm not talking about rotating revoked secrets. I'm taking about the master key rotation.

If you have hundreds of repos, the mere fact of "rotating" all secrets when the master key changes is a laborious task. Opening, tracking and waiting for hundreds of PRs to be merged, with stuff failing for unrelated reasons to secrets (random unit test or PR check failures, etc) will take months.

https://12factor.net/config – this exists for a reason. Your PR checks have nothing to do with production secrets. Your code is compiled with Java/Go/Node/whatever and is published as an artifact, and this also has nothing correlated to secrets nor configuration. You should be able to run the same artifact (docker image or jar or whatever) – with different configurations and secrets for different environments.

While the article is good and technical, it skips over these parts. If you're just doing a toy service with no regard for anything of the above, then yeah, by all means just use SOPS and don't bother with vault. But if you're an organization, then don't read this assume that this works for 100s of services & engineers with differing CI/CD practices and schedules, and no luxury time to wait hours for a key=value change or waiting months for a full rotation.

Post reply on HN