#Согласование и ограничение разрешений Connectors

#Overview

Согласование и ограничение разрешений Connectors защищает момент, когда workload фактически использует Connector, особенно если доступ идет через Connectors Proxy. Этот механизм добавляет проверки на основе политики и временные выдачи разрешений поверх обычной модели разрешений Connector.

Эта возможность полезна, когда команде нужно иметь возможность обнаруживать Connector, но чувствительная операция, такая как продвижение в production registry, должна ждать согласования.

Функция зависит одновременно от enable-connectors-approval и enable-connector-proxy-permissions. Подробнее о флагах см. Feature Flags.

Если эти feature flags не включены вместе, поток, зависящий от согласования, не активен.

• Если enable-connector-proxy-permissions отключен, система не применяет слой разрешений capability для proxy, поэтому согласование не может ограничивать использование proxy.
• Если enable-connectors-approval отключен, система не создает и не оценивает runtime flow, связанный с согласованием.

В этом случае workloads используют обычную модель доступа Connector вместо доступа через proxy с ограничением по согласованию.

#Как это вписывается в модель разрешений

Эта функция не заменяет обычные правила видимости и области действия Connector, описанные в Connector Resource Levels and Permissions. Вместо этого она добавляет дополнительную проверку поверх runtime-использования.

На практике это означает, что одновременно верны два утверждения:

• Пользователь может читать Connector или использовать ограниченные API, которые уже разрешены обычной моделью разрешений через Connectors API
• Тот же workload по-прежнему может быть заблокирован от использования Connector через Connectors Proxy до прохождения проверок согласования

Такое разделение полезно, когда просмотр или выбор Connector допустим, но реальная операция за этим Connector должна контролироваться строже.

#Два основных ресурса

AccessPolicy отвечает на вопрос: «какое правило согласования и разрешений нужно применить здесь?»

AccessRequest отвечает на вопрос: «может ли этот workload использовать Connector прямо сейчас?»

Такое разделение сделано намеренно:

• оставайтесь в этом документе, если вам нужна общая картина возможностей и end-to-end flow
• перейдите к AccessPolicy, если нужно спроектировать долгоживущее правило
• перейдите к AccessRequest, если нужно изучить один runtime request или устранить проблему со статусом

#Понимание модели доступа

В этой возможности администраторы определяют модель доступа в AccessPolicy, а система оценивает каждое runtime-использование через AccessRequest.

На высоком уровне есть два распространенных способа разрешить workload использовать Connector через Connectors Proxy:

• defaultPermission: совпавшие workloads могут использовать Connector немедленно
• checkGrantedPermission: совпавшие workloads могут использовать Connector только после прохождения требуемых проверок

Это означает, что одна и та же возможность Connector может использоваться по-разному в зависимости от уровня риска:

• для общего внутреннего инструмента администратор может выдать defaultPermission, чтобы утвержденные namespaces или ServiceAccounts могли использовать его напрямую
• для production registry или production cluster администратор может потребовать проверки перед тем, как workload будет разрешено использовать Connector

Во время выполнения workload обычно получает доступ к целевому инструменту, монтируя конфигурацию Connector через Connectors CSI Driver, а затем вызывая proxy endpoint Connector. Если совпавшая политика требует согласования, система удерживает workload в ожидании до прохождения проверок, а затем выдает этому workload временное разрешение на proxy. Если проверки отклонены, CSI Driver монтирует только файл .error.json (без файлов конфигурации), и Pod запускается без пригодной для использования конфигурации Connector, из-за чего workload быстро завершается с ошибкой.

#Что именно ограничивается

Эта функция предназначена для ограничения использования Connectors Proxy, а не возможности читать сам объект Connector.

Это различие важно, потому что доступ через proxy обычно является точкой, в которой система внедряет учетные данные инструмента или разрешает чувствительные операции в целевой системе.

Типичные примеры:

• развертывание workload в защищенный k8s cluster
• продвижение artifact в production registry
• запуск workload, который должен использовать общий Connector только после прохождения проверки

Выданное разрешение ограничено конкретным контекстом workload, что снижает риск повторного использования учетных данных по сравнению с широким долгоживущим доступом.

#Взаимосвязь политики и запроса

AccessPolicy является переиспользуемой. Одна политика может применяться к одному Connector, группе Connectors или всем Connectors в namespace.

AccessRequest зависит от runtime. Он привязан к одному целевому Connector, одному запрашивающему субъекту и одному объекту контекста. Запрос фиксирует, какие политики совпали и были ли выполнены необходимые проверки, чтобы система могла решить, нужно ли синхронизировать ограниченное разрешение для этого workload.

Вместе они разделяют долгоживущее проектирование доступа и краткоживущую runtime-авторизацию:

• Используйте AccessPolicy для определения модели согласования и разрешений.
• Используйте AccessRequest для оценки одного фактического использования Connector.

#Пример Tekton Pipeline

Распространенный сценарий — Tekton pipeline, который продвигает artifact в production Harbor registry через Connector, такой как prod-harbor.

Чтобы использовать этот шаблон, пользователи подготавливают pipeline следующим образом:

• Администратор определяет AccessPolicy для чувствительного Connector, например prod-harbor.
• В определение pipeline включается ApprovalTask перед задачей продвижения.
• Задача продвижения монтирует Connector через CSI, а затем использует защищенный proxy path для доступа к целевому инструменту.

Здесь защищенный proxy path означает путь доступа Connectors Proxy, который workload использует для обращения к целевому инструменту через Connector.

После этого система автоматически обрабатывает поток доступа с учетом согласования:

• Система создает AccessRequest для Pod, который выполняет задачу продвижения.
• По умолчанию AccessRequest ищет ApprovalTask в том же PipelineRun.
• Если ApprovalTask одобрен, система выдает временное разрешение на proxy, и задача продвижения продолжается.
• Если ApprovalTask отклонен, CSI Driver монтирует файл .error.json вместо файлов конфигурации, и workload завершается с ошибкой, потому что не может получить доступ к Connector.
• Если ApprovalTask все еще в состоянии ожидания, workload продолжает ждать, пока не будет принято решение по согласованию.

Этот шаблон позволяет командам держать Connector доступным на платформе, но при этом требовать явного шага согласования перед тем, как чувствительное действие продвижения сможет его использовать.

Типичный AccessPolicy для этого шаблона выглядит так:

apiVersion: connectors.alauda.io/v1alpha1
kind: AccessPolicy
metadata:
  name: prod-harbor-approval
  namespace: devops
spec:
  connector:
    names:
      - prod-harbor
  checkGrantedPermission:
    spec:
      checks:
        - name: manual-approval
          ref:
            configMap:
              name: connectors-approvals-in-pipeline
      roleTemplate:
        ref:
          configMap:
            name: connectors-use-connectors-proxy-in-pod

В этом примере политика нацелена на один чувствительный Connector и предоставляет доступ через proxy к Pod только после того, как текущий ApprovalTask pipeline будет одобрен.

Два упомянутых ConfigMap — это встроенные шаблоны, предоставляемые компонентами Connectors:

• connectors-approvals-in-pipeline определяет правило проверки по умолчанию, которое сопоставляет ApprovalTask в том же PipelineRun
• connectors-use-connectors-proxy-in-pod определяет временное разрешение на proxy, выдаваемое Pod после согласования

#Типичные сценарии использования

• Продвижение production artifact, которое должно ждать согласования человеком
• Развертывание workload в production cluster только после согласования
• Развертывания в защищенные environments, где доступ через proxy должен контролироваться
• Общие Connectors, которыми можно пользоваться только после согласования для определенных запусков workload

#Что дальше

• AccessPolicy
• AccessRequest