#Архитектура

#Connector

Connector — это ресурс, представляющий интегрированный экземпляр конкретного инструмента. Настраивая URL доступа к инструменту и данные аутентификации, мы можем создать экземпляр для интеграции инструмента.

Например, интеграция https://github.com с использованием GitHub Private Access Token достигается через Connector.

В Kubernetes Connector является пользовательским ресурсом на уровне namespace. Пользователи могут создавать несколько Connector в одном namespace для интеграции разных инструментов.

Например, в namespace default можно создать как Connector для интеграции https://github.com, так и Connector для интеграции https://example.harbor.com/.

Администраторы платформы могут управлять интеграциями инструментов по всему кластеру, управляя ресурсами Connector.

#ConnectorClass

ConnectorClass определяет методы доступа и спецификации поведения для конкретных типов инструментов. Он задаёт параметры, необходимые при интеграции с определённым типом инструмента, такие как адрес инструмента и данные аутентификации.

Например, Git ConnectorClass определяет конфигурационные элементы, которые нужно предоставить при интеграции с Git-инструментами, включая адрес Git-сервиса и данные аутентификации Basic-Auth.

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

Например, можно определить Harbor ConnectorClass для поддержки интеграции с репозиторием образов Harbor, MySQL ConnectorClass для интеграции с базами данных MySQL или Jira ConnectorClass для интеграции с инструментами управления проектами Jira.

#Connectors Proxy

Connectors Proxy — это ключевая возможность системы Connectors, обеспечивающая безопасный доступ к интегрированным инструментам без необходимости передачи секретов. Обычно он работает как HTTP-сервис, который может выступать в роли как прямого (forward), так и обратного (reverse) прокси для клиентских приложений.

Когда клиенты обращаются к ресурсам инструмента через Connectors Proxy, прокси автоматически внедряет необходимые учетные данные аутентификации в запросы, обеспечивая беспрепятственный доступ без необходимости клиентам напрямую обрабатывать учетные данные. Такой подход обеспечивает значительное преимущество в безопасности:

• Доступ без секретов: устраняет необходимость напрямую распространять учетные данные инструмента клиентам, используя краткоживущие токены, выдаваемые Kubernetes. Это предотвращает утечку учетных данных в средах клиентов, таких как логи или переменные окружения.

Для поддержки различных требований аутентификации инструментов платформа поддерживает как встроенные, так и пользовательские реализации прокси. Каждый ConnectorClass может предоставлять собственный прокси-сервис, обеспечивая гибкость для удовлетворения специфических требований аутентификации инструментов.

#Встроенный Connectors Proxy

Встроенная реализация обеспечивает полную поддержку протоколов HTTP/HTTPS с методами аутентификации Basic Auth и Bearer Token. Предоставляет возможности как прямого, так и обратного прокси для максимальной гибкости.

Используется ConnectorClass: K8s ConnectorClass, Git ConnectorClass

#Пользовательский Connectors Proxy

Для инструментов, требующих специализированных механизмов аутентификации, могут быть разработаны пользовательские реализации прокси.

Пример: OCI ConnectorClass использует пользовательский OCI Plugin Proxy, поддерживающий протокол OCI с авторизацией Bearer Token для реестров, таких как Harbor и CNCF Distribution Registry.

• Подробнее: Connectors Proxy

#Управление разрешениями для Connectors Proxy

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

Управление разрешениями для Connectors Proxy вступает в силу только при включённом флаге функции enable-connector-proxy-permissions. По умолчанию, когда этот флаг отключён, клиенту достаточно иметь разрешение get на ресурс Connector, чтобы использовать этот Connector через Connectors Proxy.

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

Connectors Approval построен поверх этого управления разрешениями прокси. Его роль — дополнительно решать, может ли рабочая нагрузка получить доступ к использованию Connectors Proxy для защищённого Connector.

Для более подробного объяснения, как это вписывается в общую модель разрешений, см. Connectors Permission Model.

#Connectors API

Connectors API предоставляет возможности доступа к внутренним ресурсам инструментов на основе экземпляров Connector. Например, для Git Connector Connectors API может получить список веток (References) в Git-репозитории.

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

Система поддерживает два способа доступа к ресурсам инструментов через API:

• Оригинальный API инструмента: когда ConnectorClass предоставляет возможности Proxy Service, клиенты могут напрямую обращаться к оригинальному API инструмента через Connector API. Система автоматически перенаправляет запросы к Proxy Service инструмента, выполняет внедрение аутентификации и возвращает оригинальные данные инструмента.
• Пользовательский API: использование пользовательских API, предоставляемых для ConnectorClass, которые предлагают расширенные возможности сверх оригинального API инструмента.

Этот API очень полезен в практических приложениях, таких как:

• Получение списка тегов контейнерных образов при создании приложений
• Получение списка веток (References) репозитория кода при операции Git Clone
• Прямой доступ к специфичным API инструментов, когда ConnectorClass поддерживает Proxy Service

Реализация Connectors API основана на базовых возможностях, предоставляемых ConnectorClass API.

#Управление разрешениями для Connectors API

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

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

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

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

Такое разделение позволяет платформе сохранять удобство обнаружения Connector при одновременном контроле того, какие пользователи могут запрашивать данные инструмента через API. Для более подробного объяснения см. Permissions for Connectors API.

#Connectors Permission Model

Система Connectors разделяет разрешения на ресурсы и разрешения на возможности.

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

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

В рамках этой модели Connectors Approval применяется только когда рабочая нагрузка использует Connector через Connectors Proxy. Другими словами, он контролирует, может ли рабочая нагрузка фактически использовать этот Connector для выполнения действий во время выполнения, таких как clone, pull, push или deployment, и предоставляет этот доступ только после прохождения необходимых проверок.

Для подробного объяснения того, как пользователи взаимодействуют с этой моделью и как встроенные разрешения Alauda Container Platform (ACP) влияют на неё, см. Connectors Permission Model.

#ConnectorClass API

ConnectorClass API определяет API, предоставляемые конкретными типами инструментов.

Разные типы инструментов могут предлагать различные возможности API, например:

• Git ConnectorClass API может предоставлять возможность получения списка веток репозитория кода
• OCI ConnectorClass API может предоставлять возможность получения списка тегов для репозиториев артефактов

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

#Connectors CSI Driver

Для упрощения использования возможностей Connectors-Proxy рабочими нагрузками K8S можно использовать Connectors CSI Driver.

Connectors CSI Driver может монтировать сгенерированное содержимое шаблонов конфигурационных файлов, поддерживаемых внутри ConnectorClass, в рабочую нагрузку. Конфигурационный файл может включать информацию для доступа к Connectors Proxy, позволяя пользователям использовать возможности Connectors Proxy с минимальными изменениями в их исходных скриптах.

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

#Connectors Approval & Permission Gating

Connectors Approval & Permission Gating расширяет стандартную модель разрешений Connector для чувствительных операций. Он использует AccessPolicy для определения, кто может использовать Connectors через Connectors Proxy, либо предоставляя defaultPermission сразу, либо предоставляя доступ к прокси только после прохождения проверок, связанных с одобрением.

Эта функция зависит от включения обоих флагов: enable-connectors-approval и enable-connector-proxy-permissions.

Если эти флаги не включены одновременно, специфичный для одобрения поток не активен.

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

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

Если пользователи не хотят ограничивать использование Connector, они всё равно могут создать AccessPolicy с defaultPermission, чтобы соответствующие рабочие нагрузки могли использовать Connector через Connectors Proxy без ожидания проверок одобрения.

Connectors Approval & Permission Gating построен вокруг двух взаимодополняющих ресурсов:

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

Типичный сценарий: Pod или задача pipeline монтирует Connector через Connectors CSI Driver, система оценивает соответствующий AccessPolicy, создаёт или обновляет AccessRequest для этой рабочей нагрузки, ожидает необходимых проверок, предоставляет доступ к Connectors Proxy для рабочей нагрузки и позже отзывает его после завершения работы нагрузки.

Connectors Approval & Permission Gating предназначен для сценариев, таких как продвижение артефактов в production-реестр или другие защищённые операции с инструментами, где обнаружение и фактическое использование должны контролироваться отдельно.

Для пошагового объяснения этой возможности см. Connectors Approval & Permission Gating, затем AccessPolicy и, наконец, AccessRequest.

#ResourceInterface

ResourceInterface — это стандартизованная абстракция, определяющая, как внешние ресурсы (например, Git-репозитории, OCI контейнерные образы, репозитории артефактов) могут быть интегрированы в рабочие процессы pipeline.

При построении CI/CD pipeline пользователи традиционно должны вручную настраивать URL ресурсов, ветку/тег git, тег OCI образа, репозиторий артефактов и учетные данные аутентификации для разных внешних инструментов. Этот ручной процесс сложен, подвержен ошибкам и делает конфигурации pipeline тесно связанными с конкретными экземплярами инструментов.

ResourceInterface решает эту проблему, предоставляя стандартную абстракцию ресурсов, такую как "GitCodeRepository", "OCIArtifact" и "MavenArtifact". Вместо ручного ввода URL, например https://github.com/myorg/myapp.git, пользователи могут выбрать connector, просмотреть ресурсы через UI, и система автоматически сгенерирует правильную конфигурацию и учетные данные для pipeline.

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

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

Если вы хотите интегрировать Connector в ваш пользовательский Pipeline или Task, пожалуйста, обратитесь к Pipeline Integration.