Настройка частного доступа Github с использованием эластичного бобового стека AWS и контейнера Ruby

Ответ 1

После хорошего дня усилий я, наконец, включил использование моей частной организации GitHub с помощью Elastic Beanstalk, просто используя файл .config. Я использую Python и pip, но он также должен работать для других инсталляторов пакетов на EB.

rhetonik ssh-agent + ssh-add не работал у меня вообще, поэтому я решил настроить конфигурационный файл ssh.

Вот мой файл .ebextensions/3-pip-install-from-github.config:

files:
    "/root/.ssh/config":
        owner: root
        group: root
        mode: "000600"
        content: |
            Host github.com
                User git
                Hostname github.com
                IdentityFile /root/.ssh/github
    "/root/.ssh/known_hosts":
        owner: root
        group: root
        mode: "000644"
        content: |
            #
            # paste output of `ssh-keyscan -H github.com` here
            #

commands:
    01-command:
        command: sudo aws s3 cp s3://bucket-with-your-github-ssh-key/github /root/.ssh
    02-command:
        command: sudo chmod 600 /root/.ssh/github

Грубые инструкции:

• Настройте ведро S3, доступное вашему экземпляру EB. Внутри этого ведра сохраните ключ SSH, позволяющий получить доступ к репозиторию GitHub, к которому вы хотите получить доступ, через pip, npm, bundle и т.д. Используйте sudo aws s3 cp, чтобы скопировать этот ключ на ваш экземпляр EB при развертывании. sudo необходимо, потому что сценарии EB используют root, а не ec2-user.

• Этот файл конфигурации ebextensions также создает 2 файла на вашем экземпляре EB. /root/.ssh/config сообщает ssh (вызывается pip и git) для использования ключа, который вы скопировали из S3. Вставка вывода ssh-keyscan -H github.com в /root/.ssh/known_hosts будет предварительно проверять, что ssh на вашем экземпляре EB фактически связывается с GitHub, чтобы избежать атак MITM. Это лучше, чем отключить StrictHostKeyChecking в /root/.ssh/config.

Вот мой requirements.txt файл для pip:

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

При запуске eb-deploy вы можете tail -f /var/log/eb-activity.log убедиться, что все выполняется гладко.

Ответ 2

Вот как я, наконец, это сделал. Все о настройке SSH-ключа для пользователя, который отвечает за фазу bundle install.

• Запустите среду для приложения в AWS Elastic Beanstalk
• Дополнительно - Войдите в консоль Amazon EC2 и измените тип экземпляра на желаемое значение
• Обновить имя пары SSH для включения удаленного входа SSH. (Я уверен, что при запуске среды должен быть указан тип экземпляра и имя пары ключей SSH).
• Ищите недавно запущенный экземпляр либо в консоли EC2, либо через CLI, обратите внимание на полное доменное имя (FQDN) для этого экземпляра. Экземпляры EB похожи на любой другой экземпляр, который вы создадите с помощью Amazon EC2. Войдите через SSH в этот экземпляр.
• Выполните следующие команды для создания SSH-ключа для пользователя root

  $sudo su - root

  $ssh-keygen -t rsa -C "[email protected]"

• Измените .bash_profile, чтобы явно запустить ssh-agent и добавить вновь созданный SSH-ключ. Добавьте следующие строки (это может показаться ненужным, я сделал это, чтобы убедиться)

  eval `ssh-agent

  eval ssh-add ~/.ssh/id_rsa

• Обратите внимание на открытый ключ SSH E.g.: ~/.ssh/id_rsa.pub и добавьте его в набор SSH-ключей для учетной записи Github, который имеет доступ к частным репозиториям

• В этот момент ваш экземпляр имеет доступ к вашим приватным репозиториям Github. Вы можете протестировать это, выпустив git clone в этих репозиториях, войдя в систему как пользователь root.

• Создайте AMI из этого экземпляра, используя стандартные методы

• Вернитесь на панель управления AWS Elastic Beanstalk и найдите вариант Edit Configuration в вашей прикладной среде. На вкладке Server найдите параметр, который позволяет указать Custom AMI. Обновите это поле с помощью вновь созданного идентификатора AMI, например: ami-4324fd4.

• Сохраните конфигурацию, нажав Apply Changes. AWS Elastic Beanstalk начнет развертывать новые экземпляры в вашей среде и заканчивать старые. Это гарантирует, что все ваши автомасштабируемые экземпляры имеют белый ключ SSH, необходимый для частного доступа Github.

После выполнения вышеуказанных шагов вы можете продолжить развертывание приложения Rails с помощью git aws.push

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

Ответ 3

Если вы спешите, и ваше репо-приложение также является приватным, вы можете создать дополнительную учетную запись пользователя Github и назначить ей привилегии только для чтения для репо, содержащего драгоценный камень.

Затем передайте узел https url с новыми учетными данными:

gem 'somegemname', git: "https://username:[email protected]/example/privaterepository"

Ответ 4

Существует два подхода к аутентификации с помощью GitHub. Я рекомендую связать вашу личную учетную запись GitHub с частным репозиторией GitHub в любом случае.

Первый подход передает те же учетные данные ssh, которые вы используете локально для push, pull и т.д. из удаленного репозитория GitHub - вы загрузили свой открытый ключ для своей личной учетной записи и того, что использует GitHub. Чтобы эта работа работала на другом сервере, вам нужно запустить ssh-agent и использовать ssh-add, чтобы добавить свой ключ к агенту, - тогда ваши личные учетные данные GitHub могут использоваться для выполнения команд git.

Второй подход заключается в том, чтобы позволить удаленным серверам (серверам), к которым вы развертываетесь, иметь доступ к GitHub - это может быть эластичный beanstalk или ваш фактический сервер (ы). Создайте ключ ssh без пароля на сервере (ssh-keygen -t rsa, принимайте значения по умолчанию, или, возможно, EB имеет собственный способ), затем скопируйте сгенерированное содержимое открытого ключа и создайте новый "ключ развертывания", содержащий этот ключ в вашем репозитории GitHub - вам нужно быть администратором, который, как я полагаю, вы есть. Установленный ключ развертывания позволит пользователям EB регистрироваться на удаленном сервере и выполнять git pull и связанные с ним команды (только для чтения) с сервера.

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