Всем привет! Очень скоро, 20 апреля, GitHub будет проводить очередной митап в России. Как и всегда, команда организаторов ждёт вас и вашей обратной связи. Что вам интересно? Приходите послушать и пообщаться.

В этот раз митап будет про безопасность. В последние годы наблюдается рост интереса к этой теме. С одной стороны, это совершенно эволюционный процесс – базы уязвимостей растут, надо их имплементировать в инструменты, стараясь делать это так, чтобы эти инструменты сами не стали уязвимыми, писать регламенты. С другой стороны, появились рабочие группы по DevSecOps и Supply Chain Security. В индустрии обратили пристальное внимание на проблему общения о безопасности между командами разработки, саппортом, бизнес-группами и собственно отделом безопасности. Одними из ключевых факторов для попытки решения этой проблемы уже называют аккуратную автоматизацию процесса разработки и интеграцию с партнёрскими решениями. GitHub, являясь местом, которому разработчики доверяют своё самое ценное, плотно работает над новыми технологиями, и на митапе разработчики из GitHub, Алена Глобина и Артём Савельев, расскажут про CodeQL и обеспечение превентивной безопасности в цикле разработки.

Также недавно GitHub опубликовал пост про управление секретами и использование их в GitHub Actions, перевод которого мы и публикуем.

GitHub Actions – это расширяемый собственными и партнёрскими решениями механизм по автоматизации этапов разработки. Когда нужно обращаться наружу, можно хранить зашифрованные секреты для GitHub Actions для аутентификации на внешних ресурсах. Это делает доступ более простым и безопасным.

Хорошие практики управления секретами зиждятся на принципе наименьших привилегий, ограничивая права секретов до того, что реально надо, регламентируя выпуск этих секретов и производя ротацию по необходимости. В GitHub Actions есть несколько фич, которые помогут управлять секретами, исходя из принципа наименьших привилегий.

Расположение и доступность секретов

Секреты в GitHub можно хранить на трех уровнях - организации, репозитория или среды. Каждый уровень имеет свои особенности, связанные с характером использования.

Например, имеется токен, которым пользуется бот в Slack и у которого есть разрешение только на постинг статус-апдейтов CI/CD в каналы, управляемые организацией. Токен доступа к особым ресурсам не имеет, плюс много других сущностей постят похожее в Slack. Этот секрет можно хранить на уровне организации. При создании секрета на этом уровне можно выбрать его scope доступности – на уровне всех репозиториев в организации, приватных репозиториев или конкретного набора репозиториев.

Второй пример. Приложение в контейнере, которое хранит образ в AWS Elastic Container Registry (ECR). На уровне репозитория создается уникальный токен и используется с установленным ограничением на развертывание только этого контейнера.

Это же приложение разворачивается в три среды в Azure Web App. Каждая среда – собственный профиль развертывания. В такой модели секрет можно хранить на уровне среды.

Ограничение использования секрета

Принцип наименьших привилегий актуален не только в плане того, что токен может использовать, но и то, кто и как используют сам токен. Реализовать эффективную политику ограничения использования секрета можно, комбинируя размещение секрета на корректном уровне и функции environment protections, CODEOWNERS и branch protection rules.

Пример. Компания MonaCorp хочет сделать так, чтобы секрет мог быть использован только при деплое разрешенных изменений в продакшн-среду приложения OctoMittens, которое хостится в Azure Web App. У приложения также в наличии среды для dev и test.

Сначала необходимо определить среды внутри репозитория.

Каждая среда имеет собственный секрет AZURE_WEBAPP_PUBLISH_PROFILE.

Однако, если оставить это в таком виде, кто-нибудь с write-доступом может создать ветку unauthorized-production-deployment, изменить файл и запустить workflow. В итоге секрет будет использован для деплоя в прод. Подобное несанкционированное использование секрета можно предотвратить так:

• Создать правило защиты среды, ограничив ветки, которые можно деплоить в среду прода. Например, разрешив деплоить только main.
  

  

• Настроить CODEOWNERS для директории .github/workflows. Например, чтобы доступ был у @monacorp/automation-review .

· ### Actions workflows

.github/workflows/ @monacorp/automation-review

• Создать правило на защиту ветки. Например, чтобы любой merge в main должен был бы пройти ревью от CODEOWNERS.

После этого единственным путём использования секрета AZURE_WEBAPP_PUBLISH_PROFILE (для прода) остаётся ветка main и среда production. Любое другое использование будет требовать подтверждение от команды @monacorp/automation-review .

Интеграция с хранилищами секретов

Многие компании управляют секретами централизованно, например, в HashiCorp Vault или Azure Key Vault. GitHub Actions можно интегрировать с любым из этих хранилищ, соблюдая при этом описанные выше практики.

Пример. MonaCorp хочет разместить все секреты в HashiCorp Vault. Хранение секретов в нескольких местах нарушит принцип DRY, увеличит сложность управления и добавит рисков. Поэтому MonaCorp хочет разместить там созданные секреты и использовать уже сделанные настройки.

Чтобы сделать это, команда MonaCorp создает AppRoles в HashiCorp Vault для каждой из сред для своего приложения. Каждая AppRole будет связана с настройкой доступа для секретов, регламентирующей ее использования для деплоя в конкретную среду.

Далее roleID и secretID из AppRole сохраняются в секреты в GitHub.

Аналогично настраивается action Azure Key Vault – Get Secrets.

Ротация

У MonaCorp есть процесс для ротации секретов. Секреты, хранящиеся в Vault, ротируются там же. Результат ротации автоматически попадает в Actions. Обновление секретов в GitHub автоматизируется с помощью REST API.

Безопасность секретов в GitHub - резюме

При правильной настройке уровня и локации хранения секретов, CODEOWNERS, правил защиты среды, GitHub даёт весь нужный инструментарий для того, чтобы управлять аутентификацией в Actions.

Ждем вас на митапе!