Подтвердить что ты не робот

Каким образом секретные файлы должны быть перенесены в приложение EC2 Ruby on Rails, используя веб-службы amazon с их эластичным бобовым стеблем?

Как следует поместить секретные файлы в приложение EC2 Ruby on Rails, используя веб-службы amazon с их эластичным бобовым стеблем?

Я добавляю файлы в репозиторий git, и я нажимаю на github, но хочу сохранить свои секретные файлы из репозитория git. Я использую aws, используя:

git aws.push

В .gitignore:

находятся следующие файлы:
/config/database.yml
/config/initializers/omniauth.rb
/config/initializers/secret_token.rb

Следуя этой ссылке, я попытался добавить S3 файл в мое развертывание: http://docs.amazonwebservices.com/elasticbeanstalk/latest/dg/customize-containers.html

Цитата из этой ссылки:

Пример фрагмента

Следующий пример загружает zip файл из ведра Amazon S3 и распаковывает его в файл /etc/myapp:

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

Следуя этим указаниям, я загрузил файл в ведро S3 и добавил следующее в файл private.config в каталоге .ebextensions:

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

Этот файл config.tar.gz будет извлекаться в:

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

Однако, когда приложение развертывается, файл config.tar.gz на хосте S3 никогда не копируется и не извлекается. Я все еще получаю ошибки, которые невозможно найти в базе данных .yml, и в журнале EC2 нет записи конфигурационного файла, вот сообщение об ошибке:

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

Ответ 1

Возможно (и легко) хранить конфиденциальные файлы в S3 и автоматически копировать их в свои экземпляры Beanstalk.

При создании приложения Beanstalk автоматически создается ведро S3. Этот ведро используется для хранения версий приложений, журналов, метаданных и т.д.

По умолчанию aws-elasticbeanstalk-ec2-role, назначенный вашей среде Beanstalk, доступен доступ к этому ведру.

Итак, все, что вам нужно сделать, это поместить ваши чувствительные файлы в это ведро (либо в корневом каталоге, либо в любой структуре каталогов, которые вы желаете), и создать файл конфигурации .ebextension, чтобы скопировать их в экземпляры EC2.

Вот пример:

# .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

Это описано здесь: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/https-storingprivatekeys.html

Ответ 2

"Правильный" способ сделать то, что я думаю, что вы хотите сделать, - использовать роли IAM. Вы можете увидеть сообщение в блоге об этом здесь: http://aws.typepad.com/aws/aws-iam/

В принципе, он позволяет запускать экземпляр EC2 без каких-либо личных учетных данных в любом файле конфигурации. Когда вы запускаете экземпляр, ему будет назначена данная роль (набор разрешений для использования ресурсов AWS), а вращающиеся учетные данные будут автоматически помещены на машину с помощью Amazon IAM.

Ответ 3

Чтобы файлы .ebextension/*.config могли загружать файлы с S3, они должны быть общедоступными. Учитывая, что они содержат конфиденциальную информацию, это плохая идея.

Вы можете запустить экземпляр Elastic Beanstalk с ролью экземпляра, и вы можете предоставить эту роль для доступа к файлам, о которых идет речь. К сожалению, разделы file: и sources: файлов .ebextension/*.config не имеют прямого доступа для использования этой роли.

Вы должны написать простой script, используя класс AWS:: S3:: S3Object AWS SDK для Ruby для загрузки файлов и используйте command: вместо sources:. Если вы не укажете учетные данные, SDK автоматически попытается использовать эту роль.

Вам нужно будет добавить политику к своей роли, которая позволит вам скачать нужные вам файлы. Это будет выглядеть так:

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

Тогда вы можете сделать что-то подобное в своем .config файле

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

Ответ 4

Использование переменных среды - хороший подход. Справочные пароли в среде, поэтому в файле yaml:

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

Затем установите их в экземпляре непосредственно с помощью eb или консоли.

Вы можете быть обеспокоены тем, что такая конфиденциальная информация легко доступна в среде. Если процесс компрометирует вашу систему, он, вероятно, может получить пароль независимо от того, где он находится. Этот подход используется многими провайдерами PaaS, такими как Heroku.

Ответ 5

В этом документе безопасности Amazon EC2 поддерживает TrueCrypt для шифрования файлов и SSL для передачи данных. Проверьте эти документы

Вы можете загрузить экземпляр сервера с зашифрованным диском или использовать частное репо (я думаю, что это стоит для github, но есть альтернативы)

Ответ 6

Я думаю, что лучший способ - не взломать AWS (установить крючки, загрузить файлы). Просто используйте переменные ENV.

Используйте gem 'dot-env' для разработки (т.е. <% = ENV ['LOCAL_DB_USERNAME']% > в 'config/database.yml') и консоль AWS по умолчанию для установки переменных в Beanstalk.

Ответ 7

Я знаю, что это старый пост, но я не мог найти другого ответа нигде, поэтому я сжег полуночное масло, чтобы поднять его. Надеюсь, это сэкономит вам несколько часов.

Я согласился с разработчиками, которые указали, сколько из PITA вынуждает разработчиков устанавливать ENV vars в свою локальную базу данных dev.yml. Я знаю, что драгоценный камень dotenv хорош, но вам все равно нужно поддерживать ENV vars, что добавляет времени, необходимого для подъема станции.

Мой подход заключается в том, чтобы хранить файл database.yml на S3 в ведре, созданном EB, а затем использовать конфигурационный файл .ebextensions для создания script в каталоге pre hook сервера, чтобы он выполнялся после распаковки в промежуточном каталоге, но до компиляции активов, который, конечно же, взрывается без database.yml.

Файл .config

# .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

Примечания

  • Конечно, XXX в названии ведра представляет собой порядковый номер, созданный EB. Вам нужно будет проверить S3, чтобы увидеть имя вашего ведра.
  • Важно создать имя создаваемого файла script. Эти сценарии выполняются в алфавитном порядке, поэтому я был осторожен, чтобы называть его так, чтобы он сортировался до comp_compilation script.
  • Очевидно, перенаправление вывода на /tmp/copy.log необязательно

Сообщение, которое помогло мне больше всего, было в Настройка перехватчиков развертывания ElasticBeanstalk

отправленный Kenta @AWS. Спасибо Кента!