Especially in the microservices era you should use a config server and never store your credentials in repository!
You should not use git smudge/clean filters for encryption. Why? Example!
Let’s create a example repository
% TMP=$(mktemp -d)
% cd $TMP
% git init
% echo 'Hello world!' > credentials
Add .gitattributes
/credentials filter=crypto
Add .git/config
[filter "crypto"]
smudge = openssl enc -aes-256-cbc -salt
clean = openssl enc -aes-256-cbc -salt
require
Note: require indicates that these commands need exit code 0 otherwise it could happen that these files are added though without any encryption. You can test this by using smudge = gpg -d -q –batch –no-tty -r <SIGNATURE> and clean = gpg -ea -q –batch -no-tty -r <SIGNATURE> filters.
Add file to to stage and commit
% git add .gitattributes credentials
% git add credentials
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
% git status
Changes to be committed:
new file: .gitattributes
new file: credentials
% git commit -m "Inital commit" [master (Basis-Commit) 860cedc] Initial commit
2 files changed, 2 insertions(+)
create mode 100644 .gitattributes
create mode 100644 credentials
Note: The .git/config for filters will not be added to the commit!
Clone the example repository
% TMP2=$(mktemp -d)
% git clone $TMP .
% cat credentials
Salted__��:�.��1٩�H��8��[��25%%
We now have an encrypted file without our repository. To decode it we need the clean command. On the other side anyone still can commit this file and break configuration.
Thoughts
- Yes, you can automate credentials encoding or decoding with filters.
- But you could also encode or decode manualy and check-in or -out. This makes not much difference!
- GitLab provides file locks. This probably makes sense as long as you use GitLab premium. Otherwise you might use git commit hooks.
- If you wanna use git repos to store credentuals and have them fully crypted you may have a look at [Git Annnex GCrypt](http://git-annex.branchable.com/tips/fully_encrypted_git_repositories_with_gcrypt/. Yet this is not based on git but a own project written in Haskell! It just uses the git-format!
- You’re doomed if you store your production credentials in clear text so every developer can read it.
- Credentials should never be stored in repositories!
- Use config servers and tools like consul for creating configs or directly pull the configs from the servers!
So, why all that circumstances?! This easily can get messed up. This is just a badly designed »solution« . Therefore I would call it only a »workaround« and no real solution!