31–39 of 39 posts
Vault from hashicorp was built to solve the use case described in the article. However, encrypting source code, in general, especially from hosting services like github is still a valid use case for many scenarios. GitZero attempts to solve it, but it provides no specific guarantees that the source code (for free tier) is inaccessible to the hosting service
Earlier quoted context omitted.
Why not store your remote state in S3 buckets? They support encryption at rest.
Then you need a different secret in the application: the key to the data in the S3 buckets. Ultimately, you have to supply at least one secret to the application at runtime, and then it can bootstrap its way to others if needed.
Once the code was pushed to those servers, the clean filter would use the private ssh key of the host key pair to decrypt the secrets.
Don't keep encrypted secrets in your git repositories, if for no other reason than that it makes access revocation deceptively difficult --- but also because it encourages you to have a development team in which ordinary devs have a full complement of secrets on their laptops at all times. Instead, keep secrets "out of band" and supply them to applications as part of your deployment process.
Just curious - what's the preferred way of passing secrets from the deployment process to the application? Environment variables? Simple to use and understand but can leak to child processes and crash reports. Files on disk? Usually can also be read by children. Via stdin on app startup? Seems simple... Some other way?
For it to get into the environment or stdin it has to be stored somewhere.
Where is that somewhere and how do you access it?
Ideally the secrets, and the keys to access them would never be accessible directly by the person who initiated the deployment; they'd be fetched directly from where they're stored to where they're deployed.
git-crypt can be a part of this.
More likely you'd something purpose built like many of the solutions mentioned in this discussion. If you want something commercial then you might consider https://thycotic.com/ Secret Server.
If not then there is a open source Python based server which uses Shamir's Secret Sharing Scheme. (But apologies I've lost the url)
Earlier quoted context omitted.
Just curious - what's the preferred way of passing secrets from the deployment process to the application? Environment variables? Simple to use and understand but can leak to child processes and crash reports. Files on disk? Usually can also be read by children. Via stdin on app startup? Seems simple... Some other way?
https://www.torus.sh/ is built for exactly that.
You just have to name your envs in torus TF_VAR_NAMEOFTHING so that terraform pics up on them.
However, I must say I disagree with the sentiment that separation of secrets from source code is a bad thing. Git-crypt and similar tools use git for versioning. While this sounds great, it is not desirable for key management. Software and secrets have different management cycles. You always want to keep a copy of past software versions, but this is not the case for secrets. For instance, what if you want to make sure a secret is deleted? It will be a hard challenge to remove this from the git history on all copies of the repo.
As commented before, separating your development workflow from your secret management flow is actually a must. Not only are the management cycles different, the access policies also differ. Giving only a few trusted individuals access to the encrypted bag inside your git repo may work for a very small team with a few similar servers. However, when you have multiple sets of people and services that need access to different sets of secrets, controlling who has access to what secrets with these encrypted data bags quickly becomes impractical.
I agree with tptacek, having a decoupled and secure place to manage and distribute secrets is more secure and scales better. At SecretHub we allow access control per secret or secret-group to solve this complex mapping problem. We believe it should be easy for developers to create secrets, but only easy for machines to use them. Developers rarely need access to secrets in production.
Take a look at our website to find out more: https://secrethub.io
Disclaimer: I'm the co-founder of https://secrethub.io, an encrypted SaaS to help teams manage and distribute secrets.
Earlier quoted context omitted.
We ran into this problem with terraform and we needed a fix quickly. The problem is that they recommend you check in your .tfstate files, which does make sense; they do need to be synchronized between everyone who might be working on the repo. However, we learned later down the line that in some cases, the state files might contain secrets. So we rolled out git-crypt for all .tfstate files to future-proof ourself aga…
Why not store your remote state in S3 buckets? They support encryption at rest.
> As long as you authenticate your request and you have access permissions, there is no difference in the way you access encrypted or unencrypted objects.
The only advantage of S3 encryption is that if someone walks out of the data center with a disk, they can't read the data on it.
Earlier quoted context omitted.
> "The simplest hack is to use a configuration management tool" > "You can also use a credential management suite for a more robust solution" You have to start somewhere, this is why automated system with credentials isn't a simple task to solve. Imagine this, you use consul to store your secrets, as you wrote up a script for Ansible to look things up, this include secrets. Great, but you need to authorize. So you ne…
>> "The simplest hack is to use a configuration management tool" >> "You can also use a credential management suite for a more robust solution" > Imagine this, you use consul to store your secrets, as you wrote up a script for Ansible to look things up, this include secrets. Great, but you need to authorize. So you need to keep the token somewhere. You see, the problem springs from you mistaking Ansible for configura…
Ansible can also use configuration templates just fine. It can also support secrets management, depending on how you want to store the secrets. The first tool covered in the series itself was Credstash (https://tozny.com/blog/crypto-tools-for-devops-credstash/). Ansible supports retrieving secrets from Credstash natively, either for use in commands or when populating templates: http://docs.ansible.com/ansible/playbooks_lookups.html#the-c...
Git-crypt is but one solution for storing secrets _next to_ the code that uses them. Credstash is another for storing secrets in another, server-accessible location. Both can work with tools like Ansible (or Puppet or Chef or Salt).
From the tone of the above (and your other responses) you're not a heavy Ansible user. That's fine. Use the tool you're comfortable with. But don't try to turn people away from an equally useable alternative to something you _do_ use just because it's not your tool of choice.
Vault from hashicorp was built to solve the use case described in the article. However, encrypting source code, in general, especially from hosting services like github is still a valid use case for many scenarios. GitZero attempts to solve it, but it provides no specific guarantees that the source code (for free tier) is inaccessible to the hosting service