Alauda DevOps Connectors Docs
  • Русский

    • ConnectorsProxy

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

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

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

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

    Содержание

    Встроенный Connectors ProxyФорвард-проксиРеверс-проксиПользовательский Connectors ProxyАдрес Connector ProxyИспользование с Connectors CSI DriverГлубокое понимание Connectors ProxyУказание прокси в ConnectorClassАутентификация Connectors ProxyАутентификация встроенного форвард-проксиАутентификация встроенного реверс-проксиПользовательская аутентификация на основе RegoВнедрение учетных данных аутентификации в бэкенд-запрос при использовании встроенного реверс-проксиBasic AuthBearer TokenПользовательский RegoСсылки

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

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

    Форвард-прокси

    Работает как стандартный HTTP-прокси с использованием переменных окружения http_proxy и https_proxy. Когда прокси получает клиентские запросы, он:

    1. Аутентифицирует клиента
    2. Внедряет учетные данные инструмента, указанные в Connector, в запрос, если текущий путь запроса указывает на целевой инструмент, заданный Connector
    3. Перенаправляет аутентифицированный запрос к целевому инструменту
    DANGER

    Connectors Proxy не поддерживает метод CONNECT для HTTP туннелирования. Клиенты должны отправлять HTTP-запросы напрямую на сервер прокси.

    Реверс-прокси

    Клиенты получают доступ к инструментам, подключаясь напрямую к адресу Connector Proxy вместо исходного URL инструмента. Прокси:

    1. Принимает клиентские запросы на конечной точке прокси
    2. Выполняет аутентификацию клиента
    3. Внедряет учетные данные инструмента, указанные в Connector, и перенаправляет запросы на бэкенд-инструмент

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

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

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

    Пользователь может разработать собственный сервер прокси и указать его в connectorclass.

    Адрес Connector Proxy

    Каждый Connector имеет уникальный адрес прокси для доступа к ресурсам инструмента. Адрес прокси хранится в поле status.proxy.httpAddress:

    apiVersion: connectors.alauda.io/v1alpha1
kind: Connector
metadata:
  name: github
spec:
  address: https://github.com/kubernetes/kubernetes.git
  auth:
    name: basicAuth
    params:
    - name: repository
      value: kubernetes/kubernetes.git
  connectorClassName: git
status:
  # . . .
  proxy:
    httpAddress:
      url: http://c-github.default.svc.cluster.local

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

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

    Использование с Connectors CSI Driver

    Connectors Proxy работает без сбоев с Connectors CSI Driver, обеспечивая полное решение для доступа без секретов:

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

    Эта интеграция особенно полезна в сценариях, таких как:

    • Операции клонирования Git в Kubernetes Jobs
    • Операции push/pull образов в Tekton Pipelines
    • Доступ к API в пользовательских нагрузках

    Для полного сценария доступа без секретов с использованием Connectors Proxy и Connectors CSI Driver смотрите Как использовать Git Connector для полного клонирования Git без хранения учетных данных на клиенте

    Глубокое понимание Connectors Proxy

    Указание прокси в ConnectorClass

    Вы можете указать сервер прокси для использования в ConnectorClass:

    apiVersion: connectors.alauda.io/v1alpha1
kind: ConnectorClass
metadata:
  name: example
spec:
  proxy:
    ref:
      kind: Service
      name: connectors-proxy-service
      namespace: connectors-system

    Connectors, созданные из этого ConnectorClass, будут использовать connectors-proxy-service в качестве реального сервера прокси.

    Конфигурация встроенного прокси:

    ref:
  kind: Service
  name: connectors-proxy-service
  namespace: <connector-namespace> # Пространство имен, где развернуты компоненты Connector

    Конфигурация пользовательского прокси:

    Пользовательские прокси могут указывать на любой адрес, способный обрабатывать прокси-запросы.

    Аутентификация Connectors Proxy

    При использовании Connectors Proxy клиенты должны предоставлять корректные учетные данные для доступа к прокси. Процесс аутентификации требует двух ключевых элементов:

    1. Идентификация Connector: указание, какой connector использовать для внедрения учетных данных
    2. Токен авторизации: предоставление токена ServiceAccount с правами чтения для целевого Connector

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

    Для подробной информации о токенах ServiceAccount и настройке RBAC смотрите документацию Kubernetes по аутентификации.

    Аутентификация встроенного форвард-прокси

    В режиме форвард-прокси информация об аутентификации передается через заголовок Proxy-Authorization с использованием HTTP Proxy Basic Authentication.

    • Имя пользователя: <connector-namespace>/<connector-name>
    • Пароль: токен ServiceAccount с правами чтения для Connector

    Заголовок Proxy-Authorization:

    # формат учетных данных: <connector-namespace>/<connector-name>:<service-account-token>
# пример: default/github:sa-token-xxxxxxx
Proxy-Authorization: Basic <base64-encoded-credentials>

    Пример настройки HTTP Proxy в окружении:

    Вы можете настроить аутентификацию прокси с помощью стандартных переменных окружения HTTP proxy:

    export http_proxy=http://<connector-namespace>%2F<connector-name>:<service-account-token>@<connector-proxy-address>
export https_proxy=http://<connector-namespace>%2F<connector-name>:<service-account-token>@<connector-proxy-address>

    Примечание: %2F — это URL-кодированная форма символа / в формате namespace/name коннектора.

    Аутентификация встроенного реверс-прокси

    В режиме реверс-прокси клиенты подключаются напрямую к адресу прокси коннектора. Токен аутентификации может быть предоставлен с помощью Basic Auth или Bearer Token, а идентификация коннектора осуществляется через адрес прокси коннектора.

    Basic Authentication
    • Имя пользователя: любое значение (игнорируется)
    • Пароль: токен ServiceAccount с правами чтения для Connector

    Пример:

    curl -u "user:sa-token-xxxxxxx" "http://c-github.default.svc.cluster.local/"
    Bearer Token Authentication
    • Заголовок Authorization: Bearer <service-account-token>

    Пример:

    curl -H "Authorization: Bearer sa-token-xxxxxxx" "http://c-github.default.svc.cluster.local/"

    Пользовательская аутентификация на основе Rego

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

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

    Например:

    spec:
  proxy:
    authExtractor:
      rego: |
        package proxy
        auth = {
          "token": input.request.headers["Private-Token"][0]
        }

    Эта конфигурация извлекает токен из заголовка Private-Token в клиентских запросах, который затем прокси использует для проверки аутентификации клиента.

    Такой подход обеспечивает значительную гибкость для нестандартных механизмов HTTP-аутентификации. CLI клиентов могут предоставлять Kubernetes токены, используя оригинальный формат учетных данных инструмента, а прокси извлекает токен через правила Rego для завершения проверки аутентификации.

    Для более подробной настройки использования правил Rego для извлечения токенов смотрите ConnectorClass.

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

    Идентификация Connector

    Connector может быть идентифицирован через различные форматы адреса прокси:

    • Формат Service: например, http://c-<connector-name>.<namespace>.svc.cluster.local
    • Формат пути: http://<proxy-address>/namespaces/<connector-namespace>/connectors/<connector-name>

    Адрес прокси коннектора автоматически генерируется системой и уникален для каждого коннектора. Вы должны получить адрес прокси коннектора из поля status.proxy.httpAddress ресурса коннектора перед его использованием.

    Пример:

    Для коннектора github в пространстве имен default:

    # Использование Bearer Token и формата адреса сервиса
curl -H "Authorization: Bearer sa-token-xxxxxxx" \
     "http://c-github.default.svc.cluster.local/"

# Использование Basic Auth и формата адреса с путем
curl -u ":sa-token-xxxxxxx" \
     "http://connector-proxy.example.com/namespaces/default/connectors/github"

    Прокси проверит токен аутентификации и автоматически внедрит учетные данные аутентификации коннектора default/github при пересылке запросов к сервисам GitHub.

    Внедрение учетных данных аутентификации в бэкенд-запрос при использовании встроенного реверс-прокси

    После того, как встроенный реверс-прокси проверит клиентский запрос, он внедряет учетные данные аутентификации в бэкенд-запрос в зависимости от типа учетных данных, настроенного в Connector. Поддерживаются следующие методы внедрения:

    • Basic Auth
    • Bearer Token
    • Пользовательский Rego

    Basic Auth

    Если Connector настроен с типом секрета kubernetes.io/basic-auth, прокси внедряет учетные данные в заголовки бэкенд-запроса с использованием Basic Authentication.

    Bearer Token

    Если Connector настроен с типом секрета connectors.cpaas.io/bearer-token, прокси внедряет учетные данные в заголовки бэкенд-запроса с использованием Bearer Token аутентификации.

    Пользовательский Rego

    Помимо стандартных методов Basic Auth и Bearer Token, вы можете использовать правила Rego для определения пользовательской логики внедрения аутентификации. Например:

    spec:
  auth:
    types:
    - name: rego-auth
      secretType: Opaque
      generator:
        rego: |
          package proxy
          auth = {
            "position": "header",
            "auth": {
              "Private-Token": input.data.token
            }
          }

    Эта конфигурация внедряет значение токена из данных секрета коннектора в заголовок Private-Token бэкенд-запросов.

    Для более подробной настройки смотрите ConnectorClass.

    При использовании пользовательской аутентификации на основе Rego обычно необходимо настроить spec.proxy.authExtractor для извлечения токенов из клиентских запросов, что позволяет встроенному HTTP реверс-прокси проверять аутентификацию клиента. Одновременно используйте spec.auth.types[].generator.rego для внедрения учетных данных аутентификации в бэкенд-запросы. Это сочетание обеспечивает поддержку пользовательских механизмов аутентификации при использовании встроенного HTTP реверс-прокси.

    Ссылки