API-сервер Kubernetes — головна точка входу до кластера для зовнішніх сторін (користувачів і сервісів), що з ним взаємодіють.
У межах цієї ролі API-сервер має кілька ключових вбудованих засобів контролю безпеки, таких як логування аудиту та контролери допуску. Однак існують способи змінити конфігурацію або вміст кластера, оминаючи ці засоби контролю.
На цій сторінці описано способи обходу вбудованих в API-сервер Kubernetes засобів контролю безпеки, щоб оператори кластера й архітектори безпеки могли переконатися, що ці обхідні шляхи належно обмежені.
kubelet на кожному вузлі завантажує та безпосередньо керує всіма маніфестами, що зберігаються в зазначеній теці або завантажуються з конкретної URL-адреси як статичні Podʼи у вашому кластері. API-сервер не керує цими статичними Podʼами. Зловмисник із правами запису в це місце може змінити конфігурацію статичних Podʼів, завантажених із цього джерела, або додати нові статичні Podʼи.
Статичним Podʼам заборонено доступ до інших обʼєктів API Kubernetes. Наприклад, не можна налаштувати статичний Pod на монтування Secret із кластера. Однак ці Podʼи можуть виконувати інші чутливі з погляду безпеки дії, наприклад використовувати монтування hostPath з базового вузла.
Стандартно kubelet створює дзеркальний Pod, щоб статичні Podʼи були видимими в API Kubernetes. Однак якщо під час створення Podʼа зловмисник вкаже недійсну назву простору імен, Pod не буде видимий в API Kubernetes, і його зможуть виявити лише інструменти з доступом до уражених хостів.
Якщо статичний Pod не проходить контроль допуску, kubelet не зареєструє Pod на API-сервері. Однак Pod все одно працює на вузлі. Докладніше дивіться в issue kubeadm #1541.
kubelet надає HTTP API, який зазвичай доступний через TCP-порт 10250 на робочих вузлах кластера. API також може бути доступний на вузлах панелі управління залежно від дистрибутива Kubernetes. Прямий доступ до API дозволяє розкривати інформацію про Podʼи, що працюють на вузлі, отримувати логи цих Podʼів і виконувати команди в кожному контейнері на вузлі.
Деякі з цих точок доступу підтримують протоколи Websocket через HTTP-запити GET, які авторизуються за допомогою дієслова get. Це означає, що дозвіл get на nodes/proxy не є дозволом лише для читання й авторизує доступ до точок доступу, які можна використовувати для виконання команд у будь-якому контейнері на вузлі.
Коли у користувачів кластера Kubernetes є доступ RBAC до субресурсів обʼєкта Node, цей доступ слугує авторизацією для взаємодії з API kubelet. Точний доступ залежить від того, доступ до якого субресурсу надано, як детально описано в розділі авторизація kubelet.
Прямий доступ до API kubelet не підлягає контролю допуску й не реєструється логуванням аудиту Kubernetes. Зловмисник із прямим доступом до цього API може обійти засоби контролю, які виявляють певні дії або запобігають їм.
API kubelet можна налаштувати на автентифікацію запитів кількома способами. Стандартно конфігурація kubelet дозволяє анонімний доступ. Більшість провайдерів Kubernetes змінюють стандартну конфігурацію на автентифікацію через вебхук і сертифікати. Це дозволяє панелі управління переконатися, що викликач має право доступу до ресурсу API nodes або його субресурсів. Стандартний анонімний доступ не дає панелі управління такого підтвердження.
nodes за допомогою механізмів, таких як RBAC. Надавайте цей доступ лише за потреби, наприклад сервісам моніторингу.nodes/proxy, навіть лише з дієсловом get. Натомість надавайте детальні дозволи.Кластери Kubernetes використовують etcd як сховище даних. Сервіс etcd прослуховує TCP-порт 2379. Доступ потрібен лише API-серверу Kubernetes та інструментам резервного копіювання, які ви використовуєте. Прямий доступ до цього API дозволяє розкривати або змінювати будь-які дані, що зберігаються в кластері.
Доступом до API etcd зазвичай керує автентифікація за клієнтськими сертифікатами. Будь-який сертифікат, виданий центром сертифікації, якому довіряє etcd, надає повний доступ до даних в etcd.
Прямий доступ до etcd не підлягає контролю допуску Kubernetes і не реєструється логуванням аудиту Kubernetes. Зловмисник, який має доступ на читання до приватного ключа клієнтського сертифіката etcd API-сервера (або може створити новий довірений клієнтський сертифікат), може отримати права адміністратора кластера, отримавши доступ до Secrets кластера або змінивши правила доступу. Навіть без підвищення привілеїв RBAC у Kubernetes зловмисник, який може змінювати etcd, може отримати будь-який обʼєкт API або створити нові робочі навантаження в кластері.
Багато провайдерів Kubernetes налаштовують etcd на використання взаємного TLS (клієнт і сервер перевіряють сертифікати один одного для автентифікації). Загальноприйнятої реалізації авторизації для API etcd немає, хоча така можливість існує. Оскільки моделі авторизації немає, будь-який сертифікат із клієнтським доступом до etcd можна використати для повного доступу до etcd. Зазвичай клієнтські сертифікати etcd, які використовуються лише для перевірки справності, також можуть надавати повний доступ на читання та запис.
На кожному вузлі кластера Kubernetes доступ до взаємодії з контейнерами контролює середовище виконання контейнерів (або середовища, якщо ви налаштували більше одного). Зазвичай середовище виконання контейнерів надає сокет Unix, до якого має доступ kubelet. Зловмисник із доступом до цього сокета може запускати нові контейнери або взаємодіяти із запущеними контейнерами.
На рівні кластера вплив такого доступу залежить від того, чи мають контейнери на скомпрометованому вузлі доступ до Secrets або інших конфіденційних даних, які зловмисник може використати для підвищення привілеїв на інших робочих вузлах чи в компонентах панелі управління.
root.hostPath, що охоплюють сокет середовища виконання контейнерів безпосередньо або через монтування батьківської теки. Крім того, монтування hostPath слід налаштовувати лише для читання, щоб зменшити ризик обходу обмежень тек зловмисниками.