Jak mogę bezpiecznie zapisać moje tajne klucze i hasło w moim systemie kontroli wersji?

Zachowuję ważne ustawienia, takie jak nazwy hostów i porty serwerów programistycznych i produkcyjnych w moim systemie kontroli wersji. Ale wiem, że trzymanie tajemnic (takich jak klucze prywatne i hasła do baz danych) w repozytorium VCS jest złą praktyką .

Jednak hasła - jak każde inne ustawienie - wydają się być wersjonowane. Więc co to jest właściwy sposób kontrolowania wersji haseł?

Wyobrażam sobie, że wymagałoby to trzymania sekretów w ich własnym pliku „ustawień sekretów” oraz szyfrowania tego pliku i kontrolowania wersji. Ale jakie technologie? A jak to zrobić poprawnie? Czy jest na to lepszy sposób?

Generalnie zadaję pytanie, ale w moim konkretnym przypadku chciałbym przechowywać tajne klucze i hasła do witryny Django / Python za pomocą git i github .

Również, idealnym rozwiązaniem byłoby zrobić coś magicznego kiedy wciskam / pull z git - na przykład, jeśli zaszyfrowany plik haseł zmienia skrypt jest uruchamiany, które pyta o hasło i deszyfruje go na miejsce.

Masz rację, chcąc zaszyfrować swój poufny plik ustawień, zachowując jednocześnie kontrolę wersji. Jak wspomniałeś, najlepszym rozwiązaniem byłoby takie, w którym Git w sposób przejrzysty zaszyfruje niektóre poufne pliki po ich wysłaniu, aby lokalnie (tj. Na dowolnym komputerze, który ma Twój certyfikat), możesz użyć pliku ustawień, ale Git lub Dropbox lub ktokolwiek jest przechowywanie plików w VC nie daje możliwości odczytania informacji w postaci zwykłego tekstu.

Samouczek dotyczący przezroczystego szyfrowania / deszyfrowania podczas wypychania / ściągania

W tym streszczeniu https://gist.github.com/873637 pokazano samouczek dotyczący korzystania z sterownika smudge / clean filter Git z openssl do przezroczystego szyfrowania przesłanych plików. Musisz tylko przeprowadzić wstępną konfigurację.

Podsumowanie tego, jak to działa

Zasadniczo będziesz tworzyć .gitencryptfolder zawierający 3 skrypty bash,

clean_filter_openssl 
smudge_filter_openssl 
diff_filter_openssl 

które są używane przez Git do deszyfrowania, szyfrowania i obsługi różnic Git. Główne hasło i sól (naprawione!) Są zdefiniowane w tych skryptach i MUSISZ upewnić się, że plik .gitencrypt nigdy nie zostanie przesłany. Przykładowy clean_filter_opensslskrypt:

#!/bin/bash

SALT_FIXED=<your-salt> # 24 or less hex characters
PASS_FIXED=<your-passphrase>

openssl enc -base64 -aes-256-ecb -S $SALT_FIXED -k $PASS_FIXED

Podobnie dla smudge_filter_open_ssli diff_filter_oepnssl. Zobacz Gist.

Twoje repozytorium z poufnymi informacjami powinno mieć plik .gitattribute (niezaszyfrowany i zawarty w repozytorium), który odwołuje się do katalogu .gitencrypt (który zawiera wszystko, czego Git potrzebuje do zaszyfrowania / odszyfrowania projektu w sposób przejrzysty) i który jest obecny na twoim lokalnym komputerze.

.gitattribute zawartość:

* filter=openssl diff=openssl
[merge]
    renormalize = true

Na koniec musisz również dodać następującą zawartość do swojego .git/configpliku

[filter "openssl"]
    smudge = ~/.gitencrypt/smudge_filter_openssl
    clean = ~/.gitencrypt/clean_filter_openssl
[diff "openssl"]
    textconv = ~/.gitencrypt/diff_filter_openssl

Teraz, gdy wypychasz repozytorium zawierające poufne informacje do zdalnego repozytorium, pliki zostaną zaszyfrowane w sposób przezroczysty. Podczas ściągania z komputera lokalnego, który ma katalog .gitencrypt (zawierający Twoje hasło), pliki zostaną odszyfrowane w sposób przezroczysty.

Uwagi

Powinienem zauważyć, że ten samouczek nie opisuje sposobu tylko zaszyfrowania poufnego pliku ustawień. Spowoduje to przezroczyste zaszyfrowanie całego repozytorium, które jest przesłane do zdalnego hosta VC i odszyfrowanie całego repozytorium, aby zostało całkowicie odszyfrowane lokalnie. Aby osiągnąć pożądane zachowanie, możesz umieścić poufne pliki dla jednego lub wielu projektów w jednym sensitive_settings_repo. Możesz zbadać, jak ta przezroczysta technika szyfrowania działa z podmodułami Git http://git-scm.com/book/en/Git-Tools-Submodules, jeśli naprawdę potrzebujesz, aby poufne pliki znajdowały się w tym samym repozytorium.

Użycie stałego hasła mogłoby teoretycznie prowadzić do luk w zabezpieczeniach siłowych, gdyby atakujący mieli dostęp do wielu zaszyfrowanych repozytoriów / plików. IMO, prawdopodobieństwo tego jest bardzo niskie. Jak wspomniano na dole tego samouczka, nieużywanie stałego hasła spowoduje, że lokalne wersje repozytorium na różnych maszynach będą zawsze pokazywać, że zmiany zaszły ze statusem „git”.

Heroku popycha użycie zmiennych środowiskowych dla ustawień i tajnych kluczy:

Tradycyjne podejście do obsługi takich zmiennych konfiguracyjnych polega na umieszczeniu ich w źródle - w jakimś pliku właściwości. Jest to proces podatny na błędy i jest szczególnie skomplikowany w przypadku aplikacji typu open source, które często muszą utrzymywać oddzielne (i prywatne) gałęzie z konfiguracjami specyficznymi dla aplikacji.

Lepszym rozwiązaniem jest użycie zmiennych środowiskowych i trzymanie kluczy z dala od kodu. Na tradycyjnym hoście lub pracując lokalnie możesz ustawić zmienne środowiskowe w swoim bashrc. Na Heroku używasz zmiennych konfiguracyjnych.

Dzięki .envForemanowi i plikom Heroku zapewnia godny pozazdroszczenia zestaw narzędzi do eksportu, importu i synchronizacji zmiennych środowiskowych.

Osobiście uważam, że zapisywanie tajnych kluczy obok kodu jest niewłaściwe. Jest to zasadniczo niezgodne z kontrolą źródła, ponieważ klucze są przeznaczone dla usług zewnętrznych w kodzie . Jedynym dobrodziejstwem byłoby to, że programista może sklonować HEAD i uruchomić aplikację bez żadnej konfiguracji. Załóżmy jednak, że programista sprawdza historyczną wersję kodu. Ich kopia będzie zawierała hasło do bazy danych z zeszłego roku, więc aplikacja nie będzie działać w przypadku dzisiejszej bazy danych.

Dzięki powyższej metodzie Heroku programista może pobrać zeszłoroczną aplikację, skonfigurować ją przy użyciu dzisiejszych kluczy i pomyślnie uruchomić ją w dzisiejszej bazie danych.

Moim zdaniem najczystszym sposobem jest użycie zmiennych środowiskowych. Na przykład nie będziesz musiał zajmować się plikami .dist , a stan projektu w środowisku produkcyjnym byłby taki sam, jak na komputerze lokalnym.

Polecam przeczytanie rozdziału poświęconego konfiguracji aplikacji Twelve-Factor , pozostałe też, jeśli jesteś zainteresowany.

Opcją byłoby umieszczenie poświadczeń związanych z projektem w zaszyfrowanym kontenerze (TrueCrypt lub Keepass) i przesłanie go.

Zaktualizuj jako odpowiedź z mojego komentarza poniżej:

Przy okazji ciekawe pytanie. Właśnie znalazłem to: github.com/shadowhand/git-encrypt, który wygląda bardzo obiecująco w przypadku automatycznego szyfrowania

Sugeruję użycie do tego plików konfiguracyjnych i nie wersjonowanie ich.

Możesz jednak wersjonować przykłady plików.

Nie widzę problemu z udostępnianiem ustawień programistycznych. Z definicji nie powinien zawierać żadnych wartościowych danych.

Czarna skrzynka został niedawno wydany przez StackExchange i chociaż jeszcze go nie używałem, wydaje się, że dokładnie rozwiązuje problemy i obsługuje funkcje wymagane w tym pytaniu.

Z opisu na https://github.com/StackExchange/blackbox :

Bezpiecznie przechowuj sekrety w repozytorium VCS (np. Git lub Mercurial). Te polecenia ułatwiają szyfrowanie GPG określonych plików w repozytorium, dzięki czemu są one „zaszyfrowane w spoczynku” w repozytorium. Jednak skrypty ułatwiają ich odszyfrowanie, gdy trzeba je wyświetlić lub edytować, i odszyfrować w celu wykorzystania w produkcji.

Odkąd zadałem to pytanie zdecydowałem się na rozwiązanie, z którego korzystam przy tworzeniu małej aplikacji z małym zespołem ludzi.

git-crypt

git-crypt używa GPG do przezroczystego szyfrowania plików, gdy ich nazwy pasują do określonych wzorców. Na przykład, jeśli dodasz do .gitattributespliku ...

*.secret.* filter=git-crypt diff=git-crypt

... potem plik taki jak config.secret.json będzie zawsze przesyłany do zdalnego repozytorium z szyfrowaniem, ale pozostanie niezaszyfrowany w lokalnym systemie plików.

Jeśli chcę dodać nowy klucz GPG (osobę) do twojego repozytorium, który może odszyfrować chronione pliki, uruchom git-crypt add-gpg-user <gpg_user_key>. Tworzy to nowe zatwierdzenie. Nowy użytkownik będzie mógł odszyfrować kolejne zatwierdzenia.

Generalnie zadaję pytanie, ale w moim konkretnym przypadku chciałbym przechowywać tajne klucze i hasła do witryny Django / Python za pomocą git i github.

Nie, po prostu nie rób tego, nawet jeśli jest to twoje prywatne repozytorium i nigdy nie zamierzasz go udostępniać, nie rób tego.

Powinieneś stworzyć plik local_settings.py, umieścić go na VCS ignore iw swoim settings.py zrobić coś takiego

from local_settings import DATABASES, SECRET_KEY
DATABASES = DATABASES

SECRET_KEY = SECRET_KEY

Jeśli ustawienia twoich sekretów są tak wszechstronne, chętnie powiem, że robisz coś nie tak

EDYCJA: Zakładam, że chcesz śledzić poprzednie wersje haseł - powiedzmy, dla skryptu, który uniemożliwiłby ponowne użycie hasła itp.

Myślę, że GnuPG jest najlepszym rozwiązaniem - jest już używany w jednym projekcie związanym z git (git-Annex) do szyfrowania zawartości repozytorium przechowywanej w usługach w chmurze. GnuPG (gnu pgp) zapewnia bardzo silne szyfrowanie oparte na kluczach.

1. Trzymasz klucz na swoim lokalnym komputerze.
2. Dodajesz „moje hasło” do ignorowanych plików.
3. Na haku przed zatwierdzeniem szyfrujesz plik mypassword do pliku mypassword.gpg śledzonego przez git i dodajesz go do zatwierdzenia.
4. Po podłączeniu haka po prostu odszyfrowujesz mypassword.gpg do mypassword.

Teraz, jeśli twój plik „moje hasło” nie zmienił się, zaszyfrowanie da ten sam zaszyfrowany tekst i nie zostanie dodany do indeksu (brak redundancji). Najmniejsza modyfikacja mypassword skutkuje radykalnie innym zaszyfrowanym tekstem i mypassword.gpg w obszarze pomostowym bardzo różni się od tego w repozytorium, dlatego zostanie dodany do zatwierdzenia. Nawet jeśli napastnik zdobędzie twój klucz gpg, nadal musi złamać hasło. Jeśli atakujący uzyska dostęp do zdalnego repozytorium z zaszyfrowanym tekstem, może porównać kilka zaszyfrowanych tekstów, ale ich liczba nie będzie wystarczająca, aby dać mu jakąkolwiek istotną przewagę.

Później możesz użyć .gitattributes, aby zapewnić deszyfrowanie w locie w celu zakończenia git diff hasła.

Możesz także mieć oddzielne klucze dla różnych typów haseł itp.

Zwykle oddzielam hasło jako plik konfiguracyjny. i oddal je.

/yourapp
    main.py
    default.cfg.dist

A kiedy uruchomię main.py, umieść prawdziwe hasło w default.cfgskopiowanym.

ps. kiedy pracujesz z git lub hg. możesz zignorować *.cfgpliki do utworzenia .gitignorelub.hgignore

Zapewnij sposób na zastąpienie config

Jest to najlepszy sposób zarządzania zestawem rozsądnych ustawień domyślnych dla sprawdzanej konfiguracji bez konieczności jej kompletności lub zawierającej takie elementy, jak nazwy hostów i poświadczenia. Istnieje kilka sposobów na zastąpienie domyślnych konfiguracji.

Zmienne środowiskowe (jak już wspominali inni) są jednym ze sposobów na zrobienie tego.

Najlepszym sposobem jest poszukanie zewnętrznego pliku konfiguracyjnego, który zastępuje domyślne wartości konfiguracyjne. Pozwala to na zarządzanie zewnętrznymi konfiguracjami za pośrednictwem systemu zarządzania konfiguracją, takiego jak Chef, Puppet lub Cfengine. Zarządzanie konfiguracją jest standardową odpowiedzią w przypadku zarządzania konfiguracjami niezależnie od bazy kodu, więc nie musisz wykonywać wydania, aby zaktualizować konfigurację na jednym hoście lub w grupie hostów.

Do Twojej wiadomości: Szyfrowanie danych nie zawsze jest najlepszą praktyką, szczególnie w miejscach o ograniczonych zasobach. Może się zdarzyć, że szyfrowanie kredytów nie zapewni Ci dodatkowego ograniczenia ryzyka i po prostu doda niepotrzebną warstwę złożoności. Upewnij się, że wykonałeś odpowiednią analizę przed podjęciem decyzji.

Zaszyfruj plik haseł, używając na przykład GPG. Dodaj klucze na komputerze lokalnym i na serwerze. Odszyfruj plik i umieść go poza folderami repozytoriów.

Używam pliku passwords.conf, znajdującego się w moim folderze domowym. Przy każdym wdrożeniu ten plik jest aktualizowany.

Nie, klucze prywatne i hasła nie podlegają kontroli wersji. Nie ma powodu, aby obciążać wszystkich dostępem do odczytu do repozytorium znajomością poufnych danych uwierzytelniających usług używanych w produkcji, podczas gdy najprawdopodobniej nie wszyscy powinni mieć dostęp do tych usług.

Począwszy od Django 1.4, Twoje projekty Django są teraz dostarczane z project.wsgimodułem, który definiuje applicationobiekt i jest to idealne miejsce, aby zacząć wymuszać użycie project.localmodułu ustawień, który zawiera konfiguracje specyficzne dla witryny.

Ten moduł ustawień jest ignorowany podczas kontroli wersji, ale jego obecność jest wymagana podczas uruchamiania instancji projektu jako aplikacji WSGI, co jest typowe dla środowisk produkcyjnych. Tak to powinno wyglądać:

import os

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "project.local")

# This application object is used by the development server
# as well as any WSGI server configured to use this file.
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

Teraz możesz mieć local.pymoduł, którego właściciela i grupę można skonfigurować tak, aby tylko upoważniony personel i procesy Django mogły odczytywać zawartość pliku.

Jeśli potrzebujesz VCS dla swoich sekretów, powinieneś przynajmniej przechowywać je w drugim repozytorium oddzielonym od twojego rzeczywistego kodu. Możesz więc dać członkom swojego zespołu dostęp do repozytorium kodu źródłowego, tak aby nie widzieli Twoich poświadczeń. Ponadto umieść to repozytorium w innym miejscu (np. Na własnym serwerze z zaszyfrowanym systemem plików, a nie na github) i aby sprawdzić je w systemie produkcyjnym, możesz użyć czegoś takiego jak git-submodule .

Innym podejściem mogłoby być całkowite uniknięcie zapisywania sekretów w systemach kontroli wersji i zamiast tego użycie narzędzia takiego jak repozytorium z hashicorp , tajnego magazynu z rolowaniem klucza i audytem, ​​z interfejsem API i wbudowanym szyfrowaniem.

Tym się właśnie zajmuję:

• Zachowaj wszystkie sekrety jako zmienne env w $ HOME / .secrets (go-r perms), które źródła $ HOME / .bashrc (w ten sposób, jeśli otworzysz .bashrc przed kimś, nie zobaczą sekretów)
• Pliki konfiguracyjne są przechowywane w VCS jako szablony, takie jak config.properties przechowywane jako config.properties.tmpl

• Pliki szablonów zawierają symbol zastępczy dla klucza tajnego, na przykład:

  my.password = ## MOJE_HASŁO ##

• Podczas wdrażania aplikacji uruchamiany jest skrypt, który przekształca plik szablonu w plik docelowy, zastępując symbole zastępcze wartościami zmiennych środowiskowych, na przykład zmieniając ## MY_PASSWORD ## na wartość $ MOJE_HASŁO.

Możesz użyć EncFS, jeśli twój system to zapewnia. W ten sposób możesz zachować zaszyfrowane dane jako podfolder repozytorium, jednocześnie zapewniając aplikacji odszyfrowany widok danych zamontowanych na bok. Ponieważ szyfrowanie jest przezroczyste, nie są potrzebne żadne specjalne operacje w przypadku ściągania lub wypychania.

Wymagałoby to jednak zamontowania folderów EncFS, co może zrobić Twoja aplikacja na podstawie hasła przechowywanego w innym miejscu poza wersjonowanymi folderami (np. Zmienne środowiskowe).