#AccessRequest

#Обзор

AccessRequest — это объект времени выполнения в пределах namespace, предназначенный для управления доступом к Connector через механизм утверждения.

Он связывает вместе:

• субъект, запрашивающий доступ
• целевой Connector
• объект контекста времени выполнения, для которого запрашивается доступ

В модели утверждения Connectors, AccessPolicy определяет правило, а AccessRequest отслеживает одну конкретную попытку доступа.

В большинстве случаев пользователи не создают AccessRequest вручную. Он создаётся автоматически, когда рабочая нагрузка пытается использовать Connector через Connectors CSI Driver, не имея при этом необходимого разрешения connectors/proxy.

#Доступность

AccessRequest является частью функционала Connectors Approval.

Перед использованием этого процесса необходимо включить:

• enable-connectors-approval
• enable-connector-proxy-permissions

Для получения дополнительной информации смотрите Feature Flags.

#Понимание AccessRequest

#Что он представляет

AccessRequest фиксирует одну конкретную runtime-запрос, а не переиспользуемую политику.

Основные поля:

• spec.subject: кто запрашивает доступ. В сценариях с утверждением для CSI это обычно ServiceAccount рабочей нагрузки.
• spec.connectorRef: к какому Connector запрашивается доступ. Ссылаемый Connector всегда находится в том же namespace, что и AccessRequest.
• spec.context.objectRef: к какому объекту времени выполнения привязан этот запрос. В настоящее время поддерживается только Pod.

Этот ресурс специально ориентирован на runtime:

• он отслеживает прогресс утверждения для одного контекста рабочей нагрузки
• он предоставляет временное разрешение только после успешных проверок
• он становится неактуальным после завершения этого контекста рабочей нагрузки

#Как он связан с AccessPolicy

AccessPolicy отвечает на вопросы:

• какие Connectors требуют утверждённого доступа
• какие проверки должны быть пройдены
• какое разрешение должно быть выдано после утверждения

AccessRequest отвечает на другой вопрос:

• для данного субъекта, Connector и контекста Pod, был ли доступ утверждён и синхронизирован

Это основное разграничение между двумя объектами:

• AccessPolicy описывает переиспользуемое правило
• AccessRequest описывает одну runtime-оценку этого правила

Когда AccessRequest впервые совпадает с политиками, контроллер сохраняет снимки совпавших записей AccessPolicy.spec в status.policies. Это обеспечивает стабильность запроса в процессе выполнения, даже если исходная политика изменится позже.

Схему политики смотрите в AccessPolicy API Reference.

#Как он создаётся и обрабатывается

Типичный процесс:

1. Рабочая нагрузка пытается использовать Connector через Connectors Proxy или Connectors CSI Driver.
2. Если у рабочей нагрузки уже есть необходимое разрешение connectors/proxy для данного Connector и контекста Pod, AccessRequest не создаётся.
3. Если разрешение отсутствует, поток CSI создаёт или повторно использует AccessRequest.
4. Контроллер проверяет контекст Pod, разрешает целевой Connector и сопоставляет ресурсы AccessPolicy с checkGrantedPermission.
5. Контроллер находит совпадающие проверки, например ApprovalTask, и записывает их результаты в status.policies[].matchedChecks.
6. После успешного прохождения всех проверок система создаёт временные Role и RoleBinding для запрашивающего субъекта.
7. По завершении Pod, его удалении или недействительности Connector временные разрешения удаляются.

Таким образом, AccessRequest является runtime-мостом между статусом утверждения и фактической синхронизацией разрешений RBAC.

#Пример

Ниже приведён пример структуры одного запроса:

apiVersion: connectors.alauda.io/v1alpha1
kind: AccessRequest
metadata:
  name: prod-harbor-build-pod-7x9k2
  namespace: connectors-shared
spec:
  subject:
    kind: ServiceAccount
    name: builder
    namespace: cicd
  connectorRef:
    name: prod-harbor
  context:
    objectRef:
      apiVersion: v1
      kind: Pod
      name: build-pod-7x9k2
      namespace: cicd

Этот пример демонстрирует важный шаблон:

• AccessRequest хранится в namespace Connector: connectors-shared
• запрашивающий ServiceAccount находится в namespace рабочей нагрузки: cicd
• запрос привязан к одному Pod, а не ко всем будущим Pod, использующим тот же ServiceAccount

#Чтение статуса

AccessRequest.status показывает, на каком этапе runtime-процесса утверждения находится запрос — заблокирован он или завершён.

Важные условия:

• ContextObjectValid: существует ли связанный Pod и активен ли он
• ConnectorResolved: существует ли указанный Connector
• AccessPolicyMatched: совпала ли какая-либо утверждённая AccessPolicy с этим запросом
• AccessCheckReady: пройдены ли проверки, находятся в ожидании или отклонены
• AccessPermissionSync: синхронизировано ли временное разрешение, ожидает синхронизации или уже удалено
• Ready: общий результат, выведенный из вышеуказанных условий

Распространённые интерпретации:

• Ожидание утверждения: AccessCheckReady = Unknown с причиной Pending
• Доступ предоставлен и доступен: Ready = True и AccessPermissionSync = True с причиной Synced
• Доступ отклонён: AccessCheckReady = False с причиной Rejected
• Разрешение удалено после завершения runtime: AccessPermissionSync = True с причиной PermissionCleanUp

#Операционные заметки

• AccessRequest.spec неизменяем после создания. Если субъект, Connector или контекст изменяются, используется другой запрос.
• AccessRequest обычно существует только для доступа с утверждением. Если ни одна политика утверждения не совпадает, он не становится переиспользуемой записью разрешений.
• Сгенерированное разрешение ограничено как запрошенным Connector, так и контекстом runtime Pod, что помогает обеспечивать принцип наименьших привилегий.

#Что дальше

• Повторно изучить общий процесс в Connectors Approval & Permission Gating
• Повторно изучить дизайн политики в AccessPolicy
• Ознакомиться со схемой в AccessRequest API Reference
• Узнать, как определяются правила утверждения в AccessPolicy API Reference