This project scares me because it helps foster a bad practice -- keeping secrets in a repo. You really shouldn't be keeping secrets in the repo.
You should be using a secrets service that is designed for such a purpose, like Hashicorp's Vault[0], so that you never have to keep a secret in the code.
Storing secrets in a repository with non-secrets is bad, because access is pre-repo, and it would hurt your ability to limit secret access to the smallest possible audience.
Access is per-repo, so if you have enough secrets and disparate interested parties, the number of required repos could make a dedicated alternative far more manageable.
Agree, also check out credstash[0], a very good and secure solution if you are running on AWS. Credstash is an small utility that encrypt with KMS and store the ciphertext of the datakey and secret on Dynamodb.
I configure my application roles to be able to decrypt with the master key and I restrict what ciphertext they can read from Dynamodb.
It's a bad practice, because git makes keys practically irrevocable. It's not enough to rotate encryption keys, because the old ciphertexts are in the git history; you have to rotate the underlying secrets as well (people don't do this and shouldn't have to).
Don't store encrypted secrets in git if you can avoid it.
No, this forces you to rotate your secrets because you don't get to pretend that losing access to the repo means losing access to the secrets. While dynamic secrets are best, static secrets (like API keys) should be stored in version control.
When someone has unintended access to secrets (for example, the developer you just fired), you need to rotate both the key and secrets to have any semblance of security. Ideally you use deterministic encryption to create the secrets too.
We agree that if you store secrets in a repo, any time you change the encryption key, you have to go and purge the underlying secrets. We disagree that this is intuitive or that shops do this reliably.
We should be able to agree that not storing secrets in your repo dodges all these problems nicely.
Well, I disagree. It doesn't matter where you store them, repo or not: even if they're not in a "repo", they're stored somewhere, and when you revoke access from someone to that somewhere, you still have the same problem: the party that you're revoking access from had access at one point. For all you know, they copied the secret while they had access. You can't "revoke" information from someone's mind: you MUST rotate the secret to accomplish that.
If anything, I like the git repo idea b/c — presuming that the repository stores a history of who had access to what, when — it removes the question of whether you need to rotate a secret. You can look at the history, and if the secret didn't get rotated when access was removed or at some time afterwards, you know you're not secure.
Compare that to say, a random file somewhere, say on a deployment node in deployment code, or alongside that code so as to keep it out of a repo, that just keeps the latest copy of the secrets, where one doesn't know when access was revoked. Do the keys need rotation?
If you use a purpose built storage though then you can deny access to the actual keys to just about everyone, so if a developer leaves then they won't have the keys, and if they do you'll know because it will have a built in audit trail. And in many cases you never have to release the key from the purpose built store because it takes in crypto text and gives out plain text without ever revealing the key to the user.
They'll have their own key, which will be revoked from the store, and they might have a single key that machines use to access the store. You should be rotating that machine key all the time anyway, so rotating once more when a dev leaves isn't a big deal. It's also much easier than rotating all of your actual keys, which in many cases is generated by a third party that may make such a thing very hard.
What you are describing is how to remove _access_ to the secret. The issue here is, that the former employee still has _knowledge_ of the secret. Hence you have to rotate the secret.
Plenty of companies choose to accept the risk that an employee might have memorized a secret, but not accept the risk that the employee's secret-encrypting-key might leak at any point for the lifetime of the repository.
Obviously, nothing you do w/r/t secret storage is going to resolve the problem of what's in your employees' heads.
In this case state of access control is stored along with code/secrets. The problem is that ACLs, secrets themselves and code change independently of each other. This only works if you assume no downgrading and homogeneous versioning across all instances.
You're forgetting that if I have been storing all of the encrypted traffic all along and then get access to the keys I can unlock all of the history too. Once a secret is out of use it should be purged completely. This is why secrets should be stored on ephemeral storage if at all possible. This is however pretty advance for many people.
The page says "When someone is out - just delete his public key, reencrypt the files, and he won’t be able to decrypt secrets anymore." but doesn't talk about rotating the secrets.
Second that, if there are many people having access to the repository and you maintain repo's history, rotating encryption keys and secrets won't save you, unless you also delete the whole history and do some major updates to the files.
Someone can answer to that that he can put the ciphertests in a separate repository and limit repo's access to only deployment server/user, but that completely invalidates the goal.
The problem is you need some repository to store this information and it's incredibly helpful to store the configuration along with the code.
If someone has access to a shared secret and then shouldn't you should assume the secret is now compromised and rotate it. Rotating the keys doesn't solve this problem.
No. If that were the case, there would be no purpose to rotating keys. The problem is that despite rotating keys, your old crypto keys have permanent access to secrets, because the old ciphertexts are by default retained in the git history.
It's a bad idea to store secrets in any form in your source code repository.
I think what grandparent and others are saying is that you also revoke the secrets contained in the ciphertext, e.g. if it's an AWS key you would revoke that AWS key on AWS's side as well as encrypting new secrets with a different encryption key.
Obviously this is a huge hassle and isn't easily done with all kinds of secrets (which is what I think you're getting at?). But it's also often necessary.
> The problem is you need some repository to store this information
This doesn't have to be a Git repository, nor does it have to be the same repository as the code which uses the secrets.
> it's incredibly helpful to store the configuration along with the code
It's helpful, but ultimately means that the ciphertext is potentially available to the world and existing keys may decipher it in perpetuity. Thus this is not a recommended tradeoff to make.
It is helpful to store configuration with code, but you don't have to include secret values in your code. It's much better to use a purpose built service like credstash[0] to store secret values while you keep the name of the secret and (possibly) version in a repo with your code.
>you have to rotate the underlying secrets as well (people don't do this and shouldn't have to).
How is that different from the case of an employee having written down the secrets and leaving the company later on? In both cases the employee has had access to the secrets and in both cases the only way to be secure is to change them.
why shouldn't people have to rotate the underlying secrets?
a rogue employee who created a secret, or any engineer who had to access that secret to get their job done, is always going to be able to use that secret value, regardless of where the encrypted blob is stored.
seems like we should be making it easier to rotate secret values often and automatically.
Doesn't the OP say that secrets aren't allowed to be stored unless they're in the gitignore file? Does this mean they're somehow not storing the secret's history? Say by rewriting the history of those particular files in the .gitsecrets file every time they're committed so they've only got the lastedt version?
In addition to what others are saying, for many types of secrets (API credentials, salts, keys, etc.) it's good practice to make them different in production vs development. This has the advantage of keeping your production secrets in the domain of ops, and your developers never even need to have them.
This is built on the assumption that you only ever have one set of secrets, or that you don't mind distributing your prod secrets to your engineers, both of which I would consider to be bad practice.
You should be using a secrets service that is designed for such a purpose, like Hashicorp's Vault[0], so that you never have to keep a secret in the code.
[0] https://github.com/hashicorp/vault