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

    • OCI Connector

    OCI Connector — это платформонезависимый коннектор, который позволяет подключаться к любому OCI Registry, например CNCF Distribution Registry, Harbor и др. Вы можете использовать OCI Connector для безопасного доступа к приватным OCI-репозиториям в CI/CD пайплайнах или выполнять операции с OCI в контейнеризованных нагрузках без предоставления учетных данных. Кроме того, вы можете централизованно управлять конфигурациями доступа к OCI, избегая дублирования настроек учетных данных OCI в каждом namespace.

    В этом документе описывается:

    • Требования к доступу для OCI Registry
    • Как создать OCI Connector на основе типа OCI Connector
    • Возможности прокси и конфигурации OCI Connector

    Содержание

    Требования к OCI RegistryСоздание OCI Connector на основе типа OCI Connectorspec.connectorClassNamedescriptionАдресАутентификацияИспользование аутентификации на основе токенаТребуемые права токенаПрокси и конфигурацияПроксиАдрес проксиForward ProxyReverse ProxyДополнительно

    Требования к OCI Registry

    OCI Registry, к которому осуществляется доступ, должен соответствовать следующим условиям:

    1. Требования к реализации интерфейсов:

    2. Требования к методу аутентификации:

    Создание OCI Connector на основе типа OCI Connector

    Пример создания базового OCI Connector:

    apiVersion: connectors.alauda.io/v1alpha1
kind: Connector
metadata:
  name: oci-registry-demo
spec:
  connectorClassName: oci
  address: https://registry.example.com
  auth:
    name: tokenAuth

    spec.connectorClassName

    Используйте константное значение oci.

    description

    Вы можете добавить описательную информацию к OCI Connector через поле annotations.

    • cpaas.io/description: описание OCI Connector.

    Например:

    apiVersion: connectors.alauda.io/v1alpha1
kind: Connector
metadata:
  name: oci-registry-demo
  annotations:
    cpaas.io/description: "Подключение к CNCF Distribution Registry для доступа к публичному репозиторию команды"

    Адрес

    spec.address указывает адрес доступа к OCI Registry, например: https://registry.example.com.

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

    OCI Connector поддерживает следующие типы аутентификации:

    • tokenAuth: аутентификация на основе токена (опционально)
      • Соответствующий тип учетных данных: cpaas.io/distribution-registry-token, этот тип учетных данных используется для процесса аутентификации, определённого в CNCF Distribution Token Authentication Specification, и учетные данные должны содержать информацию username и password.

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

    Пример:

    apiVersion: connectors.alauda.io/v1alpha1
kind: Connector
metadata:
  name: oci-registry-demo
spec:
  connectorClassName: oci
  address: https://registry.example.com
  # . . .
  auth:
    name: tokenAuth
    secretRef:
      name: oci-secret
---
apiVersion: v1
stringData:
  password: your-password
  username: your-username
kind: Secret
metadata:
  name: oci-secret
type: cpaas.io/distribution-registry-token

    Если целевой OCI Registry не требует аутентификации, вы можете опустить информацию об аутентификации. Пример конфигурации:

    apiVersion: connectors.alauda.io/v1alpha1
kind: Connector
metadata:
  name: oci-registry-demo
spec:
  connectorClassName: oci
  address: https://registry.example.com
  auth:
    name: tokenAuth

    Требуемые права токена

    Необходимые права для настроенного токена зависят от того, как вы планируете его использовать в Pods/Pipelines.

    Например:

    • Операции pull образов: если вам нужно только скачивать образы через этот коннектор, токен должен иметь права только на чтение целевых репозиториев.
    • Операции pull и push образов: если вам нужно загружать образы через этот коннектор, токен должен иметь права на чтение и запись целевых репозиториев. Иными словами, токен должен позволять как скачивать, так и загружать образы в реестр.

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

    Прокси и конфигурация

    Для предоставления клиентам возможности доступа к OCI-репозиториям без учетных данных, тип OCI Connector предлагает прокси-сервер, который автоматически внедряет информацию для аутентификации.

    Клиенты, имеющие доступ к коннектору, могут использовать этот прокси-сервер для доступа к OCI-репозиториям без настройки учетных данных на стороне клиента.

    Для упрощения использования тип OCI Connector предоставляет конфигурационную информацию, которую можно монтировать в Pods через CSI. В Pod при выполнении операций с OCI автоматически может использоваться прокси-сервис для завершения операций с OCI.

    Прокси

    Адрес прокси

    При создании Connector система:

    1. Автоматически создаст Service для прокси.
    2. Запишет адрес прокси в поле status.proxy.httpAddress.

    Вы можете использовать этот адрес прокси для операций push и pull образов.

    Пример:

    apiVersion: connectors.alauda.io/v1alpha1
kind: Connector
metadata:
  name: oci-registry-demo
  namespace: default
spec:
  address: https://registry.example.com
  auth:
    name: tokenAuth
    secretRef:
      name: oci-registry-demo
  connectorClassName: oci
status:
  conditions:
  # . . .
  proxy:
    httpAddress:
      url: http://c-oci-registry-demo.default.svc.cluster.local/namespaces/oci-connector-demo/connectors/oci-connector

    Forward Proxy

    Вы можете монтировать информацию о прокси в Pods с помощью CSI, а затем использовать эту информацию через переменные окружения или конфигурационные файлы.

    volumes:
- name: proxyconfig
  csi:
    readOnly: true
    driver: connectors-csi
    volumeAttributes:
      connector.name: "harbor"

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

    export http_proxy=$(cat /{mount-path}/http.proxy)
export https_proxy=$(cat /{mount-path}/https.proxy)
export HTTP_PROXY=$http_proxy
export HTTPS_PROXY=$https_proxy
export no_proxy=localhost,127.0.0.1
export NO_PROXY=$no_proxy
echo "Используется прокси: http_proxy=$http_proxy, https_proxy=$https_proxy, no_proxy=$no_proxy"

    Reverse Proxy

    При использовании обратного прокси необходимо изменить адрес целевого образа на адрес прокси.

    Пример: registry.example.com/test/abc:v1 → c-oci-registry-demo.default.svc.cluster.local/namespaces/oci-connector-demo/connectors/oci-connector/test/abc:v1

    и смонтировать файлы конфигурации учетных данных в Pod, а также настроить адрес прокси в insecure-registries.

    OCI Connector, созданный на основе типа OCI Connector, предоставляет следующие конфигурации:

    registry-config: конфигурационные учетные данные, необходимые для OCI CLI, таких как buildkit, buildah.

    • Предоставляет конфигурационный файл config.json.
    • Содержит информацию для аутентификации, необходимую для доступа к прокси.

    Пример:

    // config.json

{
  "auths": {
      "<proxy address of the connector>": {
          "auth": "<authentication information required to access the connector proxy>"
      }
  }
}

    buildkitd: конфигурационная информация, необходимая для BuildKit Daemon.

    • Предоставляет конфигурационный файл buildkitd.toml.
    • В конфигурационном файле текущий коннектор по умолчанию будет указан как insecure-registries.

    Пример:

    insecure-entitlements = [ "network.host", "security.insecure" ]
[registry."<proxy address of the connector>"]
  http = true

    Вы можете монтировать эту конфигурационную информацию в Pods с помощью connectors-csi и в сочетании с возможностями прокси выполнять операции push или pull образов без использования секретов.

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