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

Планувальник у 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-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ʼа не буде згенеровано жодних подій.

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

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