Pytanie W jaki sposób pliki tajne powinny zostać przekazane do aplikacji EC2 Ruby on Rails, korzystając z serwisów amazon z elastyczną zasłoną fasoli?


W jaki sposób pliki tajne powinny zostać przekazane do aplikacji EC2 Ruby on Rails, korzystając z serwisów amazon z elastyczną zasłoną fasoli?

Dodaję pliki do repozytorium git i pcham do github, ale chcę zachować moje tajne pliki z repozytorium git. Wdrażam do aws używając:

git aws.push

Następujące pliki znajdują się w .gitignore:

/config/database.yml
/config/initializers/omniauth.rb
/config/initializers/secret_token.rb

Podążając za tym łączem, próbowałem dodać plik S3 do mojego wdrożenia: http://docs.amazonwebservices.com/elasticbeanstalk/latest/dg/customize-containers.html

Cytując z tego linku:

Przykładowy fragment

Poniższy przykład pobiera plik zip z zasobnika Amazon S3 i rozpakowuje go do / etc / myapp:

sources:  
    /etc/myapp: http://s3.amazonaws.com/mybucket/myobject 

Postępując zgodnie z tymi wskazówkami, załadowałem plik do wiadra S3 i dodałem do pliku private.config w katalogu .ebextensions:

sources:
  /var/app/current/: https://s3.amazonaws.com/mybucket/config.tar.gz

Ten plik config.tar.gz zostanie rozpakowany do:

/config/database.yml
/config/initializers/omniauth.rb
/config/initializers/secret_token.rb

Jednak po wdrożeniu aplikacji plik config.tar.gz na hoście S3 nigdy nie jest kopiowany ani rozpakowywany. Nadal dostaję błędy, że nie można zlokalizować pliku database.yml, a dziennik EC2 nie ma zapisu pliku konfiguracyjnego, tutaj jest komunikat o błędzie:

Error message:
  No such file or directory - /var/app/current/config/database.yml
Exception class:
  Errno::ENOENT
Application root:
  /var/app/current

12
2017-12-20 21:34


pochodzenie




Odpowiedzi:


Możliwe jest (i łatwe) przechowywanie wrażliwych plików w S3 i ich automatyczne kopiowanie do instancji Beanstalk.

Podczas tworzenia aplikacji Beanstalk automatycznie tworzone jest wiadro S3. Ten zasobnik służy do przechowywania wersji aplikacji, dzienników, metadanych itp.

Domyślny aws-elasticbeanstalk-ec2-role przypisane do środowiska Beanstalk ma prawa odczytu do tego zasobnika.

Wszystko, co musisz zrobić, to umieścić swoje wrażliwe pliki w tym segmencie (albo w katalogu głównym wiadra, albo w dowolnej strukturze katalogów) i utworzyć .ebextension plik konfiguracyjny, aby skopiować je do instancji EC2.

Oto przykład:

# .ebextensions/sensitive_files.config

Resources:
  AWSEBAutoScalingGroup:
    Metadata:
      AWS::CloudFormation::Authentication:
        S3Auth:
          type: "s3"
          buckets: ["elasticbeanstalk-us-east-1-XXX"] # Replace with your bucket name
          roleName: 
            "Fn::GetOptionSetting": 
              Namespace: "aws:autoscaling:launchconfiguration"
              OptionName: "IamInstanceProfile"
              DefaultValue: "aws-elasticbeanstalk-ec2-role" # This is the default role created for you when creating a new Beanstalk environment. Change it if you are using a custom role

files:
  /etc/pki/tls/certs/server.key: # This is where the file will be copied on the EC2 instances
    mode: "000400" # Apply restrictive permissions to the file
    owner: root # Or nodejs, or whatever suits your needs
    group: root # Or nodejs, or whatever suits your needs
    authentication: "S3Auth"
    source: https://s3-us-west-2.amazonaws.com/elasticbeanstalk-us-east-1-XXX/server.key # URL to the file in S3

Zostało to udokumentowane tutaj: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/https-storingprivatekeys.html


1
2017-09-29 14:22





"Właściwy" sposób na zrobienie tego, co myślę, że chcesz zrobić, to używać ról IAM. Tutaj możesz zobaczyć post na blogu: http://aws.typepad.com/aws/aws-iam/

Zasadniczo pozwala na uruchomienie instancji EC2 bez umieszczania jakichkolwiek osobistych danych uwierzytelniających w żadnym pliku konfiguracyjnym. Po uruchomieniu instancji zostanie przypisana dana rola (zestaw uprawnień do korzystania z zasobów AWS), a rotacyjne poświadczenie zostanie automatycznie umieszczone na komputerze za pomocą Amazon IAM.


2
2017-12-21 15:51





Aby mieć .ebextension/*.config pliki mogą pobierać pliki z S3, musiałyby być publiczne. Biorąc pod uwagę, że zawierają poufne informacje, jest to zły pomysł.

Możesz uruchomić instancję Elastic Beanstalk z rolą instancjii możesz nadać tej roli uprawnienia dostępu do plików, których dotyczy problem. Niestety file: i sources: sekcje .ebextension/*.config pliki nie mają bezpośredniego dostępu do korzystania z tej roli.

Powinieneś być w stanie napisać prosty skrypt używając AWS :: S3 :: S3Object klasa AWS SDK dla Ruby aby pobrać pliki i użyć a command: zamiast sources:. Jeśli nie określisz poświadczeń, pakiet SDK automatycznie spróbuje użyć tej roli.

Będziesz musiał dodać politykę do swojej roli, która pozwoli ci pobrać specjalnie interesujące pliki. Wyglądałoby to tak:

{                       
  "Statement": [
    {
    "Effect": "Allow",
     "Action": "s3:GetObject",
     "Resource": "arn:aws:s3:::mybucket/*"
    }
  ]
}

Wtedy możesz zrobić coś takiego w swoim .config plik

files:
  /usr/local/bin/downloadScript.rb: http://s3.amazonaws.com/mybucket/downloadScript.rb
commands:
  01-download-config:
    command: ruby /usr/local/downloadScript.rb http://s3.amazonaws.com/mybucket/config.tar.gz /tmp
  02-unzip-config:
    command: tar xvf /tmp/config.tar.gz
    cwd: /var/app/current

2
2018-05-31 22:29





Używanie zmiennych środowiskowych jest dobrym podejściem. Hasła referencyjne w środowisku, a więc w pliku yaml:

password: <%= ENV['DATABASE_PASSWORD'] %>

Następnie ustaw je na instancji bezpośrednio za pomocą eb lub konsoli.

Możesz martwić się, że takie poufne informacje będą łatwo dostępne w środowisku. Jeśli proces zagraża twojemu systemowi, prawdopodobnie może uzyskać hasło bez względu na to, gdzie ono się znajduje. Takie podejście jest używane przez wielu dostawców PaaS, takich jak Heroku.


1
2018-05-31 13:16





Stamtąd dokument bezpieczeństwa Amazon EC2 obsługuje TrueCrypt dla szyfrowania plików i SSL dla danych w tranzycie. Sprawdź te dokumenty

Możesz przesłać instancję serwera z zaszyfrowanym dyskiem lub możesz użyć prywatnego repo (myślę, że to kosztuje github, ale są alternatywy)


0
2017-12-20 21:53



Cóż, myślę, że jedną z największych rzeczy jest zapewnienie prawidłowych uprawnień i że aplikacja żądająca plików z S3 ma odpowiednie uprawnienia, ale obie działają pod moim użytkownikiem i mam uprawnienia do plików, więc " m nie wiem, jak powiedzieć, czy to jest problem. - nikc


Myślę, że najlepszym sposobem nie jest hakowanie AWS (ustawianie haków, przesyłanie plików). Po prostu użyj zmiennych ENV.

Użyj gem 'dot-env' do rozwoju (to jest <% = ENV ['LOCAL_DB_USERNAME']%> w 'config / database.yml') i domyślnej konsoli AWS do ustawienia zmiennych w Beanstalk.


0
2018-04-26 16:12





Wiem, że to stary post, ale nigdzie nie mogłem znaleźć innej odpowiedzi, więc wypaliłem olej o północy, żeby go wymyślić. Mam nadzieję, że zaoszczędzi ci to kilka godzin.

Zgodziłem się z twórcami, którzy napisali, ile PITA ma zmusić programistów do umieszczenia varów ENV w ich lokalnej bazie danych dev.yml. Wiem, że klejnot dotenv jest przyjemny, ale nadal musisz utrzymywać vary ENV, co zwiększa czas potrzebny na podniesienie stacji.

Moim podejściem jest przechowywanie pliku database.yml na S3 w zasobniku utworzonym przez EB, a następnie użycie pliku konfiguracyjnego .ebextensions w celu utworzenia skryptu w katalogu pre hook serwera, aby był on wykonywany po rozpakowaniu do katalogu pomostowego, ale wcześniej Kompilacja zasobu - która oczywiście wysadza się bez bazy danych.yml.

Plik .config jest

# .ebextensions/sensitive_files.config
# Create a prehook command to copy database.yml from S3
files:
  "/opt/elasticbeanstalk/hooks/appdeploy/pre/03_copy_database.sh" :
    mode: "000755"
    owner: root
    group: root
    content: |
        #!/bin/bash
        set -xe
        EB_APP_STAGING_DIR=$(/opt/elasticbeanstalk/bin/get-config  container -k app_staging_dir)
        echo EB_APP_STAGING_DIR is  ${EB_APP_STAGING_DIR} >/tmp/copy.log
        ls -l ${EB_APP_STAGING_DIR} >>/tmp/copy.log
        aws s3 cp s3://elasticbeanstalk-us-east-1-XXX/database.yml ${EB_APP_STAGING_DIR}/config/database.yml >>/tmp/copy.log 2>>/tmp/copy.log

Uwagi

  • Oczywiście XXX w nazwie zasobnika jest numerem kolejnym utworzonym przez EB. Musisz sprawdzić S3, aby zobaczyć nazwę swojego wiadra.
  • Nazwa utworzonego pliku skryptu jest ważna. Skrypty te są wykonywane w kolejności alfabetycznej, więc starałem się je nazwać, aby sortował się przed skryptem asset_compilation.
  • Oczywiście przekierowanie wyjścia do /tmp/copy.log jest opcjonalne

Najbardziej pomógł mi post Dostosowywanie haków rozmieszczenia ElasticBeanstalk

opublikowane przez Kenta @ AWS. Dzięki Kenta!


0
2018-06-20 07:29