As soon as developers have access to the production credentials it's game over. Auditability is gone. Passwords end-up being stored in various password stores and plain files because it's convenient. Developers connect to the production system and start doing live changes.
Hashicorp Vault is more difficult to put in place but it does the right thing. With it's custom backend it can generate temporary tokens, for example to access the database. Those token are short-lived and part of the audit log.
With Torus, you can use our fine grained access controls to model exactly how your organization divvies up access and responsibilities. You can give a team (users or machines) access to everything, a specific environment, or even a specific service instance within an environment.
Only users or machines with explicit access can retrieve the encrypted secrets from our servers and they are never written to disk in plain-text.
With our worklog(1) feature, we make it really easy to rotate secrets when a team member leaves, commits them to git by accident, or a machine is compromised by listing out every secret they could access cryptographically.
For small teams and deployments, we want to make it easy for them to keep their secrets out of git without having to securely manage and deploy heavier tooling such as Vault or Keywhiz.
Do you know any good resources on this topic that can be easily picked up by small teams? Most resources I've seen assume you have access to huge clusters of hardware and plenty of people to setup and maintain everything. But what if you're bootstraping a project with some friends?
Heck, how do people manage their personal credentials and secrets? I have a few computers, and I usually copy over a few PGP keys, SSH keys, and API keys. For regular credentials, I use a password manager which syncs through a cloud data storage system.
One of the best sites I've found for learning about security-related topics is the NIST CSRC [0]. They cover a huge variety of topics, with varying levels of detail. I've found many of their publications to be very approachable. For example, they usually include a glossary of terms and acronyms, along with examples to help you understand the problem. Also, unlike what you find in many popular books or random online blogs, they actually cover varying edge-cases and discuss an example of what a real-world solution could do. I love that because it gives you a reasonable starting point for when you don't know any better. The only problem is that their content generally isn't written with personal usage or small teams in mind.
The idea is not new. Back in the 1980s I worked at a job where access to live production systems was tightly controlled and audited. Developers could get access, but passwords were short-lived and everything was logged.
Hashi Vault isn't that difficult to setup, especially for smaller setups, it's basically just a binary you run, with the file backend. You still get the auditing goodness, etc. Otherwise I agree with what else you said.
Looks interesting. I'll definitely take a look at how this compares to Hashicorp Vault. Definitely getting closer and closer to the point where I can start to properly utilize a tool like this.
Reading the docs, though, it does seem like it's one legendary AWS outage away from being a huge problem:
>Torus’s infrastructure has been designed from the ground up for resilience without any single point of failure. All of our services are autoscaled and run in multiple availability zones in the us-east-1 region.
As long as everything's encrypted on the client-side (and the client's source code is available for public audit), I don't see any immediate concerns besides the obvious one of "what happens if Torus goes under?".
It looks like there are plans to open-source the server, though, so that problem can be solved if you want to host your own Torus deployment (which I'd likely do for any serious non-personal usage).
We've used Torus a fair bit in my team at work, however we're now using Docker's native secrets solution for our container runtimes as it avoids the knowledge and build-time overhead of an extra dependency.
I personally found the experience of using Torus to be great. Getting a quick working setup is easy and it doesn't take much effort to transition from there to locked down access control. Will likely continue using it outside of the Docker context.
I've been using Blackbox and it has been great. It encrypts files directly in your VCS. We've setup the deploy pipeline to decrypt secret config files and then deploy to servers.
Looks interesting. I probably need to get my hands dirty to understand how it's different from Hashicorp's Vault. A quick glance says it's a cloud-based solution with simpler UX. I see only client binaries and sign-up instructions. There are no server setup instructions.
At Manifold(1), we built Torus from the ground-up to solve a consistent pain when building cloud apps: securely storing, sharing, and rotating secrets used to build, run, and deploy code. Our goal is to make it simple for anyone, not just the security savvy, to keep their secrets out of git and off disk.
To do this, we designed our security model (host and cryptography architecture) for hosting in the cloud to ensure we never have access to any of the keys used to encrypt or sign secrets — they’re derived from a user’s password and never forwarded along. We’ve posted more information in our documentation(2).
The server is currently closed source, with plans to open source it. The client (where all cryptographic operations happen) is open source.
Very strange navigation behaviour: enabled JS, and then clicking e.g. 'Docs' modifies the URL in address bar, but requires a manual refresh to actually load the docs page...
Doesn't solve the lack of mobile support, but hopefully the fact that the client-side code is already free software (and under a liberal license, to boot) means that the community can fix that problem if all else fails.
zimbatm|8 years ago
Hashicorp Vault is more difficult to put in place but it does the right thing. With it's custom backend it can generate temporary tokens, for example to access the database. Those token are short-lived and part of the audit log.
ianl|8 years ago
Only users or machines with explicit access can retrieve the encrypted secrets from our servers and they are never written to disk in plain-text.
With our worklog(1) feature, we make it really easy to rotate secrets when a team member leaves, commits them to git by accident, or a machine is compromised by listing out every secret they could access cryptographically.
For small teams and deployments, we want to make it easy for them to keep their secrets out of git without having to securely manage and deploy heavier tooling such as Vault or Keywhiz.
1) https://www.torus.sh/docs/latest/commands/organizations#work...
newmac|8 years ago
They seem to have pretty serious access control (Orgs, Teams) and a Policy based access control system.
TheAceOfHearts|8 years ago
Heck, how do people manage their personal credentials and secrets? I have a few computers, and I usually copy over a few PGP keys, SSH keys, and API keys. For regular credentials, I use a password manager which syncs through a cloud data storage system.
One of the best sites I've found for learning about security-related topics is the NIST CSRC [0]. They cover a huge variety of topics, with varying levels of detail. I've found many of their publications to be very approachable. For example, they usually include a glossary of terms and acronyms, along with examples to help you understand the problem. Also, unlike what you find in many popular books or random online blogs, they actually cover varying edge-cases and discuss an example of what a real-world solution could do. I love that because it gives you a reasonable starting point for when you don't know any better. The only problem is that their content generally isn't written with personal usage or small teams in mind.
[0] https://beta.csrc.nist.gov
ams6110|8 years ago
zie|8 years ago
TheSwordsman|8 years ago
Reading the docs, though, it does seem like it's one legendary AWS outage away from being a huge problem:
>Torus’s infrastructure has been designed from the ground up for resilience without any single point of failure. All of our services are autoscaled and run in multiple availability zones in the us-east-1 region.
BlackjackCF|8 years ago
Maybe it's not a good idea to launch in the default region.
empath75|8 years ago
tptacek|8 years ago
momania|8 years ago
yellowapple|8 years ago
It looks like there are plans to open-source the server, though, so that problem can be solved if you want to host your own Torus deployment (which I'd likely do for any serious non-personal usage).
wyqydsyq|8 years ago
I personally found the experience of using Torus to be great. Getting a quick working setup is easy and it doesn't take much effort to transition from there to locked down access control. Will likely continue using it outside of the Docker context.
owaislone|8 years ago
https://github.com/StackExchange/blackbox
m_sahaf|8 years ago
ianl|8 years ago
To do this, we designed our security model (host and cryptography architecture) for hosting in the cloud to ensure we never have access to any of the keys used to encrypt or sign secrets — they’re derived from a user’s password and never forwarded along. We’ve posted more information in our documentation(2).
The server is currently closed source, with plans to open source it. The client (where all cryptographic operations happen) is open source.
1) https://www.manifold.co/ 2) https://www.torus.sh/docs/latest/internals/crypto
newmac|8 years ago
OJFord|8 years ago
Corristowolf|8 years ago
[deleted]
skrowl|8 years ago
yellowapple|8 years ago
Doesn't solve the lack of mobile support, but hopefully the fact that the client-side code is already free software (and under a liberal license, to boot) means that the community can fix that problem if all else fails.