
Never commit secrets into Git repos - gk1
https://datree.io/blog/secrets-management-git-version-control/
======
aequitas
Or make sure your secrets are transparently en/decrypted with GPG using:
[https://github.com/AGWA/git-crypt](https://github.com/AGWA/git-crypt) if you
really have to (and use [https://rtyley.github.io/bfg-repo-
cleaner/](https://rtyley.github.io/bfg-repo-cleaner/) to cleanup any history
of commited secrets).

An .envrc file with [https://pypi.org/project/keyring/#using-
keyring](https://pypi.org/project/keyring/#using-keyring) also provides a nice
solution for keeping secrets out of git for local development. Requires no
central server, only your local key storage (eg: keychain for macOS).

~~~
bbatha
> f you really have to (and use [https://rtyley.github.io/bfg-repo-
> cleaner/](https://rtyley.github.io/bfg-repo-cleaner/) to cleanup any history
> of commited secrets).

Don't bother. If you push a secret: Do not pass go. Do not collect $200. Just
rotate your secrets and move on. If you push your repo you should treat the
contents as public information.

~~~
aequitas
Correct, if you know it is public exposed. Our team had a private repo which
we wanted to make open source inside our company without exposing the secrets
stored there. In our case BFG saved us a lot of trouble and we could get this
feature out quickly instead of postponing it while waiting to rotate all keys.

------
hartator
> Everything should be encrypted both in transit and at rest. When your secret
> is encrypted, it is not available to the attacker and you can cut off access
> and rotate the plaintext secret to remedy the situation.

Not sure how valid this point is. If the attacker has access to a production
server, he had also access to all needed production keys. Encrypted or not.

------
pwinnski
Hashicorps Vault is great, but I'm amazed at how many of the answers to
questions happen to be "use our product." Pretty heavy-handed commercial for
Datree here.

------
jnty
> ALWAYS encrypt your secrets in transit and at rest

And the encryption secret for this is stored...how?

------
timeattack
[https://github.com/seletskiy/carcosa](https://github.com/seletskiy/carcosa)

------
adamrainsby
git repositories are not somehow incompatible with encryption.

------
umvi
That sounds like a lot of work. I don't see any problem with committing
secrets into git repositories if a) the git repo is not in the cloud, b) what
the secret is used for is not in the cloud either.

~~~
jb3689
I don't think it being in the cloud or not makes a difference. Applications
that aren't in the cloud can still be broken into. Leaving things in source
control just adds another surface for attackers to use to compromise your
applications

~~~
umvi
> I don't think it being in the cloud or not makes a difference. Applications
> that aren't in the cloud can still be broken into.

So if the attacker has already broken into our corporate networks and can
access the internal applications directly, what's to stop them from just
examining the environment variables directly to get the secrets from there?

I don't understand the added value of Vault. We have secrets committed to
internal GitLab where you need an LDAP account to even view/clone the repo.
The secrets are used for internal applications that make calls to external
APIs (like a weather service). If the attacker can gain access to the GitLab
source, surely it's equally trivial to just examine the environment variables
of the internal application itself since the secrets will be in plain text.

And if the secrets are not in plain text (i.e. you are passing the secret
encrypted), then surely the attacker need only examine the source code (which
we've established he has access to) to see how to decrypt the secret from the
environment variable.

Seems like an impossible chicken and egg problem.

