Saltar al contenido

Configuración del acceso privado a Github con AWS Elastic Beanstalk y Ruby container

Solución:

Después de un buen día de esfuerzo, finalmente habilité el uso de los repositorios privados de GitHub de mi organización con Elastic Beanstalk simplemente usando un .config expediente. Estoy usando Python y pip, pero también debería funcionar para otros instaladores de paquetes en EB.

rhetonik’s ssh-agent+ssh-add El enfoque no me funcionó en absoluto, así que elegí configurar un archivo de configuración ssh en su lugar.

Aquí está mi .ebextensions/3-pip-install-from-github.config expediente:

files:
    "/root/.ssh/config":
        owner: root
        group: root
        mode: "000600"
        content: |
            Host github.com
                User git
                Hostname github.com
                IdentityFile /root/.ssh/github

commands:
    01-command:
        command: sudo ssh-keyscan -H github.com >> /root/.ssh/known_hosts
    02-command:
        command: sudo chmod 644 /root/.ssh/known_hosts
    03-command:
        command: sudo aws s3 cp s3://bucket-with-your-github-ssh-key/github /root/.ssh
    04-command:
        command: sudo chmod 600 /root/.ssh/github

Instrucciones aproximadas:

  • Configure un depósito de S3 al que pueda acceder su instancia de EB. Dentro de ese depósito, almacene la clave SSH que permite el acceso al repositorio de GitHub al que desea acceder a través de pip, npm, bundle, etc. Utilice sudo aws s3 cp para copiar esa clave en su instancia de EB durante la implementación. sudo es necesario porque los scripts EB utilizan root y no ec2-user.

  • Este archivo de configuración de ebextensions también crea 2 archivos en su instancia de EB. /root/.ssh/config dice ssh (invocado por pip y git) para usar la clave que copió de S3. Almacenar la salida de ssh-keyscan -H github.com dentro /root/.ssh/known_hosts comprobará previamente que ssh en su instancia de EB se está comunicando con GitHub para evitar ataques MITM. Esto es mejor que deshabilitar StrictHostKeyChecking en /root/.ssh/config.

Aquí está mi requirements.txt archivo para pip:

Beaker==1.7.0
Flask==0.10.1
Jinja2==2.7.3
MarkupSafe==0.23
# [...]
git+ssh://[email protected]/myorganization/[email protected]

Mientras corre eb-deploy, usted puede tail -f /var/log/eb-activity.log para asegurarse de que todo funcione sin problemas.

Así es como finalmente lo hice. Se trata de configurar una clave SSH para el usuario responsable de bundle install fase.

  1. Inicie un entorno para una aplicación en AWS Elastic Beanstalk
  2. Opcional – Inicie sesión en la consola de Amazon EC2 y cambie el tipo de instancia al valor deseado
  3. Actualice el nombre del par de claves SSH para habilitar el inicio de sesión SSH remoto. (Estoy seguro de que debe haber una forma de especificar el tipo de instancia y el nombre del par de claves SSH al iniciar un entorno)
  4. Busque la instancia recién lanzada en la consola EC2 o a través de CLI, tenga en cuenta la Nombre de dominio completo (FQDN) para este caso. Las instancias de EB son como cualquier otra instancia que crearía con Amazon EC2. Inicie sesión a través de SSH en esta instancia.
  5. Ejecute los siguientes comandos para crear una clave SSH para root usuario

    $ sudo su – raíz

    $ ssh-keygen -t rsa -C “[email protected]”

  6. Editar .bash_profile para comenzar explícitamente ssh-agent y agregue la clave SSH recién generada. Agregue las siguientes líneas (esto puede parecer innecesario, lo hice solo para estar seguro)

    eval `ssh-agent

    eval ssh-add ~/.ssh/id_rsa

  7. Tenga en cuenta la clave pública SSH, por ejemplo: ~/.ssh/id_rsa.pub y agréguelo al conjunto de claves SSH para la cuenta de Github que tiene acceso a repositorios privados

  8. En este punto, su instancia tiene acceso a sus repositorios privados de Github. Puede probar esto emitiendo un git clone en esos repositorios iniciando sesión como root usuario.

  9. Cree una AMI a partir de esta instancia mediante métodos estándar

  10. Vuelva a su panel de AWS Elastic Beanstalk y busque Edit Configuration opción en el entorno de su aplicación. En el Server pestaña, busque una opción que le permita especificar un Custom AMI. Actualice este campo con el ID de AMI recién creado, por ejemplo: ami-4324fd4.

  11. Guarde la configuración presionando Apply Changes. AWS Elastic Beanstalk comenzaría a implementar nuevas instancias en su entorno y terminaría con las antiguas. Esto es para garantizar que todas sus instancias escaladas automáticamente tengan la clave SSH en la lista blanca requerida para el acceso privado a Github.

Una vez realizados los pasos anteriores, puede continuar e implementar su aplicación Rails con git aws.push

Espero que esto ayude a otros que están atascados. Sin embargo, me alegraría ver una solución más elegante que esta.

Si tiene prisa y el repositorio de su aplicación también es privado, puede crear una cuenta de usuario de Github adicional y asignarle privilegios de solo lectura al repositorio que contiene la gema.

Luego, proporcione al paquete la URL https con las credenciales de la nueva cuenta:

gem 'somegemname', git: "https://username:[email protected]/example/privaterepository"
¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *