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

Планувальник у Kubernetes є одним з найважливіших компонентів панелі управління.

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

Неправильно налаштований планувальник може мати наслідки для безпеки. Такий планувальник може вражати певні вузли і виселяти робочі навантаження або програми, які спільно використовують вузол та його ресурси. Це може допомогти зловмиснику провести Yo-Yo атаку: атаку на вразливий автопланувальник.

Конфігурація kube-scheduler

Параметри командного рядка автентифікації та авторизації планувальника

Під час налаштування автентифікації слід переконатися, що автентифікація kube-scheduler залишається узгодженою з автентифікацією kube-api-server. Якщо у якомусь запиті відсутні заголовки автентифікації, автентифікація має відбуватися через kube-api-server, що забезпечить узгодженість автентифікації у кластері.

• 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. Профілювання можна вимкнути у конфігурації kube-scheduler, встановивши enableProfiling у значення false.
• requestheader-client-ca-file: Не передавайте цей аргумент.

Параметри командного рядка для мережевих налаштувань планувальника

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

Параметри командного рядка планувальника для TLS

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

Налаштування планувальника для власних планувальників користувачів

При використанні власних планувальників користувачів, заснованих на коді плануваника Kubernetes, адміністратори кластерів повинні бути обережними з втулками, які використовують точки розширення queueSort, prefilter, filter або permit. Ці точки розширення контролюють різні етапи процесу планування, і неправильна конфігурація може вплинути на поведінку kube-scheduler у вашому кластері.

Основні міркування

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

Якщо ви використовуєте втулок, який не належить до стандартних, розгляньте можливість вимкнення точок розширення queueSort, filter і permit наступним чином:

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

Заборона маркування вузлів

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