Kubernetes v1.35: До kuberc додано обмеження щодо виконуваних файлів, які викликаються kubeconfigs через exec plugin allowList

Автор: Peter Engelbert (Microsoft) Ben Petersen (Microsoft) | Перекладач(і): Андрій Головінін |

Чи знали ви, що kubectl може запускати довільні виконувані файли, включаючи скрипти оболонки, з повними правами користувача, який їх викликає, і навіть без вашого відома? Кожного разу, коли ви завантажуєте або автоматично генеруєте kubeconfig, поле users[n].exec.command може вказати виконуваний файл для отримання облікових даних від вашого імені. Не зрозумійте мене неправильно, це неймовірна функція, яка дозволяє вам пройти автентифікацію в кластері за допомогою зовнішніх постачальників ідентифікації. Проте, ви, мабуть, бачите проблему: чи знаєте ви точно, які виконувані файли ваш kubeconfig запускає у вашій системі? Чи довіряєте ви конвеєру, який згенерував ваш kubeconfig? Якщо на код, що генерує kubeconfig, було здійснено атаку на ланцюжок постачання, або якщо конвеєр генерації було скомпрометовано, зловмисник може робити неприємні речі з вашою машиною, змушуючи ваш kubeconfig виконувати довільний код.

Щоб надати користувачам більше контролю над тим, що виконується в їхній системі, SIG-Auth та SIG-CLI додали політику втулків для облікових даних та список дозволених елементів як бета-функцію до Kubernetes 1.35. Це доступно для всіх клієнтів, які використовують бібліотеку client-go, шляхом заповнення структури ExecProvider.PluginPolicy у конфігурації REST. Щоб розширити вплив цієї зміни, Kubernetes v1.35 також дозволяє керувати цим без написання жодної лінії програмного коду. Ви можете налаштувати kubectl для застосування політики та списку дозволеного, додавши два поля до файлу конфігурації kuberc: credentialPluginPolicy та credentialPluginAllowlist. Додавання одного або обох цих полів обмежує втулки облікових даних, які kubectl може виконувати.

Як це працює

Повний опис цієї функції доступний в нашій офіційній документації до kuberc, але в цьому блозі ми надамо короткий огляд нових налаштувань безпеки. Нові функції знаходяться в стадії бета-тестування і доступні без використання будь-яких функціональних обмежень.

Наступний приклад є найпростішим: просто не вказуйте нові поля.

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference

Це дозволить kubectl працювати як і раніше, а всі втулки будуть дозволені.

Наступний приклад функціонально ідентичний, але він є чіткішим і тому кращим, якщо це саме те, що вам потрібно:

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: AllowAll

Якщо ви не знаєте, чи ви використовуєте exec втулки для облікових даних, спробуйте встановити політику на DenyAll:

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: DenyAll

Якщо ви використовуєте втулки для введення облікових даних, ви швидко зʼясуєте, що намагається виконати kubectl. Ви отримаєте помилку, подібну до наведеної нижче.

Неможливо підключитися до сервера: отримання облікових даних: втулок «cloudco-login» не дозволений: політика встановлена на «DenyAll»

Якщо вам не вистачає інформації для усунення проблеми, збільште детальність логування під час виконання наступної команди. Наприклад:

# збільшити або зменшити детальність, якщо проблема все ще залишається незрозумілою
kubectl get pods --verbosity 5

Вибіркові дозволи для втулків

Що робити, якщо для щоденної роботи вам потрібен втулок cloudco-login? Саме для цього існує третій варіант політики — Allowlist. Щоб дозволити використання певного втулка, встановіть політику та додайте credentialPluginAllowlist:

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: Allowlist
credentialPluginAllowlist:
  - name: /usr/local/bin/cloudco-login
  - name: get-identity

Ви помітите, що в allowlist є два записи. Один з них вказаний повним шляхом, а інший, get-identity, є лише базовим іменем. Коли ви вказуєте лише базове імʼя, повний шлях буде шукатися за допомогою exec.LookPath, який не розширює globbing і не обробляє символи-замінники. Globbing наразі не підтримується. Обидві форми (базова назва та повний шлях) є прийнятними, але повний шлях є кращим, оскільки він ще більше звужує діапазон дозволених бінарних файлів.

Майбутні вдосконалення

Наразі запис у списку дозволеного (allowlist) має лише одне поле, name. У майбутньому ми (Kubernetes SIG CLI) хочемо додати інші вимоги. Однією з корисних ідей є перевірка контрольної суми, за допомогою якої, наприклад, бінарний файл можна буде запустити, тільки якщо він має суму sha256 b9a3fad00d848ff31960c44ebb5f8b92032dc085020f857c98e32a5d5900ff9c і знаходиться за адресою /usr/bin/cloudco-login.

Інша можливість — дозволити лише бінарні файли, підписані одним із довірених ключів підпису.

Приєднуйтесь

Політика втулків автентифікації все ще перебуває на стадії розробки, і ми дуже зацікавлені у ваших відгуках. Ми хотіли б дізнатися, що вам подобається в ній і які проблеми ви хотіли б, щоб вона вирішувала. Або, якщо у вас є час, щоб долучитися до розробки одного з вищезазначених вдосконалень, це буде чудовим способом розпочати співпрацю з Kubernetes. Приєднуйтесь до обговорення в Slack: