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

    • ConnectorsProxy

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

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

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

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

    Содержание

    Встроенный Connectors ProxyForward ProxyReverse ProxyПользовательский Connectors ProxyАдрес Connector ProxyИспользование с Connectors CSI DriverПодробное понимание Connectors ProxyУказание Proxy в ConnectorClassАутентификация Connectors ProxyАутентификация встроенного Forward ProxyАутентификация встроенного Reverse ProxyПользовательская аутентификация на основе RegoВнедрение учетных данных аутентификации в backend request при использовании встроенного Reverse ProxyBasic AuthBearer TokenCustom RegoСсылки

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

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

    Forward Proxy

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

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

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

    Reverse Proxy

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

    1. Получает запросы клиента на proxy endpoint
    2. Выполняет аутентификацию клиента
    3. Внедряет учетные данные инструмента, указанные в Connector, и перенаправляет запросы в backend tool

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

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

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

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

    Адрес Connector Proxy

    У каждого Connector есть уникальный proxy address для доступа к ресурсам инструмента. Адрес proxy хранится в поле 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

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

    Подробнее о других полях connectorclass см. ConnectorClass

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

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

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

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

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

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

    Подробное понимание Connectors Proxy

    Указание Proxy в ConnectorClass

    Вы можете указать proxy server, который будет использоваться в 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 в качестве своего фактического proxy server.

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

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

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

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

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

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

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

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

    Подробную информацию о ServiceAccount token и конфигурации RBAC см. в документации по аутентификации Kubernetes.

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

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

    • Username: <connector-namespace>/<connector-name>
    • Password: ServiceAccount token с правами чтения для Connector

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

    # credentials format: <connector-namespace>/<connector-name>:<service-account-token>
# example: default/github:sa-token-xxxxxxx
Proxy-Authorization: Basic <base64-encoded-credentials>

    Пример переменных окружения HTTP Proxy:

    Вы можете настроить аутентификацию 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-encoded представление символа / в формате namespace/name для Connector.

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

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

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

    Пример:

    curl -u "user:sa-token-xxxxxxx" "http://c-github.default.svc.cluster.local/"
    Bearer Token Authentication
    • Authorization Header: Bearer <service-account-token>

    Пример:

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

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

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

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

    Например:

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

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

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

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

    Подробнее о внедрении учетных данных аутентификации в backend request см. Внедрение учетных данных аутентификации в backend request при использовании встроенного Reverse Proxy.

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

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

    • Service Format: например http://c-<connector-name>.<namespace>.svc.cluster.local
    • Path Format: http://<proxy-address>/namespaces/<connector-namespace>/connectors/<connector-name>

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

    Пример:

    Для Connector github в namespace default:

    # Using Bearer Token and service address format
curl -H "Authorization: Bearer sa-token-xxxxxxx" \
     "http://c-github.default.svc.cluster.local/"

# Using Basic Auth and path address format
curl -u ":sa-token-xxxxxxx" \
     "http://connector-proxy.example.com/namespaces/default/connectors/github"

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

    Внедрение учетных данных аутентификации в backend request при использовании встроенного Reverse Proxy

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

    • Basic Auth
    • Bearer Token
    • Custom Rego

    Basic Auth

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

    Bearer Token

    Когда Connector настроен с типом secret connectors.cpaas.io/bearer-token, proxy внедряет учетные данные в заголовки backend request, используя Bearer Token authentication.

    Custom 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
            }
          }

    Эта конфигурация внедряет значение токена из secret data Connector в заголовок Private-Token backend request.

    Подробнее о конфигурации см. ConnectorClass.

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

    Ссылки