Основна інформація про Github

Reading time: 16 minutes

Базова структура

Базова структура середовища github великої компанії — це наявність enterprise, яке володіє кількома organizations, і кожна з них може містити кілька repositories та кілька teams. Менші компанії можуть просто володіти однією organization і не мати enterprise.

З точки зору користувача user може бути member різних enterprises та organizations. У межах них у користувача можуть бути різні enterprise, organization та repository roles.

Крім того, користувач може бути частиною різних teams з різними enterprise, organization або repository ролями.

І нарешті repositories можуть мати спеціальні механізми захисту.

Привілеї

Enterprise Roles

• Enterprise owner: Люди з цією роллю можуть керувати адміністраторами, керувати organizations у складі enterprise, керувати налаштуваннями enterprise, застосовувати політику в організаціях. Однак вони не можуть отримувати доступ до налаштувань чи вмісту organization, якщо їх не призначено organization owner або не надано прямий доступ до repository, що належить organization.
• Enterprise members: Members organization, що належать вашому enterprise, також автоматично є членами enterprise.

Organization Roles

В організації користувачі можуть мати різні ролі:

• Organization owners: Organization owners мають повний адміністративний доступ до вашої organization. Цю роль слід обмежити, але не менше ніж двома людьми в організації.
• Organization members: За замовчуванням, неадміністративна роль для осіб в organization — organization member. За замовчуванням organization members мають низку дозволів.
• Billing managers: Billing managers — користувачі, які можуть керувати налаштуваннями білінгу для вашої organization, наприклад платіжною інформацією.
• Security Managers: Роль, яку organization owners можуть призначити будь-якій team в організації. При застосуванні вона дає кожному member цієї команди дозволи керувати security alerts і налаштуваннями в межах organization, а також права на читання для всіх repositories в організації.
• Якщо у вашій організації є security team, ви можете використовувати роль security manager, щоб надати членам команди мінімально необхідний доступ до organization.
• Github App managers: Щоб дозволити додатковим користувачам керувати GitHub Apps, що належать organization, owner може надати їм дозволи Github App manager.
• Outside collaborators: Outside collaborator — це особа, яка має доступ до одного або кількох repositories organization, але не є явно member цієї organization.

Ви можете порівняти дозволи цих ролей у цій таблиці: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles

Members Privileges

В https://github.com/organizations/<org_name>/settings/member_privileges ви можете побачити дозволи, які користувачі матимуть просто за те, що є частиною organization.

Налаштування тут вкажуть на такі дозволи членів organization:

• Мати admin, writer, reader або відсутність доступу до всіх repository організації.
• Чи можуть members створювати private, internal або public repositories.
• Чи можливе форкування repositories.
• Чи можливо запрошувати outside collaborators.
• Чи можуть публікуватися public або private sites.
• Дозволи, які мають admins над repositories.
• Чи можуть members створювати нові teams.

Repository Roles

За замовчуванням створюються такі repository roles:

• Read: Рекомендовано для не-кодових контрибуторів, які хочуть переглядати або обговорювати проект.
• Triage: Рекомендовано для контрибуторів, які повинні проактивно керувати issues та pull requests без доступу на запис.
• Write: Рекомендовано для контрибуторів, які активно пушать у ваш проект.
• Maintain: Рекомендовано для менеджерів проєкту, яким потрібно керувати repository без доступу до чутливих або деструктивних дій.
• Admin: Рекомендовано для людей, яким потрібен повний доступ до проекту, включаючи чутливі та деструктивні дії, як-от керування безпекою або видалення repository.

Ви можете порівняти дозволи кожної ролі в цій таблиці https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role

Ви також можете створювати власні ролі в https://github.com/organizations/<org_name>/settings/roles

Teams

Ви можете перелічити teams, створені в organization, в https://github.com/orgs/<org_name>/teams. Зауважте, щоб побачити teams, які є дочірніми для інших teams, потрібно перейти до кожної parent team.

Users

Користувачів organization можна переглянути в https://github.com/orgs/<org_name>/people.

В інформації про кожного користувача можна побачити teams, частиною яких є користувач, і repos, до яких користувач має доступ.

Github Authentication

Github пропонує різні способи автентифікації у вашому акаунті та виконання дій від вашого імені.

Web Access

Заходячи на github.com, ви можете увійти, використовуючи свій username і password (а також потенційно 2FA).

SSH Keys

Ви можете налаштувати свій акаунт із одним або кількома public keys, що дозволяють відповідному private key виконувати дії від вашого імені. https://github.com/settings/keys

GPG Keys

Ви не можете видати себе за користувача за допомогою цих ключів, але якщо ви не використовуєте їх, можливо, вас виявлять за надсилання комітів без підпису. Детальніше про vigilant mode тут: https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode.

Personal Access Tokens

Ви можете генерувати personal access token, щоб надати додатку доступ до вашого акаунту. Створюючи personal access token, user повинен вказати дозволи, які token матиме. https://github.com/settings/tokens

Oauth Applications

Oauth applications можуть просити вас про дозволи для доступу до частини вашої github інформації або для імітації вас з метою виконання певних дій. Типовий приклад — кнопка login with github, яку ви можете зустріти на деяких платформах.

• Ви можете створити власні Oauth applications на https://github.com/settings/developers
• Ви можете побачити всі Oauth applications, що мають доступ до вашого акаунту на https://github.com/settings/applications
• Ви можете побачити scopes, які Oauth Apps можуть запитувати на https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps
• Ви можете побачити доступ сторонніх додатків у organization за адресою https://github.com/organizations/<org_name>/settings/oauth_application_policy

Деякі рекомендації з безпеки:

• OAuth App завжди має діяти як автентифікований GitHub user по всьому GitHub (наприклад, при надсиланні користувацьких повідомлень) і мати доступ лише до вказаних scope.
• OAuth App може використовуватися як провайдер ідентичності, дозволивши "Login with GitHub" для автентифікованого користувача.
• Не створюйте OAuth App, якщо хочете, щоб ваш додаток діяв лише над одним repository. З repo OAuth scope, OAuth Apps можуть діяти на всіх репозиторіях автентифікованого користувача.
• Не створюйте OAuth App, щоб діяти як додаток для вашої команди чи компанії. OAuth Apps автентифікуються як один user, тому якщо одна людина створить OAuth App для компанії, а потім покине її, ніхто інший не матиме доступу.
• Детальніше тут: https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps.

Github Applications

Github applications можуть просити дозволи для доступу до вашої github інформації або імітації вас з метою виконання конкретних дій над певними ресурсами. У Github Apps потрібно вказати repositories, до яких додаток матиме доступ.

• Щоб встановити GitHub App, ви повинні бути organisation owner або мати admin permissions в repository.
• GitHub App має підключатися до персонального акаунту або organization.
• Ви можете створити власну Github application на https://github.com/settings/apps
• Ви можете побачити всі Github applications, що мають доступ до вашого акаунту на https://github.com/settings/apps/authorizations
• Ось API Endpoints для Github Applications: https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. Залежно від дозволів додатка він зможе доступатися до деяких з них.
• Ви можете побачити встановлені apps в organization в https://github.com/organizations/<org_name>/settings/installations

Деякі рекомендації з безпеки:

• GitHub App повинен виконувати дії незалежно від користувача (якщо додаток не використовує user-to-server token). Щоб зробити user-to-server access tokens більш безпечними, можна використовувати access tokens, що закінчуються через 8 годин, та refresh token, який можна обміняти на новий access token. Для додаткової інформації див. "Refreshing user-to-server access tokens."
• Переконайтеся, що GitHub App інтегровано з конкретними repositories.
• GitHub App повинен підключатися до персонального акаунту або organization.
• Не очікуйте, що GitHub App знає та робить усе, що може user.
• Не використовуйте GitHub App лише заради сервісу "Login with GitHub". Проте GitHub App може використовувати user identification flow для входу користувачів та виконання інших дій.
• Не створюйте GitHub App, якщо ви лише хочете діяти як GitHub user і робити все, що цей user може робити.
• Якщо ви використовуєте свій додаток з GitHub Actions і хочете змінювати workflow файли, ви мусите аутентифікуватися від імені користувача з OAuth token, який включає workflow scope. Користувач має мати admin або write permission до repository, що містить workflow файл. Для додаткової інформації див. "Understanding scopes for OAuth apps."
• Детальніше тут: https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps.

Github Actions

Це не спосіб автентифікації в github, але зловмисна Github Action може отримати неавторизований доступ до github і, в залежності від наданих Action привілеїв, можна здійснити кілька різних атак. Див. нижче для додаткової інформації.

Git Actions

Git actions дозволяють автоматизувати виконання коду при виникненні події. Зазвичай код, що виконується, якимось чином пов'язаний з кодом repository (наприклад, збірка docker контейнера або перевірка, що PR не містить секретів).

Configuration

В https://github.com/organizations/<org_name>/settings/actions можна перевірити конфігурацію github actions для organization.

Можна заборонити використання github actions повністю, дозволити всі github actions, або дозволити лише певні actions.

Також можна налаштувати, хто потребує схвалення для запуску Github Action, та дозволи GITHUB_TOKEN для Github Action під час його виконання.

Git Secrets

Github Action зазвичай потребують певних секретів для взаємодії з github або сторонніми додатками. Щоб уникнути зберігання їх у відкритому вигляді в repo, github дозволяє зберігати їх як Secrets.

Ці секрети можна налаштувати для repo або для всієї organization. Потім, щоб Action мав доступ до секрету, потрібно оголосити його як:

steps:
- name: Hello world action
with: # Set the secret as an input
super_secret:${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret:${{ secrets.SuperSecret }}

Приклад використання Bash

steps:
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"

Git Environments

Github дозволяє створювати environments, де ви можете зберігати secrets. Потім ви можете надати github action доступ до secrets у цьому environment наступним чином:

jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name

Ви можете налаштувати environment так, щоб він був доступний для усіх гілок (за замовчуванням), тільки для захищених гілок або вказати, які гілки можуть отримувати до нього доступ.
Додатково, захист environment включає:

• Required reviewers: блокувати jobs, що націлені на environment, поки вони не будуть затверджені. Увімкніть Prevent self-review, щоб забезпечити справжній принцип «чотирьох очей» під час самої затвердження.
• Deployment branches and tags: обмежувати, які гілки/теги можуть деплоїтись до environment. Краще вибирати конкретні гілки/теги і переконатись, що ці гілки захищені. Примітка: опція "Protected branches only" застосовується до класичних branch protections і може поводитись неочікувано при використанні rulesets.
• Wait timer: відкладати деплой на конфігурований період.

Там також можна вказати кількість необхідних рев’ю перед виконанням action, що використовує environment, або чекати деякий час перед тим, як дозволити продовження деплоїв.

Git Action Runner

GitHub Action можна виконувати всередині github environment або виконувати у інфраструктурі третьої сторони, налаштованій користувачем.

Декілька організацій дозволяють запускати GitHub Actions у інфраструктурі третьої сторони, оскільки це зазвичай дешевше.

Ви можете переглянути self-hosted runners організації за адресою https://github.com/organizations/<org_name>/settings/actions/runners

Спосіб знайти, які GitHub Actions виконуються у не-github інфраструктурі — шукати runs-on: self-hosted у конфігураційному yaml для GitHub Action.

Неможливо запустити GitHub Action організації всередині self hosted машини іншої організації, тому що при конфігурації Runner генерується унікальний токен, який вказує, до якої організації належить runner.

Якщо кастомний GitHub Runner налаштований на машині всередині AWS або GCP, наприклад, Action може мати доступ до metadata endpoint і вкрасти токен сервісного облікового запису, під яким запущена машина.

Git Action Compromise

Якщо всім actions (або одному зловмисному action) дозволено виконання, користувач може використати GitHub action, який є зловмисним, і він компрометує контейнер, в якому виконується.

Branch Protections

Branch protections призначені, щоб не давати користувачам повний контроль над репозиторієм. Мета — поставити кілька методів захисту перед тим, як можна буде записувати код у певну гілку.

Branch protections репозиторію можна знайти за адресою https://github.com/<orgname>/<reponame>/settings/branches

До гілки (наприклад master) можна застосувати різні захисти:

• Можна вимагати PR перед merge (щоб ви не могли безпосередньо мержити код у гілку). Якщо це вибрано, можуть бути активні й інші захисти:
• Вимагати певну кількість approvals. Дуже часто вимагають 1 або 2 додаткових людей для approve PR, щоб один користувач не міг самостійно змінити код.
• Dismiss approvals when new commits are pushed. Якщо цього не зробити, користувач може approve легітимний код, а потім додати зловмисний код і змержити його.
• Require approval of the most recent reviewable push. Забезпечує, що будь-які нові коміти після approval (включно з пушами інших співпрацівників) ініціюють повторне рев’ю, тож атакер не зможе додати зміни після затвердження і змержити.
• Require reviews from Code Owners. Потрібне принаймні 1 схвалення від code owner репозиторію (щоб "випадкові" користувачі не могли його approve).
• Restrict who can dismiss pull request reviews. Можна вказати людей або команди, яким дозволено скасовувати рев’ю PR.
• Allow specified actors to bypass pull request requirements. Ці користувачі зможуть обходити попередні обмеження.
• Require status checks to pass before merging. Деякі перевірки повинні пройти перед тим, як можна буде змержити коміт (наприклад GitHub App, що звітує результати SAST). Порада: прив’язуйте required checks до конкретного GitHub App; інакше будь-який додаток може підробити перевірку через Checks API, і багато ботів приймають директиви пропуску (наприклад "@bot-name skip").
• Require conversation resolution before merging. Всі коментарі в коді мають бути вирішені перед merge PR.
• Require signed commits. Коміти мають бути підписані.
• Require linear history. Запобігає пушу merge commits у відповідні гілки.
• Include administrators. Якщо це не встановлено, адміністратори можуть обходити обмеження.
• Restrict who can push to matching branches. Обмежує, хто може робити push у відповідні гілки.

Tag Protections

Теги (наприклад latest, stable) за замовчуванням змінювані. Щоб забезпечити процес «чотирьох очей» при оновленнях тегів, захищайте теги і побудуйте ланцюг захистів через environments і гілки:

1. У правилі захисту тега увімкніть Require deployments to succeed і вимагайте успішного деплою у захищене environment (наприклад prod).
2. У цільовому environment обмежте Deployment branches and tags до релізної гілки (наприклад main) і за бажанням налаштуйте Required reviewers з Prevent self-review.
3. У релізній гілці налаштуйте branch protections, щоб Require a pull request, встановіть approvals ≥ 1, і увімкніть як Dismiss approvals when new commits are pushed, так і Require approval of the most recent reviewable push.

Цей ланцюг запобігає тому, щоб один співпрацівник переклеїв тег або примусово опублікував реліз, редагуючи workflow YAML, оскільки gates деплою контролюються поза workflows.

References

• https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization
• https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprisehttps://docs.github.com/en/enterprise-server
• https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github
• https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards
• https://docs.github.com/en/actions/security-guides/encrypted-secrets
• https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions
• https://securitylab.github.com/resources/github-actions-untrusted-input/
• https://docs.github.com/en/rest/checks/runs
• https://docs.github.com/en/apps
• GitHub Actions: A Cloudy Day for Security - Part 1