#ConnectorClass

#Обзор

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

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

apiVersion: connectors.alauda.io/v1alpha1
kind: ConnectorClass
metadata:
  name: hello-git
spec:
  address:
    type: string  # Address in string format
  auth:
    types:
      - name: basicAuth
        secretType: kubernetes.io/basic-auth  # Using Basic Auth for authentication

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

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

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

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

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

spec:
  address:
    type: string  # Currently supports only string type

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

#Параметры

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

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

• 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"

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

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

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

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

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

Пользователи могут задавать уникальное имя текущего типа аутентификации через:

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

Пример:

spec:
  auth:
    types:
      - name: basicAuth  # Name of the authentication type
        secretType: kubernetes.io/basic-auth  # Corresponding Secret type
      - name: sshAuth
        secretType: kubernetes.io/ssh-auth

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

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

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

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

Параметры, необходимые для учетных данных при аутентификации, определяются через 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  # Marking authentication as optional
        secretType: kubernetes.io/basic-auth
      - name: sshAuth
        secretType: kubernetes.io/basic-auth

На этом этапе при подключении этого типа инструмента к платформе аутентификацию типа basicAuth можно не указывать.

#Проверка доступности

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

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

#Проверка с использованием HTTP-запросов

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

Пример

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

spec:
  livenessProbe:
    http:
      path: /

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

Дополнительные сведения см. в разделе Проверка с использованием HTTP-запросов в Authentication Probe. Конфигурация идентична, за исключением путей к полям.

#Проверка с использованием ConnectorClass API

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

Пример

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

spec:
  livenessProbe:
    api:
      path: /

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

#Проверка аутентификации

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

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

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

#Проверка с использованием HTTP-запросов

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

• spec.authProbes[].probe.http.host указывает целевой host для проверки аутентификации. По умолчанию используется host из адреса коннектора.
• spec.authProbes[].probe.http.path указывает путь запроса для проверки аутентификации. Это абсолютный путь, который будет добавлен к URI host, полученному из 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 scheme для проверки аутентификации. По умолчанию используется scheme из адреса коннектора.

Пример

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

kind: ConnectorClass
metadata:
  name: example-class
spec:
  authProbes:
    - authName: basicAuth  # Corresponding authentication type
      probe:
        http:
          httpHeaders:
            Authorization: abc
          path: /
          method: GET # Defaults to GET, supports both POST and GET methods
          disableRedirect: false # Defaults to false, allowing automatic redirection
---
kind: Connector
metadata:
  name: example
spec:
  connectorClassName: example-class
  address: https://example.com

#Проверка с использованием ConnectorClass API

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

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

Пример

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

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 # It is a relative path of the API address resolved from `spec.api` of 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  # Corresponding authentication type
      params:
        - name: repository
          type: string

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

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

Например:

spec:
  authProbes:
    - authName: basicAuth  # Corresponding authentication type
      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 для удаления префиксов строк

Пример

Проверка аутентификации Basic Authentication:

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 демонстрирует проверку Basic Authentication:

• 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 (необязательно, используется вместе с позицией "body")
  • auth: map пар ключ-значение для аутентификации

#Переменные, доступные в Rego

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

#Basic Authentication

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 Key

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

#Аутентификация через JSON Body

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

          # Default uses API key
          auth = {
            "position": "header",
            "auth": {
              "X-API-Key": input.data.apikey
            }
          }

          # Use OAuth token if available
          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

          # Get current 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

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

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

#Настройка адреса API

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

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
• Спецификация определения ConnectorClass API

#Описание OpenAPI

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

• Отмечает, является ли API пользовательским 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"

В путях API можно определить расширение x-provider-type, чтобы отметить, является ли 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  # Use custom API
        /api/v4/projects:
          get:
            summary: Get Gitlab Projects API
            x-provider-type: proxy  # Use Proxy to access the tool's original 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"

#ConnectorClass Proxy

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

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

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

Connector будет использовать адрес proxy для проксирования запроса к ConnectorClass. Дополнительная информация

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

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

Например:

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. Дополнительные сведения об использовании встроенного reverse proxy см. в Connectors Proxy.

#Тип resolver

Адрес 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 Condition используется для обозначения статуса текущего ConnectorClass. Оно агрегирует статусы других условий.

• Когда другие Conditions имеют значение True, текущее Condition имеет значение True.
• Когда любое другое Condition имеет значение False, текущее Condition имеет значение False.
• Когда любое другое Condition имеет значение Unknown, текущее Condition имеет значение Unknown.

Состояние APIReady

Указывает информацию о состоянии API service, настроенного для ConnectorClass. API service настраивается через spec.api ConnectorClass.

Примечание:

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

Состояние ProxyReady

Указывает информацию о состоянии Proxy service, настроенного для ConnectorClass. Proxy service настраивается через spec.proxy ConnectorClass.

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

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

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

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

Рекомендуется уточнять масштаб влияния при обновлении 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