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

LLMS index: [llms.txt](/llms.txt)

---

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

Щоб надати користувачам більше контролю над тим, що виконується в їхній системі, [SIG-Auth](https://git.k8s.io/community/sig-auth) та [SIG-CLI](https://git.k8s.io/community/sig-cli) додали політику втулків для облікових даних та список дозволених елементів як бета-функцію до Kubernetes 1.35. Це доступно для всіх клієнтів, які використовують бібліотеку `client-go`, шляхом заповнення структури [ExecProvider.PluginPolicy](https://github.com/kubernetes/client-go/blob/master/tools/clientcmd/api/types.go#L290) у конфігурації REST. Щоб розширити вплив цієї зміни, Kubernetes v1.35 також дозволяє керувати цим без написання жодної лінії програмного коду. Ви можете налаштувати `kubectl` для застосування політики та списку дозволеного, додавши два поля до файлу конфігурації `kuberc`: `credentialPluginPolicy` та `credentialPluginAllowlist`. Додавання одного або обох цих полів обмежує втулки облікових даних, які `kubectl` може виконувати.

## Як це працює {#how-it-works}

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

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

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

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

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

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

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

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

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

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

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

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

### Вибіркові дозволи для втулків {#selectively-allowing-plugins}

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

```yaml
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 наразі не підтримується. Обидві форми (базова назва та повний шлях) є прийнятними, але повний шлях є кращим, оскільки він ще більше звужує діапазон дозволених бінарних файлів.

### Майбутні вдосконалення {#future-enhancements}

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

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

## Приєднуйтесь {#get-involved}

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

- [#sig-cli](https://kubernetes.slack.com/archives/C2GL57FJ4),
- [#sig-auth](https://kubernetes.slack.com/archives/C0EN96KUY).