Учетные данные Rails 5.2 + прекомпиляция ресурса - PullRequest
0 голосов
/ 01 мая 2018

У меня есть непрерывная интеграция, которая берет приложение rails и упаковывает его как образ докера.

В качестве одного из этапов этого процесса упаковки я хочу выполнить предварительную компиляцию активов.

Я делал это на Rails 5.1. Я должен был предоставить манекена SECRET_KEY_BASE, чтобы он прошел.

SECRET_KEY_BASE=1 RAILS_ENV=production rails assets:precompile

Я перехожу на Rails 5.2 и хочу начать использовать учетные данные. Я пытаюсь выполнить следующую команду:

RAILS_ENV=production rails assets:precompile

Если я не RAILS_MASTER_KEY, то это покажет мне ошибку:

Отсутствует ключ шифрования для расшифровки файла. Спросите свою команду для вашего мастер-ключ и запишите его в /home/config/master.key или поместите в ENV [ 'RAILS_MASTER_KEY'].

Если я предоставлю фиктивную (неправильную) RAILS_MASTER_KEY, он будет жаловаться, что не может декодировать учетные данные.

Я не хочу отдавать реальные RAILS_MASTER_KEY КИ.

Как результат, вопрос. Как скомпилировать ресурс без него или какие обходные пути?

Ответы [ 3 ]

0 голосов
/ 23 мая 2018

Я тоже не вижу решения. Другим способом было бы продолжать задавать в config / environment / production.rb строку:

config.require_master_key = false

и продолжайте использовать ваш SECRET_KEY_BASE=1 rails assets:precompile

Я не нашел лучшего способа. По крайней мере, этот способ кажется лучше, чем поддержка поддельного мастер-ключа.

0 голосов
/ 11 октября 2018

Мы можем легко решить проблему в Docker 1.13 и выше (при условии, что ваш CI также работает в контейнере Docker), передав master.key в контейнер CI, используя секреты Docker. Обратите внимание, что это работает только в Docker Swarm, но также один Docker-контейнер может действовать как Docker Swarm-узел. Чтобы изменить один узел (например, в вашей локальной системе разработки) на узел роя, используйте команду init и следуйте инструкциям:

docker swarm init

https://docs.docker.com/engine/reference/commandline/swarm_init/

Затем в вашем docker-compose.yml вашего контейнера CI объявите master.key как секретный ключ докера и нацелите его на нужную позицию в контейнер:

version: '3.4'

services:
  my_service:

    ...  

    secrets:
    - source: master_key
      target: /my_root/config/master.key
      uid: '1000'
      gid: '1000'
      mode: 0440

    ...  

    security_opt:
    - no-new-privileges

    ...  

secrets:
  master_key:
    file: config/master.key

https://docs.docker.com/compose/compose-file/

Как видите, мы также можем назначить выделенные права доступа для master.key в контейнере и защитить его от повышения привилегий. Для дальнейших объяснений по поводу посещения роя докеров:

https://docs.docker.com/engine/swarm/secrets/#how-docker-manages-secrets

Почему это должно быть предпочтительным решением проблемы? Ваш секретный master.key больше не хранится в контейнере CI Docker, но надежно хранится в зашифрованном журнале Raft инфраструктуры Docker Swarm, и вам не нужно делать никаких акробатических искажений с помощью поддельных ключей.

Кстати, я использую этот подход для защиты своего предметного опыта в общедоступных контейнерах Docker. Используя параметр target , каждый секрет Docker может нести общие строки или двоичное содержимое размером до 500 КБ, особенно фрагменты кода, содержащие конфиденциальные знания.

0 голосов
/ 03 мая 2018

Я создал поддельные credentials.yml.enc и RAILS_MASTER_KEY, связанные с ним, и я использую их, когда прекомпилирую ресурс.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...