Модуль 3.11: CI/CD: Azure DevOps та GitHub Actions
Складність: [MEDIUM] | Час на виконання: 2 год | Передумови: Модуль 3.6 (ACR), Модуль 3.7 (Container Apps), Модуль 3.1 (Entra ID)
Чому цей модуль важливий
Розділ «Чому цей модуль важливий»У лютому 2023 року велика CI/CD платформа повідомила про злам: зловмисники отримали доступ до репозиторіїв тисяч клієнтів. Вони вкрали змінні оточення конвеєрів, включаючи паролі сервісних акаунтів Azure. Оскільки ці паролі були довготривалими і мали повний доступ до підписок, хакери змогли захопити сотні продуктових середовищ. Компанії втратили контроль над своєю інфраструктурою лише тому, що зберігали статичні паролі в налаштуваннях конвеєра.
Цей інцидент навчив індустрію головному: конвеєр CI/CD — це найпривілейованіша частина вашої інфраструктури. Він має право змінювати код, читати секрети та видаляти сервери. Якщо зламали ваш конвеєр — у зловмисника є ключі від усього дому. Статичні паролі в змінних — це “бомба сповільненої дії”.
У цьому модулі ви навчитеся будувати безпечні конвеєри доставки в Azure за допомогою двох платформ: Azure DevOps та GitHub Actions. Ви дізнаєтеся, як відмовитися від паролів за допомогою OIDC (Workload Identity), як автоматично збирати образи в ACR та деплоїти їх у Container Apps. Наприкінці ви створите конвеєр у GitHub Actions, який авторизується в Azure взагалі без секретів.
Платформи CI/CD для Azure
Розділ «Платформи CI/CD для Azure»- Azure DevOps: Повна інтегрована платформа від Microsoft (Boards, Repos, Pipelines, Artifacts). Стандарт для корпорацій.
- GitHub Actions: Вбудований інструмент GitHub. Найшвидше росте, ідеальний для сучасних хмарних додатків.
Прощавай, паролі: OIDC та Workload Identity
Розділ «Прощавай, паролі: OIDC та Workload Identity»Це найважливіша технологія безпеки сьогодні. Старий спосіб: Ви створюєте Service Principal, берете його секретний пароль і вставляєте в GitHub Secrets. Новий спосіб (OIDC): Azure і GitHub “домовляються” довіряти один одному. Коли конвеєр запускається, він отримує тимчасовий токен (діє 10 хвилин), який Azure приймає як доказ особи.
- Ніяких секретів не зберігається в GitHub.
- Нічого не треба ротувати раз на рік.
- Якщо токен вкрадуть — він згорить через кілька хвилин.
Azure DevOps Pipelines (YAML)
Розділ «Azure DevOps Pipelines (YAML)»Конвеєр описується у файлі azure-pipelines.yml. Він складається зі:
- Stages: Етапи (напр. Build -> Test -> Deploy).
- Jobs: Набір кроків, що виконуються на одному сервері.
- Steps: Конкретні дії (напр. “зібрати Docker образ”).
GitHub Actions
Розділ «GitHub Actions»Воркфлоу живуть у папці .github/workflows/.
- Trigger: подія, що запускає білд (напр.
pushу гілку main). - Permissions: конвеєр повинен мати право
id-token: writeдля роботи через OIDC.
Типові помилки
Розділ «Типові помилки»| Помилка | Чому це стається | Як виправити |
|---|---|---|
| Паролі в GitHub Secrets | Це “старий добрий” спосіб | Переходьте на OIDC (Workload Identity Federation) |
| Права Contributor на всю підписку | Щоб “точно працювало” | Надавайте конвеєру доступ тільки до однієї конкретної Resource Group |
| Деплой у продакшн без схвалення | Поспіх при розробці | Використовуйте Environments із обов’язковим ручним підтвердженням (Reviewers) |
Тег latest у конвеєрі | Зручно, не треба міняти цифри | Використовуйте Git SHA як тег образу. Це гарантує, що ви деплоїте саме те, що щойно зібрали |
Тест
Розділ «Тест»1. Що таке OIDC (OpenID Connect) у контексті GitHub Actions та Azure?
Це метод автентифікації без паролів. Azure довіряє GitHub як постачальнику ідентичності. При запуску конвеєра GitHub видає тимчасовий токен, який Azure перетворює на права доступу. Це набагато безпечніше за статичні паролі.
2. Навіщо використовувати Environments у GitHub або Azure DevOps?
Environments дозволяють розділити налаштування для dev, staging та prod. Головне — ви можете встановити “запобіжники”: наприклад, деплой у продакшн не почнеться, поки лід команди не натисне кнопку “Approve”.
Практична вправа: Мій перший безпечний деплой
Розділ «Практична вправа: Мій перший безпечний деплой»- Створіть додаток у GitHub.
- Налаштуйте Workload Identity Federation між вашим репозиторієм та Azure (через App Registration).
- Напишіть файл
deploy.yml, який:- Логіниться в Azure через OIDC.
- Збирає образ через
az acr build. - Оновлює Container App новим образом.
- Зробіть push і подивіться, як Azure отримує новий код автоматично.
Наступний модуль
Розділ «Наступний модуль»Переходьте до Модуля 3.12: Основи ARM та Bicep — ви навчитеся описувати всю свою інфраструктуру як код, використовуючи сучасну та зручну мову Bicep.