Applied Kubernetes Hardening: A Practical Playbook

Kubernetes поставляється з гнучкістю, а не безпекою як своєю позицією за замовчуванням. Кожен відкритий порт, дозвільна роль RBAC і необмежений под — це запрошення. Посилення кластера означає систематичне закриття цих розривів без порушення робочих навантажень, які від них залежать. Це не вправа в контрольних списках — це постійна дисципліна, яка торкається шарів ідентичності, мережі, робочого навантаження та ланцюга поставок.

Заблокуйте площину керування першою

API сервер — це найцінніша ціль в будь-якому кластері. Почніть з вимкнення анонімної аутентифікації та застосування надійних методів аутентифікації — інтеграція OIDC з вашим поставщиком ідентичності краще, ніж статичні токени або сертифікати клієнтів, які ніколи не закінчуються. Обмежте доступ до сховища даних etcd, оскільки воно містить кожен секрет і об'єкт конфігурації у відкритому вигляді, якщо не ввімкнено шифрування в спокої. Увімкніть шифрування для секретів за допомогою провайдера KMS, а не покладайтеся на кодування base64, яке забезпечує нульовий реальний захист. Журнал аудиту має бути увімкнений з першого дня; без нього у вас немає слідів судово-медичної експертизи, коли щось піде не так.

RBAC: Найменший привілей, а не зручність

Найпоширеніша помилка конфігурації у виробничих кластерах — надто широкі прив'язки RBAC — cluster-admin надається облікам служб, які мають лише читати поди в одному просторі імен. Побудуйте ролі на основі фактичних функцій роботи та обмежте їх до просторів імен, де це можливо. Уникайте символів підстановки та ресурсів у визначеннях Role і ClusterRole. Регулярно аудируйте прив'язки за допомогою таких інструментів, як kubectl auth can-i --list або rbac-lookup, щоб впіймати розширення привілеїв. Облікові записи служб заслуговують такої ж уваги, як і користувачі — вимкніть автоматичне монтування токенів облікового запису служби для подів, які не потребують доступу до API.

Pod Security: припустіть компрометацію

Pod Security Admission (який замінив застарілий PodSecurityPolicy) дозволяє вам застосовувати базові або обмежені профілі на рівні простору імен. Як мінімум, забороніть привілейовані контейнери, спільне використання простору імен хосту та підвищення привілеїв. Установіть runAsNonRoot: true і видаліть усі можливості Linux за замовчуванням, додавши назад лише те, що явно потрібно. Файлові системи, доступні лише для читання, запобігають записуванню зловмисних двійкових файлів у запущений контейнер зловмисниками. Ці контролі мають значення, оскільки вихід з контейнера або вразливість експлуатованої програми не повинні призводити до повної компрометації вузла.

Мережеві політики не є необов'язковими

За замовчуванням кожен под у кластері Kubernetes може спілкуватися з кожним іншим подом. Ця плоска модель мережі — мрія для атакуючих щодо бічного руху. Реалізуйте ресурси NetworkPolicy для застосування отримання та надсилання, які за замовчуванням забороняють, а потім явно дозволяйте лише потоки трафіку, які вимагають ваші програми. Це вимагає плагіна CNI, який дійсно підтримує застосування NetworkPolicy — Calico, Cilium та інші заповнюють цю роль, оскільки базова модель мережі Kubernetes нічого не застосовує сама по собі. Сегментування просторів імен за межею довіри та накладання політик на верх дає вам справжній захист глибини.

Цілісність образу та ланцюга поставок

Посилення безпеки не зупиняється на конфігурації виконання — воно починається з того, що ви розгортаєте. Сканіруйте образи контейнерів на відомі вразливості перед тим, як вони досягнуть вашого реєстру, і застосовуйте, що лише підписані, перевірені образи можуть працювати у вашому кластері за допомогою контролерів допуску, як-от Kyverno або OPA Gatekeeper. Закріпіть теги образів до дайджестів, а не змінних тегів на кшталт latest, які можуть тихо змінюватися під вами. Обмежте реєстри, з яких подам дозволено витягувати, закривши звичайний шлях для атак ланцюга поставок, де скомпрометовані або помилково набрані образи потрапляють у виробництво.

Управління секретами за межами стандартних Kubernetes

Нативні Kubernetes Secrets — це краще, ніж нічого, але вони не є справжнім рішенням для управління секретами. Розгляньте можливість інтеграції зовнішнього менеджера секретів — Vault, AWS Secrets Manager або подібного — та введення секретів під час виконання, а не їх зберігання як об'єктів кластера. Якщо ви повинні використовувати рідні Secrets, переконайтеся, що шифрування etcd ввімкнено і RBAC суворо обмежує доступ для читання, оскільки будь-який под або користувач з дозволом get на секретах у просторі імен можуть вилучити облікові дані.

Безперервна перевірка, а не одноразове налаштування

Конфігурації посилення безпеки змінюються з часом, коли розгортаються нові робочі навантаження і пріоритети зміщуються до швидкості над безпекою. Інструменти, як-от kube-bench, перевіряють відповідність тестам CIS Kubernetes Benchmark, а kube-hunter може імітувати розвідку зловмисника проти вашого кластера. Вбудуйте ці перевірки в конвеєри CI/CD, щоб помилки конфігурації були виявлені перед тим, як вони досягнуть виробництва, а не під час дзвінка реагування на інцидент.

Посилення безпеки Kubernetes — це менше про один срібний стандарт контролю й більше про накладання захистів на ідентичність, мережу, робоче навантаження та ланцюг поставок — так що відмова в одному шарі не каскадує в повну компрометацію. Для більшого про шаблони безпеки хмарної інфраструктури та оборонні інструменти дослідіть пов'язані сегменти на платформі DEFENSE_GRID студії Korra Studio.