Jak mogę otworzyć źródła aplikacji Railsowych bez podawania tajnych kluczy i poświadczeń aplikacji?

Question

Mam wiele aplikacji Railsowych hostowanych na GitHub. Wszystkie są obecnie prywatne, a ja często wdrażam je z ich repozytorium GitHub. Chciałbym móc zrobić niektóre z nich open source, tak jak te, które można znaleźć na http://opensourcerails.com.

Moje pytanie brzmi: jak mogę udostępnić te repozytoria bez ujawniania super tajnych danych uwierzytelniających?

Na przykład mogę zajrzeć do pliku /config/initializers/cookie_verification_secret.rb i zobaczyć tajny plik cookie dla prawie każdego z nich. Nie rozumiem, jak to jest dopuszczalne. Czy ci użytkownicy w jakiś sposób zmieniają te wartości w swoich środowiskach wdrażania?

Niektórzy użytkownicy ujawniają swoje tajemnice i klucz AWS! Inni zamiast tego ustawią swoje tajemnice AWS na coś takiego:

ENV['aws-secret'] 

, chociaż nie jestem pewien, w którym momencie ustawiają tę wartość.

Jakie są najlepsze praktyki związane z otwartym zaopatrzeniem aplikacji Railsowych bez wpływu na bezpieczeństwo aplikacji.

Answer 1

Niedawno zrobiłem to przez jedną z moich aplikacji. Moim rozwiązaniem było przechowywanie wszystkiego w tajemnicy w pliku konfiguracyjnym YAML ignorowanym przez Git, a następnie uzyskanie dostępu do tego pliku przy użyciu prostej klasy w katalogu inicjalizacyjnym. Plik konfiguracyjny jest przechowywany w folderze "udostępnionym" dla wdrożenia Capistrano i kopiowany do konfiguracji przy każdym wdrożeniu.

Config sklep: http://github.com/tsigo/jugglf/blob/master/config/initializers/juggernaut.rb

Przykład użycia: https://github.com/tsigo/jugglf/blob/6b91baae72fbe4b1f7efa2759bb472541546f7cf/config/initializers/session_store.rb

Można też usunąć z kontroli źródła całą historię pliku, który wykorzystał te tajne wartości. Oto poradnik do wykonania tego w Git, którego użyłem: http://help.github.com/removing-sensitive-data/

Answer 2

Nie przechowywać żadnej tajnej wartości. W dowolnym momencie historii repozytorium Git.
Wartości te powinny być przechowywane w innym miejscu, pozostawiając tylko szablon pliki konfiguracyjne wersji, wraz ze scenariuszem potrafi:

• odczytać odpowiednie wartości z repo zewnętrznego
• i budować ostateczny plik konfiguracyjny kompletny (z tajne wartości)

Utrzymując oddzielny zbiór danych (źródła po jednej stronie, tajne wartości po drugiej), można następnie otworzyć źródło repo źródła bez żadnych tajemnic.

Answer 3

[EDYCJA - Poniższa metoda powoduje irytację konieczności przełączania się do gałęzi Produkcja w celu uruchomienia "serwera rails" w celu włączenia niezbędnych plików cookie. Tak więc, wprowadzanie zmian, gdy serwer jest trudny ... i wciąż szukam dobrego rozwiązania]

Po dalszych badaniach wydaje mi się, że rozwiązaniem, którego szukałem, było wykluczenie wszystkiego, co zawierało tajną wartość Git repo's master branch (tak jak powiedział @VonC). Ale zamiast czytać z tych plików w oddzielnym repo, po prostu tworzę nową gałąź "produkcji" i dodaję do niej.

W ten sposób są wykluczeni z programu Master i mogę je przekazać Githubowi lub innym publicznym repo w porządku.Kiedy jestem gotowy do wdrożenia, mogę wykupić gałąź Produkcji i połączyć ją z Master i wdrożyć produkcję.

Muszę być w stanie to zrobić, ponieważ Heroku i inni gospodarze wymagają jednego repozytorium git, które zostanie przekazane na ich serwery.

Więcej informacji tutaj:

http://groups.google.com/group/heroku/browse_thread/thread/d7b1aecb42696568/26d5249204c70574

Answer 4

I rzeczywiście wziął podpowiedź z pytaniem, używając ENV.

Miałem trzy różne tajne wartości, których nie chciałem udostępnić. To oczywiście tajny token aplikacji i klucz i tajemnica Twittera. W moim tajnym inicjalizatorze tokenów:

KinTwit::Application.config.secret_token = ENV['SECRET_TOKEN'] 

Twitter.consumer_key      = ENV['CONSUMER_KEY'] 
Twitter.consumer_secret     = ENV['CONSUMER_SECRET'] 

Jestem gospodarzem mojego projektu na Heroku, więc dodałem te zmienne konfiguracyjne do Heroku.

[03:07:48] [william@enterprise ~/dev/rwc/kintwit]$ heroku config:add CONSUMER_KEY=ub3rs3cr3tk3y 
Adding config vars and restarting app... done, v7 
    CONSUMER_KEY => ub3rs3cr3tk3y 
[03:08:40] [william@enterprise ~/dev/rwc/kintwit]$ heroku config:add CONSUMER_SECRET=ub3rs3cr3tk3y 
Adding config vars and restarting app... done, v8 
    CONSUMER_SECRET => ub3rs3cr3tk3y 
[03:08:57] [william@enterprise ~/dev/rwc/kintwit]$ heroku config:add SECRET_TOKEN=ub3rs3cr3tk3y 
Adding config vars and restarting app... done, v9 
    SECRET_TOKEN => ub3rs3cr3tk3y 

Teraz wartości są gotowe do następnego naciśnięcia. Ale co jeśli nie używasz Heroku? Oczywiście nie jestem ekspertem w zakresie wdrażania pojedynczych szyn (jeesh, nawet nie Heroku pro), ale przykładem może być wykonanie db: migracja do testowania.

$ RAILS_ENV=test rake db:migrate 

KEY = para wartości przed komenda ustawia zmienną środowiskową, więc uruchomienie tego polecenia, by wydrukować testecho ENV['RAILS_ENV']. Tak więc to jest skonfigurowane w twoim środowisku, tak jak byś to zrobił. Ale zmienne środowiskowe nie znajdują się w twoim kodzie, więc to jest podstęp.

Answer 5

Jeśli korzystasz z usług majstra, umieść plik .env w katalogu głównym aplikacji. (foreman docs)

.env będzie miał

AWS_SECRET=xxx 
AWS_ACCESS=yyy 

Wtedy, gdy trzeba użyć klawiszy, wkładka:

ENV['AWS_SECRET'] 
ENV['AWS_ACCESS'] 

Choć ważne jest, aby nie popełnić tego .env do swojej kontroli wersji. Więc jeśli używasz gita, dodaj .env do swojego .gitignore.

---

Bonus runda! - Heroku

Po wdrożeniu w Heroku, te zmienne środowiskowe muszą być również skonfigurowane w środowisku Heroku. Istnieją dwie opcje:

1. ręcznie dodać klucze za pomocą polecenia
2. Użyj heroku-config gem synchronizować lokalne zmienne środowiskowe, w obie strony heroku config:add.