# Посібник із зміцнення безпеки — Налаштування планувальника

> Інформація про те, як зробити планувальник Kubernetes безпечнішим.

---

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

---

<!-- overview -->
<a class='glossary-tooltip' title='Компонент панелі управління, що відстежує створені Podʼи, які ще не розподілені по вузлах, і обирає вузол, на якому вони працюватимуть.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/generated/kube-scheduler/' target='_blank' aria-label='Планувальник'>Планувальник</a> у Kubernetes є одним з критично важливих компонентів <a class='glossary-tooltip' title='Шар оркестрування контейнерів, який надає API та інтерфейси для виявлення, розгортання та управління життєвим циклом контейнерів.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/glossary/?all=true#term-control-plane' target='_blank' aria-label='панелі управління'>панелі управління</a>.

У цьому документі описано, як покращити стан безпеки планувальника.

Неправильно налаштований планувальник може мати наслідки для безпеки. Такий планувальник може націлюватися на певні вузли і виселяти робочі навантаження або програми, які спільно використовують вузол та його ресурси.  Це може допомогти зловмиснику провести [Yo-Yo атаку](https://arxiv.org/abs/2105.00542): атаку на вразливий автомасштабувач.

<!-- body -->
## Конфігурація kube-scheduler {#kube-scheduler-configuration}

### Параметри командного рядка автентифікації та авторизації планувальника {#scheduler-authentication-authorization-command-line-options}

Під час налаштування автентифікації слід переконатися, що автентифікація kube-scheduler залишається узгодженою з автентифікацією kube-api-server. Якщо у якомусь запиті відсутні заголовки автентифікації, [автентифікація має відбуватися через kube-api-server, що забезпечить узгодженість автентифікації у кластері](/docs/tasks/extend-kubernetes/configure-aggregation-layer/#original-request-username-and-group).

- `authentication-kubeconfig`: Переконайтеся, що ви надали правильний kubeconfig, щоб планувальник міг отримати параметри конфігурації автентифікації з сервера API. Цей файл kubeconfig має бути захищено суворими правами доступу до файлів.
- `authentication-tolerate-lookup-failure`: Встановіть значення `false`, щоб переконатися, що планувальник _завжди_ шукає конфігурацію автентифікації на сервері API.
- `authentication-skip-lookup`: Встановіть це значення у `false`, щоб переконатися, що планувальник _завжди_ шукає свою конфігурацію автентифікації на сервері API.
- `authorization-always-allow-paths`: Ці шляхи повинні відповідати даними, придатними для анонімної авторизації. Стандартно `/healthz,/readyz,/livez`.
- `profiling`: Значення `false` для вимкнення точок доступу профілювання, які надають налагоджувальну інформацію, але які не слід вмикати на операційних кластерах, оскільки вони становлять ризик відмови в обслуговуванні або витоку інформації. Аргумент `--profiling` застарілий і тепер може бути заданий за допомогою [KubeScheduler DebuggingConfiguration](https://kubernetes.io/docs/reference/config-api/kube-scheduler-config.v1/#DebuggingConfiguration). Профілювання можна вимкнути у конфігурації kube-scheduler, встановивши `enableProfiling` у значення `false`.
- `requestheader-client-ca-file`: Не передавайте цей аргумент.

### Параметри командного рядка для мережевих налаштувань планувальника {#scheduler-networking-command-line-options}

- `bind-address`: У більшості випадків kube-scheduler не потребує зовнішнього доступу. Встановлення адреси привʼязки на `localhost` є безпечною практикою.
- `permit-address-sharing`: Встановіть це значення у `false`, щоб  відключити спільне використання зʼєднання через `SO_REUSEADDR`. `SO_REUSEADDR` може призвести до повторного використання завершених зʼєднань, які перебувають у стані `TIME_WAIT`.
- `permit-port-sharing`: Стандартно: `false`. Використовуйте стандартне значення, якщо ви не впевнені, що розумієте наслідки для безпеки.

### Параметри командного рядка планувальника для TLS {#scheduler-tls-command-line-options}

- `tls-cipher-suites`: Завжди надавайте список бажаних наборів шифрів. Це гарантує, що шифрування ніколи не відбуватиметься за допомогою ненадійних наборів шифрів.

## Налаштування планувальника для власних планувальників користувачів {#scheduling-configurations-for-custom-schedulers}

При використанні власних планувальників користувачів, заснованих на коді планування Kubernetes, адміністратори кластерів повинні бути обережними з втулками, які використовують [точки розширення](/docs/reference/scheduling/config/#extension-points) `queueSort`, `prefilter`, `filter` або `permit`. Ці точки розширення контролюють різні етапи процесу планування, і неправильна конфігурація може вплинути на поведінку kube-scheduler у вашому кластері.

### Основні міркування {#key-considerations}

- Одночасно може бути увімкнено лише один втулок, який використовує точку розширення `queueSort`. Усі втулки, які використовують `queueSort`, слід ретельно перевіряти.
- Втулки, які реалізують точку розширення `prefilter` або `filter`, потенційно можуть позначити всі вузли як такі, що не підлягають розмішеню ресурсів. Це може призвести до зупинки планування нових podʼів.
- Втулки, які реалізують точку розширення `permit`, можуть перешкоджати або затримувати привʼязування Podʼів. Такі втулки повинні бути ретельно перевірені адміністратором кластера.

Якщо ви використовуєте втулок, який не належить до [стандартних](/docs/reference/scheduling/config/#scheduling-plugins), розгляньте можливість вимкнення точок розширення `queueSort`, `filter` і `permit` наступним чином:

```yaml
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: my-scheduler
    plugins:
      # Вимкніть певні втулки для різних точок розширення
      # Ви можете вимкнути всі втулки для точки розширення за допомогою "*"
      queueSort:
        disabled:
        - name: "*"             # Вимкнути всі втулки queueSort
      # - name: "PrioritySort"  # Вимкнути певний втулок queueSort
      filter:
        disabled:
        - name: "*"                 # Вимкнути всі втулки фільтрів
      # - name: "NodeResourcesFit"  # Вимкнути певний втулок фільтрування
      permit:
        disabled:
        - name: "*"               # Вимкнути всі втулки дозволів
      # - name: "TaintToleration" # Вимкнути певний втулок
```

Це створить профіль планувальника `my-scheduler`. Щоразу, коли у файлі `.spec` для Podʼа не вказано значення `.spec.schedulerName`, для цього Podʼа запускається kube-scheduler, використовуючи його основну конфігурацію та стандартні втулки. Якщо ви визначаєте Pod зі значенням `.spec.schedulerName`, рівним `my-scheduler`, kube-scheduler запускається, але з власною конфігурацією користувача; у цій власній конфігурації користувача пункти розширення `queueSort`, `filter` і `permit` вимкнено. Якщо ви використовуєте цю конфігурацію KubeSchedulerConfiguration і не запускаєте жодного власного планувальника користувача, а потім визначаєте Pod з параметром `.spec.schedulerName`, встановленим на `nonexistent-scheduler` (або будь-яке інше імʼя планувальника, якого не існує у вашому кластері), події для pod не генеруватимуться.

## Заборона маркування вузлів {#disallow-labeling-nodes}

Адміністратор кластера повинен переконатися, що користувачі кластера не можуть призначати мітки вузлам. Зловмисник може використовувати `nodeSelector` для планування робочих навантажень на вузлах, де ці навантаження не повинні бути присутніми.