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 реверс-прокси.

    Ссылки