#ConnectorClass

#Overview

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. Примеры

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

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

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, необходимого для аутентификации, соответствующий типу Secret Kubernetes.

Пример:

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

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

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

Как и в Kubernetes, можно использовать собственный тип 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 для проверки аутентификации. По умолчанию берется схема из адреса коннектора.
• spec.authProbes[].probe.http.response.cel указывает ожидаемый ответ для проверки аутентификации.
  • Поведение по умолчанию: успех при возврате 200.
  • Пользовательская проверка: при настройке выражения CEL аутентификация считается успешной, если выражение возвращает true.

В выражении CEL доступны следующие переменные:

Пример

Следующая 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, разрешено автоматическое перенаправление
          response:
            cel: response.statusCode == 200  # Пользовательское выражение проверки
---
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: если в Connector настроен Secret, поля 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

#API ConnectorClass

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. Подробнее см. Использование API Connectors в динамических формах.

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

Возможности конфигурации определяют конфигурационные файлы, которые 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 — это стандартный ресурс Kubernetes, который можно помечать пользовательской информацией с помощью 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

Коннектор будет использовать адрес прокси для проксирования запросов к 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
        }

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

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

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

#Тип резолвера

Адрес прокси 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 }}

#More

• Connector User Guide