Адміністрування кластера

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

1: Посилення безпеки динамічного виділення ресурсів у вашому кластері

1 - Посилення безпеки динамічного виділення ресурсів у вашому кластері

Ця сторінка показує адміністраторам кластера, як посилити авторизацію для динамічного виділення ресурсів (DRA) з акцентом на доступ з мінімальними привілеями для оновлень статусу ResourceClaim.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Для перевірки версії введіть kubectl version.
У вашому кластері налаштовано динамічне виділення ресурсів.
Ви можете редагувати ресурси RBAC та перезапускати або розгортати компоненти DRA.

Визначте компоненти DRA, які оновлюють статус

Задокументуйте, які ідентичності (зазвичай ServiceAccount) оновлюють статус ResourceClaim у вашому кластері. Типові компоненти, що записують статус:

kube-scheduler або власний контролер виділення
драйвери DRA, локальні для вузла
багатовузлові контролери статусу DRA

Надання мінімально необхідних дозволів для синтетичних субресурсів

Починаючи з Kubernetes v1.36, оновлення статусу DRA вимагають дозволів на синтетичні субресурси на додаток до resourceclaims/status.

Надання дозволів для планувальника та контролера виділення

Застосуйте роль, яка дозволяє оновлення, повʼязані з привʼязкою:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: dra-binding-updater
rules:
  - apiGroups: ["resource.k8s.io"]
    resources: ["resourceclaims/status"]
    verbs: ["get", "patch", "update"]
  - apiGroups: ["resource.k8s.io"]
    resources: ["resourceclaims/binding"]
    verbs: ["patch", "update"]

Надання дозволів для драйверів, локальних для вузла

Використовуйте вузлово-орієнтовані дієслова для драйверів, локальних для вузла:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: dra-node-driver-status-updater
rules:
  - apiGroups: ["resource.k8s.io"]
    resources: ["resourceclaims/status"]
    verbs: ["get", "patch", "update"]
  - apiGroups: ["resource.k8s.io"]
    resources: ["resourceclaims/driver"]
    verbs: ["associated-node:patch", "associated-node:update"]
    resourceNames: ["dra.example.com"]

Надання дозволів для багатовузлового контролера лише за потреби

Використовуйте arbitrary-node:* лише для компонентів, які повинні оновлювати статус з будь-якого вузла:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: dra-multinode-status-updater
rules:
  - apiGroups: ["resource.k8s.io"]
    resources: ["resourceclaims/status"]
    verbs: ["get", "patch", "update"]
  - apiGroups: ["resource.k8s.io"]
    resources: ["resourceclaims/driver"]
    verbs: ["arbitrary-node:patch", "arbitrary-node:update"]
    resourceNames: ["dra.example.com"]

Привʼязка ролей до конкретних ідентичностей

Створіть обʼєкти ClusterRoleBinding для кожної ідентичності компонента та уникайте спільного використання широкої ролі між не повʼязаними між собою компонентами DRA.

Обмежте правила resourceclaims/driver за допомогою resourceNames, де це можливо, щоб ідентичність могла оновлювати статус лише для конкретного драйвера DRA, яким вона керує.

Перевірка та моніторинг

Перевірте, що кожна ідентичність має лише необхідні дієслова та субресурси.
Підтвердіть, що оновлення статусу DRA працюють після розгортання.
Спостерігайте за подіями аудиту API-сервера щодо відхилених запитів resourceclaims/binding та resourceclaims/driver.