#ConnectorClass

#Обзор

ConnectorClass — это ресурс на уровне кластера, который определяет режимы доступа и спецификации поведения для определённых типов инструментов.

В следующем примере определяется коннектор типа hello-git, поддерживающий базовую аутентификацию:

apiVersion: connectors.alauda.io/v1alpha1
kind: ConnectorClass
metadata:
  name: hello-git
spec:
  address:
    type: string  # Адрес в формате строки
  auth:
    types:
      - name: basicAuth
        secretType: kubernetes.io/basic-auth  # Используется Basic Auth для аутентификации

В ConnectorClass режимы доступа и спецификации поведения для подключения инструментов к платформе определяются описанием следующей информации:

• Формат адреса доступа к инструменту
• Поддерживаемые методы аутентификации
• Как проверять доступность инструмента
• Как проверять валидность аутентификации
• Как инструмент предоставляет API-возможности
• Какие возможности конфигурации предоставляет инструмент
• Метаданные для отображения в удобочитаемом виде

В этом документе также приведены примеры, помогающие лучше понять, как настраивать ConnectorClass. Примеры

#Информация об адресе

Информация об адресе определяет формат доступа к инструменту. В настоящее время поддерживаются конфигурации адреса типа string. Эта информация ограничивает тип поля, которому должен соответствовать текущий тип инструмента.

spec:
  address:
    type: string  # В настоящее время поддерживается только тип string

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

#Параметры

Параметры используются для определения дополнительных параметров при создании коннектора.

Вы можете определить обязательные параметры для создания коннектора с помощью поля spec.params в connectorclass.

• spec.params[].name — имя параметра.
• spec.params[].type — тип параметра. В настоящее время поддерживается только тип string.
• spec.params[].default — значение параметра по умолчанию (необязательно). Если задано значение по умолчанию, пользователь может опустить этот параметр при создании коннектора.
• spec.params[].description — описание параметра (необязательно).

Например, следующее определение позволяет пользователям указывать параметр sslVerify при создании коннектора типа git, со значением по умолчанию true.

kind: ConnectorClass
metadata:
  name: git
spec:
  params:
    - name: sslVerify
      type: string
      default: "true"

Для конфигурации параметров при создании Connectors смотрите документацию по Connector.

В сочетании с возможностями connectors-csi-driver это позволяет более гибко настраивать конфигурацию. Особенно полезно, когда нужно предоставить параметризуемые настройки. Например, при создании коннектора типа git пользователь может указать параметр sslVerify для управления проверкой SSL-сертификата. Подробнее см. в документации ConnectorClass Configuration.

#Информация об аутентификации

#Тип аутентификации

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

Пользователь может уникально назвать текущий тип аутентификации через

• spec.auth.types[].name, который должен быть уникальным и не повторяться.
• spec.auth.types[].secretType, который указывает тип Secret, необходимого для аутентификации, соответствующий типу Kubernetes Secret.

Пример:

spec:
  auth:
    types:
      - name: basicAuth  # Имя типа аутентификации
        secretType: kubernetes.io/basic-auth  # Соответствующий тип Secret
      - name: sshAuth
        secretType: kubernetes.io/ssh-auth

В встроенных типах K8S Secret все типы, кроме Opaque, имеют ограничения по полям. При предоставлении Secret пользователь должен убедиться, что поля Secret соответствуют ограничениям типа.

При использовании типа Opaque необходимо объявить параметры аутентификации.

Как и в k8s, можно использовать собственный тип Secret. В этом случае также нужно объявить параметры аутентификации.

#Параметры аутентификации

Параметры, необходимые для учётных данных при аутентификации, определяются в spec.auth.types[].params.

Для стандартных типов Kubernetes Secret с чётко определёнными полями данных параметры можно опустить. Например:

• kubernetes.io/basic-auth: аутентификация по имени пользователя и паролю
• kubernetes.io/ssh-auth: аутентификация по SSH-ключу

Для пользовательских типов аутентификации можно определить необходимые параметры аутентификации, при этом secretType указывается как Opaque или пользовательское имя.

Например, для аутентификации GitLab с использованием Personal Access Token (PAT):

spec:
  auth:
    types:
      - name: privateToken
        secretType: Opaque
        params:
          - name: username
            type: string
          - name: private-token
            type: string
      - name: oauth2
        secretType: example.com/oauth2
        params:
          - name: clientID
            type: string
          - name: clientSecret
            type: string

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

#Необязательная аутентификация

Некоторые инструменты поддерживают доступ без аутентификации, что отмечается полем optional, указывающим, является ли аутентификация необязательной:

Например, следующий пример указывает, что учётные данные для basicAuth необязательны, а для sshAuth обязательны.

spec:
  auth:
    types:
      - name: basicAuth
        optional: true  # Отметка, что аутентификация необязательна
        secretType: kubernetes.io/basic-auth
      - name: sshAuth
        secretType: kubernetes.io/basic-auth

В этом случае при подключении такого типа инструмента к платформе аутентификация типа basicAuth может быть опущена.

#Liveness Probe

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

Проверка доступности может выполняться с помощью HTTP-запросов или API ConnectorClass.

#Проверка с помощью HTTP-запросов

Вы можете настроить spec.livenessProbe.http для выполнения проверки доступности с помощью HTTP-запросов.

Пример

Следующий фрагмент указывает, что проверка выполняется с помощью HTTP-запросов.

spec:
  livenessProbe:
    http:
      path: /

Если инструмент возвращает статус 200, он считается доступным.

Подробнее см. Probe using HTTP Requests in Authentication Probe. Конфигурация идентична, за исключением путей полей.

#Проверка с помощью API ConnectorClass

Вы можете настроить spec.livenessProbe.api для выполнения проверки доступности с помощью API ConnectorClass.

Пример

Следующий фрагмент указывает, что проверка выполняется с помощью API ConnectorClass.

spec:
  livenessProbe:
    api:
      path: /

Подробнее см. Probe using ConnectorClass API in Authentication Probe. Конфигурация идентична, за исключением путей полей.

#Authentication Probe

Проверка аутентификации используется для проверки валидности учётных данных аутентификации для инструментов данного типа. Если проверка аутентификации не требуется, поле authProbes можно опустить.

• spec.authProbes[].authName указывает тип аутентификации, который проверяется, и должен совпадать с одним из имён, определённых в spec.auth.types[].name.

Проверка аутентификации может выполняться с помощью HTTP-запросов или API ConnectorClass.

#Проверка с помощью HTTP-запросов

Вы можете настроить spec.authProbes[].probe.http для выполнения проверки аутентификации с помощью HTTP-запросов.

• spec.authProbes[].probe.http.host указывает целевой хост для проверки аутентификации. По умолчанию берётся хост из адреса коннектора.
• spec.authProbes[].probe.http.path указывает путь запроса для проверки аутентификации. Это абсолютный путь, который будет добавлен к URI хоста, разрешённому из spec.address коннектора при выполнении проверки. Если spec.address содержит префикс пути, он игнорируется при проверке аутентификации. Чтобы включить префикс пути, используйте Authentication Check Expressions для динамического получения.
• spec.authProbes[].probe.http.method указывает HTTP-метод для проверки аутентификации, поддерживаются GET и POST. По умолчанию GET.
• spec.authProbes[].probe.http.disableRedirect указывает, отключать ли HTTP-перенаправления при проверке аутентификации. По умолчанию false (автоматическое перенаправление разрешено).
• spec.authProbes[].probe.http.httpHeaders указывает HTTP-заголовки, которые будут включены в запросы проверки аутентификации.
• spec.authProbes[].probe.http.scheme указывает схему URI для проверки аутентификации. По умолчанию берётся схема из адреса коннектора.

Пример

Следующая YAML-конфигурация демонстрирует, что при проверке аутентификации система отправит запрос GET https://example.com/ HTTP/1.1 к адресу коннектора с заголовком Authorization: abc.

kind: ConnectorClass
metadata:
  name: example-class
spec:
  authProbes:
    - authName: basicAuth  # Соответствующий тип аутентификации
      probe:
        http:
          httpHeaders:
            Authorization: abc
          path: /
          method: GET # По умолчанию GET, поддерживаются методы POST и GET
          disableRedirect: false # По умолчанию false, разрешено автоматическое перенаправление
---
kind: Connector
metadata:
  name: example
spec:
  connectorClassName: example-class
  address: https://example.com

#Проверка с помощью API ConnectorClass

Вы можете настроить spec.authProbes[].probe.api для выполнения проверки аутентификации с помощью API ConnectorClass. Для этого сначала необходимо настроить spec.api в спецификации ConnectorClass. Ответ 200 означает успешную аутентификацию, а 401 или 403 — ошибку аутентификации. Подробнее о ConnectorClass API.

• spec.authProbes[].probe.api.path указывает путь конечной точки API для проверки аутентификации. Это относительный путь, который будет добавлен к адресу API, разрешённому из конфигурации spec.api ConnectorClass. Если spec.api содержит префикс пути, он будет включён при выполнении проверки аутентификации.

Пример

Следующая YAML-конфигурация демонстрирует, что при проверке аутентификации система отправит запрос GET https://example-api.default.svc.cluster.local/api/auth/check HTTP/1.1 к API ConnectorClass.

kind: ConnectorClass
metadata:
  name: example-class
spec:
  api:
    ref:
      kind: Service
      name: example-api
      namespace: default
    uri: /api
  authProbes:
    - authName: basicAuth
      probe:
        api:
          path: /auth/check # Относительный путь адреса API, разрешённого из `spec.api` connectorclass
---
kind: Connector
metadata:
  name: example
spec:
  connectorClassName: example-class
  address: https://example.com

#Пользовательские параметры проверки аутентификации

Некоторые сценарии проверки аутентификации могут требовать дополнительных параметров, например, указания имени репозитория при проверке доступа к Git-репозиторию. Эти параметры можно определить с помощью spec.authProbes[].params.

kind: ConnectorClass
metadata:
  name: example-class
spec:
  authProbes:
    - authName: basicAuth  # Соответствующий тип аутентификации
      params:
        - name: repository
          type: string

#Выражения проверки аутентификации

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

Например:

spec:
  authProbes:
    - authName: basicAuth  # Соответствующий тип аутентификации
      probe:
        http:
          httpHeaders:
            Authorization: {{ .Secret.StringData.token }}
          path: /
      params:
        - name: repository
          type: string

• Выражения можно использовать в полях probe.http.httpHeaders, probe.http.path и probe.api.path.
• Формат выражений соответствует синтаксису Go template.
• Поддерживаемые верхнеуровневые поля включают:
  • .Connector: содержит информацию о самом ресурсе Connector
  • .Secret: содержит данные Secret, используемого для аутентификации Connector
• Доступные методы в выражениях документированы в библиотеке sprig:
  • Например: b64enc для Base64-кодирования строк, trimPrefix для удаления префиксов строк

Пример

Проверка базовой аутентификации:

spec:
  authProbes:
    - authName: basicAuth
      params:
        - name: repository
          type: string
      probe:
        http:
          path: /{{- range .Connector.Spec.Auth.Params }}{{- if eq .Name "repository" }}{{ .Value.StringVal }}{{ end }}{{- end }}/info/refs?service=git-upload-pack
          httpHeaders:
          - name: Authorization
            value: >-
              {{- if .Secret }}Basic {{ printf "%s:%s" .Secret.StringData.username .Secret.StringData.password | b64enc }} {{- end }}

Коннектор выполнит проверку аутентификации на основе конфигурации, определённой в ConnectorClass.

В приведённом YAML показана проверка базовой аутентификации:

• path: использует значение repository из auth.params Connector, формируя путь как /<repository>/info/refs?service=git-upload-pack
• Authorization: при наличии Secret в Connector поля username и password кодируются в Base64 и включаются в заголовок Basic аутентификации.

#Конфигурация логики аутентификации на основе Rego

Когда коннекторам инструментов требуется более сложная логика аутентификации, можно использовать конфигурацию логики аутентификации на основе Rego.

Rego — декларативный язык политик, позволяющий определять логику аутентификации. В ConnectorClass политики Rego указываются в поле auth.types[].generator.rego:

apiVersion: connectors.alauda.io/v1alpha1
kind: ConnectorClass
metadata:
  name: example
spec:
  address:
    name: address
    type: string
  auth:
    types:
    - name: rego-auth
      secretType: Opaque
      generator:
        rego: |
          package proxy
          auth = {
            "position": "header",
            "auth": {
              "Authorization": concat(" ", ["Bearer", input.data.token])
            }
          }

Политика Rego должна соответствовать следующим правилам:

• Определять правила в пакете proxy
• Возвращать объект auth со следующей структурой:
  • position: место вставки аутентификации, например "header", "query" или "body"
  • contentType: тип содержимого для вставки в тело (необязательно, используется с позицией "body")
  • auth: карта ключ-значение аутентификации

#Доступные переменные в Rego

#Примеры политик Rego

#Базовая аутентификация

spec:
  auth:
    types:
    - name: basic-rego-auth
      secretType: Opaque
      generator:
        rego: |
          package proxy
          auth = {
            "position": "header",
            "auth": {
              "Authorization": concat(" ", ["Basic", base64.encode(concat(":", [input.data.username, input.data.password]))])
            }
          }

#Аутентификация с API ключом

spec:
  auth:
    types:
    - name: apikey-rego-auth
      secretType: Opaque
      generator:
        rego: |
          package proxy
          auth = {
            "position": "query",
            "auth": {
              "api_key": input.data.apikey
            }
          }

#Аутентификация с JSON телом

spec:
  auth:
    types:
    - name: body-rego-auth
      secretType: Opaque
      generator:
        rego: |
          package proxy
          auth = {
            "position": "body",
            "contentType": "application/json",
            "auth": {
              "username": input.data.username,
              "password": input.data.password,
              "client_id": input.data.client_id
            }
          }

#Расширенные техники Rego

Можно использовать условную логику Rego для разных методов аутентификации:

#Условная аутентификация

spec:
  auth:
    types:
    - name: conditional-auth
      secretType: Opaque
      generator:
        rego: |
          package proxy

          # По умолчанию используется API ключ
          auth = {
            "position": "header",
            "auth": {
              "X-API-Key": input.data.apikey
            }
          }

          # Использовать OAuth токен, если он есть
          auth = {
            "position": "header",
            "auth": {
              "Authorization": concat(" ", ["Bearer", input.data.oauth_token])
            }
          } {
            input.data.oauth_token != ""
          }

#Аутентификация на основе времени

spec:
  auth:
    types:
    - name: time-based-auth
      secretType: Opaque
      generator:
        rego: |
          package proxy

          import time

          # Получить текущее время
          current_time := time.now_ns() / 1000000000

          auth = {
            "position": "header",
            "auth": {
              "X-Timestamp": sprintf("%d", [current_time]),
              "X-Signature": hmac.sha256(input.data.api_secret, sprintf("%d", [current_time]))
            }
          }

Для подробностей по языку Rego смотрите:

• Rego Policy Language

#ConnectorClass API

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

Если нет необходимости предоставлять кастомные API-возможности для инструмента, spec.api можно не задавать.

#Конфигурация адреса API

API ConnectorClass настраивается в поле spec.api. Вы можете указать сервис API тремя способами:

1. Через ссылку на Kubernetes Service:

spec:
  api:
    ref:
      kind: Service
      name: git
      namespace: default

2. Через ссылку на Service с префиксом URI:

Если у API есть фиксированный префикс пути, его можно указать через spec.api.uri:

spec:
  api:
    ref:
      kind: Service
      name: git
      namespace: default
    uri: /api

3. Через абсолютный URI:

Также можно использовать spec.api.uri для указания абсолютного пути API:

spec:
  api:
    uri: https://git.example.com/api

#Разрешение адреса API

Независимо от способа конфигурации, окончательный разрешённый адрес API будет храниться в status.api.address.url. Например:

spec:
  api:
    ref:
      kind: Service
      name: git
      namespace: default
    uri: /prefix
status:
  api:
    address:
      url: https://git.default.svc/prefix

Для дополнительной информации смотрите:

• Connector API
• Спецификация определения API ConnectorClass

#Описание OpenAPI

Описание OpenAPI — это необязательная конфигурация, которая служит двум основным целям:

• Отметить, является ли API кастомным или использует Connector Proxy для доступа к оригинальному API инструмента
• Предоставить определения API для поддержки ссылок на API в динамических формах клиента

Вы можете определить описание OpenAPI с помощью spec.api.openapi. Структура соответствует спецификации OpenAPI 3.0. Например:

spec:
  api:
    openapi:
      openapi: "3.0.1"
      info:
        title: Git API
        version: "1.0.0"

Вы можете определить расширенное поле x-provider-type в путях API, чтобы отметить, является ли API кастомным или использует Proxy для доступа к оригинальному API инструмента. Допустимые значения: api или proxy.

Расширение x-provider-type определяется как: api.openapi.paths[<path>].<verb>[x-provider-type]

Пример:

spec:
  api:
    openapi:
      openapi: "3.0.1"
      info:
        title: Gitlab API
        version: "1.0.0"
      paths:
        /git/api:
          get:
            summary: Get Git API
            x-provider-type: api  # Используется кастомный API
        /api/v4/projects:
          get:
            summary: Get Gitlab Projects API
            x-provider-type: proxy  # Используется Proxy для доступа к оригинальному API инструмента

Если необходимо ссылаться на API в динамических формах, требуется дополнительная настройка в spec.api.openapi. Подробнее см. Использование Connectors API в динамических формах.

#Возможности конфигурации

Возможности конфигурации определяют конфигурационные файлы, которые ConnectorClass предоставляет клиентам. Эти файлы могут быть смонтированы в Pods с помощью Connectors-CSI Driver.

#Типы конфигураций

• Пользовательские конфигурации: определяются в spec.configurations
• Встроенные конфигурации: автоматически предоставляются Connectors-CSI Driver (см. Встроенные конфигурации)

#Пользовательские конфигурации

Конфигурации задаются через spec.configurations:

kind: ConnectorClass
metadata:
  name: git
spec:
  configurations:
  - name: gitconfig
    data:
      .gitconfig: |
        [http]
            extraHeader = Authorization: Basic {{ .context.token | b64enc }}
        [url "{{ .connector.status.proxyAddress }}"]
            insteadOf = {{ .connector.spec.address }}

Подробнее см.: Рендеринг конфигурационных файлов

Примечание: spec.configurations является необязательным. Если не задано, доступны только встроенные конфигурации.

#Метаданные для удобочитаемого отображения

ConnectorClass — это стандартный ресурс k8s, который можно помечать пользовательской информацией с помощью labels и annotations.

Например:

Например:

apiVersion: connectors.alauda.io/v1alpha1
kind: ConnectorClass
metadata:
  name: git
  labels:
    connectors.cpaas.io/git: "true"
  annotations:
    ui.cpaas.io/icon: "data:image/svg+xml;base64,PD94bWwgdmVyc2..."
    cpaas.io/display-name: Git
    cpaas.io/description: "Connect to any Git tool"
    connectors.cpaas.io/readme: "this is readme..."
    connectors.cpaas.io/docs-link: "/alauda-devops-connectors/concepts/connectorclass/git"

#Proxy ConnectorClass

Proxy ConnectorClass используется для настройки адреса прокси для ConnectorClass.

Proxy ConnectorClass настраивается через spec.proxy. Например:

spec:
  proxy:
    ref:
      kind: Service
      name: proxy
      namespace: default
    # uri: https://proxy.example.com

Connector будет использовать адрес прокси для проксирования запросов к ConnectorClass. Подробнее

#Использование Rego для извлечения токена из запроса

При использовании встроенного обратного прокси можно настроить правила Rego с помощью spec.proxy.authExtractor для извлечения токенов из запросов клиентов, что позволяет встроенному обратному прокси проверять аутентификацию клиента с помощью извлечённого токена.

Например:

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

Правила Rego должны соответствовать следующим требованиям:

• Правила должны быть определены в пакете proxy
• Используйте переменную auth для возврата токена, где токен — строка, например: auth = { "token": "abcd1234" }
• Если токен не может быть извлечён, возвращайте пустую строку, например: auth = { "token": "" }

В Rego доступны следующие переменные:

Примечания:

• Ключи заголовков в headers используют формат Canonical MIME Header Key (первая буква заглавная)
• При реализации правил Rego обеспечьте устойчивую логику. Например, возвращайте пустую строку, если input.request.headers равен null или пуст.

Пример

spec:
  proxy:
    authExtractor:
      rego: |
        package proxy

        default auth = {
          "token": ""
        }

        auth = {
          "token": input.request.headers["Private-Token"][0]
        } if {
          input.request.headers != null
          input.request.headers["Private-Token"] != null
          count(input.request.headers["Private-Token"]) > 0
        }

Этот пример демонстрирует устойчивое извлечение токена за счёт:

• Определения правила по умолчанию, возвращающего пустую строку токена
• Проверки существования и ненулевого значения заголовков перед доступом к ним
• Проверки наличия ключа заголовка и наличия хотя бы одного значения

Для более продвинутых правил Rego смотрите документацию Rego Policy Language. Для дополнительной информации по использованию встроенного обратного прокси смотрите Connectors Proxy.

#Тип Resolver

Адрес прокси ConnectorClass будет разрешаться в соответствии с указанным типом resolver.

Тип resolver настраивается через аннотации connectors.cpaas.io/proxy-resolver. Например:

apiVersion: connectors.alauda.io/v1alpha1
kind: ConnectorClass
metadata:
  name: oci
  annotations:
    connectors.cpaas.io/proxy-resolver: "path"

Это соглашение между ConnectorClass-Proxy и Connector. Необязательно.

Поддерживаемые значения: host, path. По умолчанию host.

• Формат host: http://{.ConnectorClass.Status.ProxyAddress.URL}
• Формат path: http://{.ConnectorClass.Status.ProxyAddress.URL}/namespaces/{namespace}/connectors/{connector-name}

#Информация о статусе

После определения ресурса ConnectorClass информация о статусе будет храниться в status.

Типы status.conditions включают:

• APIReady: статус API-возможностей
• ProxyReady: статус Proxy-возможностей
• Ready: общий статус текущего ConnectorClass

Условие Ready

Условие Ready используется для обозначения статуса текущего ConnectorClass. Оно агрегирует статусы других условий.

• Если все другие условия True, текущее условие True.
• Если любое другое условие False, текущее условие False.
• Если любое другое условие Unknown, текущее условие Unknown.

Условие APIReady

Отражает статус API-сервиса, настроенного для ConnectorClass. API-сервис настраивается через spec.api ConnectorClass.

Примечание:

• Проверка API выполняет только попытку запроса и не оценивает HTTP-статусы. Проверка здоровья API-сервиса должна опираться на собственный механизм проверки здоровья API.
• Поскольку API-сервис может изменяться в любой момент, статус не отражает информацию в реальном времени. Рекомендуется использовать статус как подсказку, а не для блокировки поведения клиента.

Условие ProxyReady

Отражает статус Proxy-сервиса, настроенного для ConnectorClass. Proxy-сервис настраивается через spec.proxy ConnectorClass.

#Совместимость

Обновления ConnectorClass могут повлиять на существующие Connectors. Если в ConnectorClass внесены несовместимые изменения, это может привести к неработоспособности ранее созданных Connectors. Возможные изменения, приводящие к несовместимости:

1. Изменения в информации об аутентификации: если ConnectorClass изменяет поддерживаемые типы или методы аутентификации, это может привести к сбоям Connectors, использующих старый метод аутентификации.

2. Изменения в конфигурационной информации: если изменяется конфигурация ConnectorClass, например, удаляется существующая конфигурация, это может привести к сбоям Kubernetes workloads, зависящих от старой конфигурации.

Рекомендуется тщательно оценивать зону влияния при обновлении ConnectorClass или при необходимости создавать новый ConnectorClass.

#Дополнительные примеры

• ConnectorClass, поддерживающий тип аутентификации basic-auth

  apiVersion: connectors.alauda.io/v1alpha1
  kind: ConnectorClass
  metadata:
    name: git
  spec:
    address:
      type: string
    auth:
      types:
        - name: basicAuth
          secretType: kubernetes.io/basic-auth
          optional: true

• ConnectorClass с пользовательским типом аутентификации

  apiVersion: connectors.alauda.io/v1alpha1
  kind: ConnectorClass
  metadata:
    name: sample
  spec:
    address:
      type: string
    auth:
      types:
        - name: patAuth
          optional: true
          secretType: Opaque
          params:
          - name: username
          - name: privateToken

• ConnectorClass с настроенной liveness probe

  apiVersion: connectors.alauda.io/v1alpha1
  kind: ConnectorClass
  metadata:
    name: git
  spec:
    address:
      type: string
    auth:
      types:
        - name: basicAuth
          optional: true
          secretType: kubernetes.io/basic-auth
    livenessProbe:
      http:
        path: /

• ConnectorClass с настроенной auth probe

  apiVersion: connectors.alauda.io/v1alpha1
  kind: ConnectorClass
  metadata:
    name: git
    labels:
      connectors.cpaas.io/git: "true"
  spec:
    address:
      type: string
    auth:
      types:
        - name: basicAuth
          secretType: kubernetes.io/basic-auth
          optional: true
    livenessProbe:
      http:
        path: /
    authProbes:
      - authName: basicAuth
        params:
          - name: repository
            type: string
        probe:
          http:
            path: /{{- range .Connector.Spec.Auth.Params }}{{- if eq .Name "repository" }}{{ .Value.StringVal }}{{ end }}{{- end }}/info/refs?service=git-upload-pack
            httpHeaders:
            - name: Authorization
              value: >-
                {{- if .Secret }}Basic {{ printf "%s:%s" .Secret.StringData.username .Secret.StringData.password | b64enc }} {{- end }}

• Полный пример конфигурации git-коннектора:

  apiVersion: connectors.alauda.io/v1alpha1
  kind: ConnectorClass
  metadata:
    name: git
  spec:
    address:
      name: address
      type: string
    auth:
      types:
        - name: basicAuth
          secretType: kubernetes.io/basic-auth
          optional: true
    livenessProbe:
      http:
        path: /
    authProbes:
      - authName: basicAuth
        params:
          - name: repository
            type: string
        probe:
          http:
            path: /{{- range .Connector.Spec.Auth.Params }}{{- if eq .Name "repository" }}{{ .Value.StringVal }}{{ end }}{{- end }}/info/refs?service=git-upload-pack
            httpHeaders:
            - name: Authorization
              value: >-
                {{- if .Secret }}Basic {{ printf "%s:%s" .Secret.StringData.username .Secret.StringData.password | b64enc }} {{- end }}

#Дополнительно

• Руководство пользователя Connector