#ConnectorsProxy

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

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

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

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

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

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

#Forward Proxy

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

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

#Цели внедрения учетных данных в Forward Proxy

Для встроенного режима forward proxy целями внедрения учетных данных являются:

• Connector.spec.address
• Connector.spec.addressExtensions[*].value

Когда addressExtensions не настроен, доступен только spec.address. Изменение этих addresses требует разрешения на обновление самого Connector, поэтому эта возможность не создает нового boundary владения учетными данными.

#Reverse Proxy

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

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

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

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

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

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

#Адрес Connector Proxy

У каждого Connector есть уникальный proxy address для доступа к ресурсам инструмента. Proxy address хранится в поле 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 address и информацию для аутентификации proxy
2. Connectors Proxy обрабатывает внедрение аутентификации и маршрутизацию запросов к целевому инструменту
3. Клиенты могут получать доступ к ресурсам без управления учетными данными

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

• Git clone operations в Kubernetes Jobs
• Image push/pull operations в Tekton Pipelines
• API access в custom workloads

Для полных сценариев доступа без секретов с использованием Connectors Proxy и Connectors CSI Driver см. How to use the Git Connector to complete Git clone without storing credentials on the client

#Подробное понимание 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

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

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

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

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

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

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

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

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

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

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

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

Общую модель и значение connectors/proxy см. в Connectors Permission Model.

Подробные сведения о ServiceAccount tokens и настройке RBAC см. в Kubernetes Authentication documentation.

#Аутентификация встроенного 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 с использованием стандартных environment variables HTTP proxy:

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

#Аутентификация встроенного 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 аутентификации. Client CLIs могут передавать токены Kubernetes в исходном формате учетных данных инструмента, а proxy извлекает токен через правила Rego для завершения проверки аутентификации.

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

Подробнее о внедрении учетных данных аутентификации в backend request см. Injecting Authentication Credentials into Backend Request when using built-in Reverse Proxy.

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

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

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

Proxy address connector автоматически генерируется системой и является уникальным для каждого connector. Перед использованием вы должны получить proxy address 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.

#Внедрение учетных данных аутентификации в 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.

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

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

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

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

#Ссылки

• Kubernetes Authentication documentation

#Следующие шаги

• Connectors Permission Model
• Connectors Approval & Permission Gating
• Connectors CSI Driver