#Connectors Permission Model

Connectors разделяет разрешения на обнаружение объектов интеграции и разрешения на использование этих интеграций для доступа к целевому инструменту.

С точки зрения пользователя, модель разрешений имеет три уровня:

• Могу ли я обнаружить этот Connector?
• Могу ли я просматривать данные из целевого инструмента через платформу?
• Может ли моя рабочая нагрузка действительно использовать этот Connector для доступа к целевому инструменту?

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

#Overview

Модель разрешений Connectors можно понять через три вопроса:

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

#User Capabilities

#Обнаружение типов и экземпляров Connector

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

Для пользователей это обычно означает:

• Если они могут читать ConnectorClass, они могут узнать, какие типы Connector доступны в кластере.
• Если они могут читать Connector, они могут обнаружить существование конкретной интеграции и выбрать её в рабочих процессах платформы.
• Если они могут управлять Connector или ConnectorClass, они могут изменять поведение интеграции, поэтому эти разрешения обычно ограничены администраторами.

Видимость Connector также зависит от области видимости. Connector с областью видимости namespace доступен только внутри своего namespace, тогда как Connector с областью видимости проекта или кластера доступен более широко. Подробнее об области видимости см. в разделе Connector Resource Levels and Permissions.

#Просмотр данных инструмента через Connectors API

Connectors API обычно используется UI платформы для чтения данных из целевого инструмента.

Распространённые примеры включают:

• Просмотр веток Git перед клонированием
• Просмотр тегов образов перед выбором версии артефакта
• Просмотр проектов, репозиториев или аналогичных данных селектора

Когда enable-connector-apis-permissions отключён, разрешения на чтение Connector достаточно для вызова Connectors API.

Когда enable-connector-apis-permissions включён, платформа разделяет обнаружение Connector и использование Connectors API, выполняя дополнительную проверку разрешения connectors/apis для целевого Connector.

На практике:

• Возможность видеть Connector не всегда достаточна.
• Пользователь может не иметь возможности просматривать ветки, теги или репозитории, если его роль не разрешает использование Connectors API для этого Connector.
• В Alauda Container Platform (ACP) встроенные роли, ориентированные на пользователей, обычно уже включают разрешения на чтение Connectors API, необходимые для распространённых сценариев UI.

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

Подробнее о самом потоке запросов см. в разделе Connector API.

#Использование Connector в рабочей нагрузке через Connectors Proxy

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

Распространённые примеры включают:

• Клонирование Git через прокси-эндпоинт
• Pull или push артефактов через прокси OCI или Harbor
• Позволить рабочей нагрузке использовать конфигурацию, сгенерированную драйвером CSI

Когда enable-connector-proxy-permissions отключён, разрешения на чтение Connector достаточно для использования Connectors Proxy.

Когда enable-connector-proxy-permissions включён, платформа разделяет обнаружение Connector и использование прокси, выполняя дополнительную проверку разрешения connectors/proxy для целевого Connector.

На практике:

• Возможность видеть production Connector всё ещё недостаточна.
• Рабочая нагрузка может не иметь возможности клонировать, выполнять pull, push или получать доступ к защищённой системе, пока ей не будет предоставлено разрешение на использование Connectors Proxy.
• Это разрешение обычно рассматривается более тщательно, чем Connectors API, поскольку оно представляет реальное использование целевого инструмента.

Подробнее о поведении прокси см. в разделах Connectors Proxy и Connectors CSI Driver.

#Где применяется Connectors Approval

Connectors Approval не является самой моделью разрешений. Это дополнительный уровень контроля, построенный поверх Connectors Proxy.

Когда включены оба флага enable-connectors-approval и enable-connector-proxy-permissions:

• Платформа может требовать одобрения перед тем, как рабочая нагрузка получит разрешение использовать защищённый Connector.
• AccessPolicy определяет, какие Connectors используют контроль на основе одобрения.
• AccessRequest фиксирует конкретный запрос от рабочей нагрузки к Connector.

С точки зрения пользователя, это означает, что Connectors Approval в основном влияет на то, может ли рабочая нагрузка действительно использовать Connector для выполнения таких действий, как клонирование, pull, push или деплоймент. Это не заменяет базовые разрешения на видимость и управление ConnectorClass и Connector.

Если вы уже понимаете три вышеуказанных уровня и хотите ознакомиться с потоком, связанным с одобрением, продолжайте с разделом Connectors Approval & Permission Gating. Для деталей API см. AccessPolicy и AccessRequest.

#Пример: Один Connector, разные пользовательские сценарии

Рассмотрим Connector Harbor с областью видимости проекта и статусом production:

• Разработчик может видеть этот Connector в UI.
• Тот же разработчик может также просматривать теги образов через Connectors API, поскольку Alauda Container Platform (ACP) обычно предоставляет разрешения на чтение API для сценариев выбора.
• Но сборочная рабочая нагрузка может не иметь возможности выполнить push образа через Connectors Proxy.
• Если для этого Connector требуется одобрение, рабочая нагрузка должна пройти необходимые проверки перед предоставлением доступа к прокси.

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

#Advanced: Как платформа отображает эти возможности

Вышеописанные возможности для пользователей реализованы с помощью Kubernetes RBAC.

#Разрешения на ресурсы

Разрешения на ресурсы контролируют, могут ли пользователи обнаруживать или управлять объектами интеграции:

• connectorclasses
• connectors

Эти разрешения определяют, могут ли пользователи вообще видеть типы Connector и экземпляры Connector.

#Разрешения на возможности

Разрешения на возможности контролируют, могут ли пользователи использовать эти объекты интеграции через конкретные компоненты Connectors:

• connectors/apis соответствует Connectors API
• connectors/proxy соответствует Connectors Proxy

Эти разрешения на возможности применяются только при включённых соответствующих feature flags.

• Если feature flags отключены, разрешения на чтение Connector остаются достаточными для Connectors API или Connectors Proxy.
• Если feature flags включены, платформа выполняет дополнительные проверки connectors/apis или connectors/proxy, описанные выше.

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

#Встроенные роли Alauda Container Platform (ACP)

Alauda Container Platform (ACP) предоставляет встроенные роли из двух источников:

• connectors-operator предоставляет базовые роли для доступа к ConnectorClass и Connector.
• Расширения Connector предоставляют дополнительные разрешения только для чтения Connectors API для распространённых операций, таких как просмотр веток, тегов, проектов или репозиториев.

На практике это означает, что Alauda Container Platform (ACP) обычно поддерживает распространённые сценарии UI только для чтения из коробки, при этом использование Connectors Proxy рассматривается как более чувствительная возможность.

#Summary

Модель разрешений Connectors разделяет три пользовательские возможности:

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

Это разделение позволяет платформе сохранять простоту повседневных сценариев UI, при этом защищая доступ во время выполнения к чувствительным внешним системам.

#Next Steps

• Connectors Approval & Permission Gating
• AccessPolicy
• AccessRequest
• Connector Resource Levels and Permissions
• Connectors API
• Connectors Proxy
• Feature Flags
• Architecture