Каким образом секретные файлы должны быть перенесены в приложение 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
Ответы
Ответ 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. Спасибо Кента!