AKS + ACR: Архітектура безпечної інтеграції (Best Practices)

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Інтеграція Azure Kubernetes Service (AKS) із Azure Container Registry (ACR) на перший погляд здається тривіальним завданням. Однак, як показує практика, більшість базових налаштувань мають критичні недоліки. Пропуск кількох архітектурних нюансів може призвести до нестабільності розгортань, годин відлагодження або серйозних інцидентів безпеки.

Нижче наведено чек-ліст обов’язкових кроків для переведення зв’язки AKS/ACR у статус Production Ready.

1. Приватний реєстр — це фундамент

Використання публічних репозиторіїв для робочих навантажень неприпустиме. ACR надає необхідний рівень ізоляції, версіонування та контролю доступу. Ви повинні чітко розуміти, хто створив образ, що в ньому міститься і хто має до нього доступ. Це перший крок до передбачуваного деплою.

2. Гео-реплікація (Geo-Replication)

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

1. Навіщо: Це дозволяє нодам кластера «тягнути» (pull) образи з локального для них регіону.
2. Результат: Зменшення latency, підвищення надійності та зниження витрат на egress-трафік (передачу даних між регіонами).
3. Як працює: Ви керуєте одним реєстром, а Azure синхронізує дані між регіонами автоматично. Єдині імена тегів, єдиний менеджмент. Примітка: Ця функція вимагає SKU Premium.

3. Zone Redundancy

У межах одного регіону варто увімкнути Zone Redundancy. Це розподіляє дані реєстру між різними зонами доступності (Availability Zones). Якщо один дата-центр у регіоні вийде з ладу, ваш ACR залишиться доступним, і пайплайни не зупиняться. Це вмикається одним чекбоксом на порталі або прапорцем у CLI.

4. Ізоляція життєвого циклу (Resource Groups)

Поширена помилка — створювати ACR у тій самій групі ресурсів (Resource Group), що й сам кластер AKS. Чому це погано: Контейнерні реєстри часто є спільними для різних середовищ (Dev, Test, Prod). Якщо хтось видалить групу ресурсів тестового кластера, ви ризикуєте випадково знищити й ACR з усіма образами. Рішення: Завжди виносьте ACR у виділену, «довгоживучу» групу ресурсів.

5. Захист від випадкового видалення (Soft Delete)

Людський фактор або помилка в скрипті очищення може призвести до видалення критичних маніфестів чи шарів. Увімкніть функцію Soft Delete. Вона працює як «кошик»: ACR зберігатиме видалені артефакти протягом заданого періоду (retention period), дозволяючи відновити їх до моменту остаточного знищення. Це просте налаштування, яке рятує від катастроф.

6. Managed Identity замість Service Principals

Часи хардкоду секретів та ротації паролів для Service Principals минули. Використовуйте Managed Identity (керовану ідентифікацію) для автентифікації AKS в ACR. Це дозволяє встановити зв’язок «без паролів». Ви просто надаєте ідентифікатору кластера відповідні права на реєстр. Ніяких прописаних секретів у конфігах, ніякого ризику їх витоку.

7. Боротьба з «дрейфом безпеки» та політики карантину

Образ, який був безпечним у момент створення, може стати вразливим через тиждень, коли буде виявлено нову CVE (вразливість).

1. Сканування: Інтегруйте інструменти безпеки (наприклад, Microsoft Defender for Containers).
2. Карантин: Налаштуйте політики, які блокують розгортання образів, якщо в них виявлено нові критичні вразливості, навіть якщо образ вже лежить у реєстрі. Це запобігає потраплянню скомпрометованого коду в продакшн.

8. Гранулярний доступ (RBAC)

Не роздавайте права адміністратора наліво і направо. Використовуйте вбудовані ролі Azure RBAC:

1. AcrPull: Для нод кластера та розробників, яким потрібно лише завантажити образ.
2. AcrPush: Тільки для CI/CD пайплайнів та білд-агентів.
3. AcrDelete: Для сервісних акаунтів, що займаються очищенням старіх тегів. Принцип найменших привілеїв (Least Privilege) тут є обов’язковим.

9. Мережева безпека: Private Link

Одна з найважливіших, але часто ігнорованих опцій — заборона публічного доступу до реєстру. Використовуйте Azure Private Link. Це дозволяє призначити ACR приватну IP-адресу з вашої віртуальної мережі (VNet).

1. Весь трафік між AKS та ACR йде через приватну магістраль Microsoft (backbone), не виходячи в публічний інтернет.
2. Це сумісно з ExpressRoute та VPN Gateway для гібридних сценаріїв. Це радикально підвищує рівень безпеки.

10. Контроль джерел (Admission Controllers)

Налаштуйте кластер так, щоб він приймав образи тільки з ваших довірених ACR. Це реалізується через Admission Controllers (наприклад, за допомогою Azure Policy або OPA Gatekeeper). Навіть якщо зловмисник (або неуважний розробник) спробує запустити под в кластері з образу Docker Hub або іншого ненадійного джерела, кластер заблокує цей запит.