web-dev-qa-db-fra.com

Informations d'identification Rails 5.2 + précompilation des actifs

J'ai une intégration continue qui prend l'application Rails et la conditionne comme une image de menu fixe.

L'une des étapes de ce processus d'empaquetage consiste à effectuer la précompilation des actifs.

Je faisais cela sur Rails 5.1. Je devais fournir un SECRET_KEY_BASE factice pour le laisser passer.

SECRET_KEY_BASE=1 Rails_ENV=production Rails assets:precompile

Je passe maintenant à Rails 5.2 et je souhaite commencer à utiliser les informations d'identification. J'essaie de suivre la commande:

Rails_ENV=production Rails assets:precompile

Si je ne Rails_MASTER_KEY pas alors il va me montrer une erreur: 

Clé de chiffrement manquante pour décrypter le fichier. Demandez à votre équipe votre clé principale Et écrivez-la dans /home/config/master.key ou insérez-la dans ENV ['Rails_MASTER_KEY'].

Si je fournis un code factice (incorrect) Rails_MASTER_KEY, il se plaindra de ne pas pouvoir décoder les informations d'identification.

Je ne veux pas donner un vrai Rails_MASTER_KEY à CI.

En conséquence, la question est. Comment compiler un actif sans celui-ci ou quelles sont les solutions de contournement?

ruby-on-railsruby-on-rails-5.2
8
Victor Ronin

Je ne vois pas de solution non plus. Une autre façon serait de continuer à configurer config/environnements/production.rb pour avoir la ligne suivante: 

config.require_master_key = false

et continuez à utiliser votre SECRET_KEY_BASE=1 Rails assets:precompile

Je n'ai pas trouvé de meilleur moyen. Au moins, cette méthode semble préférable au maintien d’une fausse clé principale.

1
nicb

Nous pouvons facilement résoudre le problème dans Docker 1.13 et les versions ultérieures (en supposant que votre CI fonctionne également dans un conteneur Docker) en transmettant le master.key au conteneur de CI à l'aide des secrets du docker. Notez que cela ne fonctionne que dans Darmer Swarm, mais qu'un seul conteneur Docker peut également servir de nœud Docker Swarm. Pour changer un seul noeud (par exemple, sur votre système de développement local) en noeud swarm, utilisez la commande init et suivez les instructions:

docker swarm init

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

Puis, dans votre docker-compose.yml de votre conteneur CI, déclarez le master.key en tant que secret du docker et ciblez-le à la bonne position dans le conteneur:

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/

Comme vous pouvez le constater, nous pouvons également attribuer des droits d'accès dédiés au master.key du conteneur et le protéger de l'élévation des privilèges. Pour plus d'explications sur la visite du docker swarm:

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

Pourquoi est-ce que ceci devrait être la solution préférée à la question? Votre secret (master.key} _ n'est plus stocké dans le conteneur CI Docker, mais est conservé de manière sécurisée dans le journal de Raft crypté de l'infrastructure Docker Swarm, et vous n'avez pas à faire de contorsions acrobatiques avec de fausses clés.

En passant, j'utilise cette approche pour protéger mon expertise spécifique à un domaine dans des conteneurs Docker publics: À l'aide du paramètre cible, chaque secret du menu fixe peut contenir des chaînes génériques ou du contenu binaire d'une taille maximale de 500 Ko, notamment des morceaux de code. qui contiennent des connaissances sensibles.

0
SkatEddy

J'ai créé un faux credentials.yml.enc et Rails_MASTER_KEY qui lui sont associés et je les utilise lorsque je précompile un actif.

0
Victor Ronin