Управление секретами с GitHub

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

Управление секретами — это практика безопасного хранения и управления такими конфиденциальными данными. Она гарантирует, что доступ к ним получат только авторизованные системы и пользователи, предотвращая несанкционированное раскрытие.

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

• По умолчанию они не записываются в журналы.
• После создания они не отображаются в пользовательском интерфейсе.
• Они доступны только выбранным рабочим процессам.

Это защищает ваши учетные данные от случайного раскрытия.

Секреты можно определять на разных уровнях: репозитория, среды или организации. Чаще всего начинают с секретов репозитория.

Чтобы создать секрет:

1. Откройте вкладку Настройки своего репозитория.
2. Перейдите в раздел Секреты и переменные > Действия.
3. Нажмите Новый секрет репозитория.

Укажите уникальное имя, например API_KEY, и вставьте значение секрета.

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

Для доступа к ним используется контекст ${{ secrets.SECRET_NAME }}. Этот сценарий имитирует шаг, в котором используется такой секрет. Чтобы запустить его, представьте, что GitHub Actions установил MY_API_KEY как переменную среды.

Помимо секретов репозитория, GitHub предлагает еще две области действия с более широкими возможностями:

• Секреты организации: доступны нескольким репозиториям внутри организации. Полезны для секретов, общих для многих проектов, например токена развертывания, используемого всей компанией.
• Секреты среды: привязаны к конкретным средам развертывания, например staging и production. Для них можно настроить правила защиты, например требовать ручного подтверждения перед развертыванием.

Для максимальной безопасности всегда используйте наименьшую необходимую область действия.

OpenID-подключение (OIDC) — это уровень аутентификации, построенный поверх OAuth 2.0. Это стандарт, позволяющий клиентам проверять личность конечного пользователя на основе аутентификации, выполненной сервером авторизации.

В CI/CD OIDC позволяет рабочим процессам безопасно проходить аутентификацию у облачных провайдеров, например AWS, Azure и GCP, без хранения долгосрочных учетных данных, таких как ключи API, в секретах GitHub.

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

Этот токен содержит проверяемые утверждения о рабочем процессе, например репозиторий, ветвь и идентификатор задачи (ID). Затем облачных провайдеров можно настроить так, чтобы они доверяли токенам, выпущенным GitHub, и предоставляли временный доступ на основании этих утверждений.

Использование OIDC с GitHub Actions дает существенные преимущества для безопасности:

• Отсутствие долгосрочных учетных данных: вам не нужно хранить статические облачные ключи API в секретах GitHub.
• Снижение риска: токены с коротким сроком действия сводят к минимуму последствия возможной компрометации токена.
• Детализированный доступ: облачные роли можно сопоставить с конкретными условиями рабочего процесса, например разрешить развертывание только из ветви main.
• Аудит: проще отслеживать, кто и что сделал, поскольку идентичность связана с запуском рабочего процесса.

Чтобы использовать OIDC, необходимо настроить облачного провайдера, например AWS IAM, Azure AD или GCP IAM, так, чтобы он доверял издателю OIDC от GitHub.

Обычно это включает следующие действия:

1. Настройка поставщика удостоверений (IdP) в вашей облачной учетной записи.
2. Определение роли/политики, предоставляющей конкретные разрешения.
3. Добавление «политики доверия» к роли, позволяющей токенам OIDC GitHub использовать эту роль, часто с условиями на основе утверждений токена, например только для определенного репозитория.

Затем рабочий процесс запрашивает токен и использует его для аутентификации.

Вы узнали о секретах GitHub для хранения конфиденциальных данных и об OpenID-подключении для аутентификации в облаке без учетных данных.

Какие из следующих утверждений об управлении секретами GitHub Actions являются TRUE?

Отличная работа! Вы узнали, как безопасно управлять конфиденциальными данными в конвейерах CI/CD.

• Секреты GitHub обеспечивают зашифрованное хранение ключей API и токенов в репозитории, организации или конкретных средах.
• OpenID-подключение (OIDC) обеспечивает еще более безопасную аутентификацию у облачных провайдеров с помощью проверяемых токенов с коротким сроком действия вместо статических учетных данных.

Эти практики необходимы для создания надежных и безопасных конвейеров DevOps.