Эта страница переведена с помощью Cloud Translation API.

Руководство по эксплуатации

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация

Как получить ключ API

В следующем примере объясняется, как получить ключ API, который можно использовать для проверки вызовов API к целевой службе, проксируемой через адаптер Apigee для Envoy.

1. Войдите в Apigee.

Откройте пользовательский интерфейс Apigee в браузере.
В пользовательском интерфейсе выберите ту же организацию, которую вы использовали для настройки адаптера Apigee для Envoy.

2. Создайте разработчика

Вы можете использовать существующего разработчика для тестирования или создать нового следующим образом:

Выберите «Опубликовать» > «Разработчики» в боковом меню навигации.
Нажмите + Разработчик.
Заполните диалоговое окно, чтобы создать нового разработчика. Вы можете использовать любое имя/адрес электронной почты разработчика по вашему желанию.

3. Создайте продукт API

Следуйте примеру создания продукта, приведенному ниже. См. также О конфигурации продукта API .

Выберите «Опубликовать» > «Продукты API» в боковом меню навигации.
Нажмите + Продукт API .
Заполните страницу сведений о продукте следующим образом.

Поле	Ценить
Имя	`httpbin-product`
Отображаемое имя	`httpbin product`
Среда	`your_environment` Установите для этого параметра среду, которую вы использовали при подготовке адаптера Apigee для Envoy.
Доступ	`Private`
Квота	5 запросов каждые 1 минуту См. также Квота .

В разделе «Цели удаленной службы Apigee» нажмите «Добавить цель удаленной службы Apigee» .

В диалоговом окне «Цель удаленной службы Apigee» добавьте следующие значения:

Атрибут	Ценить	Описание
Имя цели	Введите имя целевой службы. Например: `httpbin.org`	Целевая конечная точка, на которой находится прокси-сервер Envoy.
Путь	Введите путь к ресурсу в службе, который соответствует. Например: `/headers` .	Путь запроса для сопоставления в целевой конечной точке. Вызовы прокси-сервера API по этому пути будут соответствовать этому продукту API.

Нажмите Сохранить .

4. Создайте приложение для разработчика

Выберите «Опубликовать» > «Приложения» в боковом меню навигации.
Нажмите + Приложение .
Заполните страницу приложения разработчика следующим образом. Не сохраняйте данные до тех пор, пока не будет получено соответствующее указание.

Имя	`httpbin-app`
Отображаемое имя	`httpbin app`
Разработчик	Выберите разработчика, которого вы создали ранее, или любого разработчика из списка.

Затем добавьте продукт API в приложение:

В разделе «Учетные данные» нажмите + Добавить продукт и выберите только что настроенный продукт: httpbin-product .
Нажмите Создать .
В разделе «Учетные данные» нажмите «Показать» рядом с ключом .
Скопируйте значение ключа потребителя. Это значение представляет собой ключ API , который вы будете использовать для вызовов API службы httpbin .

О продуктах API

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

Определение продукта API

Когда вы определяете продукт API в Apigee, вы можете установить ряд параметров, которые будут использоваться для оценки запросов:

Цель
Путь запроса
Квота
Области действия OAuth

Цели удаленного обслуживания

Определение продукта API будет применяться к запросу, если запрос соответствует как целевой привязке (например, httpbin.org ), так и пути запроса (например, /httpbin ). Список потенциальных целей хранится в качестве атрибута Продукта API.

По умолчанию Apigee Remote Service сверяет специальный заголовок :authority (host) Envoy со своим списком целей; однако его можно настроить на использование других заголовков.

Путь к ресурсу API

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

Одиночная косая черта ( / ) сама по себе соответствует любому пути.
* действителен в любом месте и соответствует внутри сегмента (между косыми чертами).
** действителен в конце и соответствует всему, что находится в конце строки.

Квота

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

Варианты использования квот

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

Квота определяется в продукте API.

Параметры квоты настраиваются в продуктах API. Например, когда вы создаете продукт API, вы можете дополнительно установить разрешенный предел квоты, единицу времени и интервал.

Поскольку ключи API сопоставляются с Продуктами API, каждый раз при проверке ключа API соответствующий счетчик квоты может уменьшаться (если квота определена в связанном Продукте).

В отличие от среды выполнения Apigee, квоты, введенные в определение продукта, автоматически применяются удаленной службой Apigee. Если запрос авторизован, он будет засчитан в разрешенную квоту.

Где сохраняются квоты

Квоты поддерживаются и проверяются локально процессом Remote Service и асинхронно поддерживаются с помощью Apigee Runtime. Это означает, что квоты неточны и, скорее всего, будут превышены, если у вас есть более одной удаленной службы, поддерживающей квоту. Если соединение с Apigee Runtime прерывается, локальная квота будет действовать как отдельная квота до тех пор, пока она не сможет повторно подключиться к Apigee Runtime.

Области OAuth

Если вы используете токены JWT, вы можете ограничить их подмножествами разрешенных областей OAuth. Области действия, назначенные вашему выданному токену JWT, будут проверены на соответствие областям продукта API.

О приложениях для разработчиков

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

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

Вы можете использовать токен JWT для выполнения аутентифицированных вызовов прокси-сервера API вместо использования ключа API. В этом разделе объясняется, как использовать команду apigee-remote-service-cli token для создания, проверки и ротации токенов JWT.

Обзор

Проверка и аутентификация JWT осуществляется Envoy с помощьюфильтра аутентификации JWT .

После аутентификации фильтр Envoy ext-authz отправляет заголовки запроса и JWT в apigee-remote-service-envoy . Он сопоставляет api_product_list и scope JWT с продуктами Apigee API, чтобы авторизовать его в отношении цели запроса.

Создание токенов Apigee JWT

Токены Apigee JWT можно создать с помощью CLI:

$CLI_HOME/apigee-remote-service-cli token create -c config.yaml --id $KEY --secret $SECRET

Или с помощью стандартной конечной точки токена OAuth. Пример завитка:

curl https://org-env.apigee.net/remote-token/token -d '{"client_id":"myclientid","client_secret":"myclientsecret","grant_type":"client_credentials"}' -H "Content-type: application/json"

Использование токена JWT

Получив токен, вы просто передаете его Envoy в заголовке авторизации. Пример:

curl localhost:8080/httpbin/headers -i -H "Authorization:Bearer $TOKEN"

Ошибка токена JWT

Отказ посланника

Если Envoy отклоняет токен, вы можете увидеть сообщение следующего вида:

Jwks remote fetch is failed

Если это так, убедитесь, что ваша конфигурация Envoy содержит действительный URI в разделе remote_jwks , что он доступен для Envoy и что вы правильно установили сертификаты при установке прокси-сервера Apigee. Вы должны иметь возможность напрямую вызывать URI с помощью вызова GET и получать действительный ответ JSON.

Пример:

curl https://myorg-eval-test.apigee.net/remote-service/certs

Другие сообщения от Envoy могут выглядеть так:

«Аудитория в JWT запрещена»
«Издатель Jwt не настроен»

Это требования вашей конфигурации Envoy, которые вам, возможно, придется изменить.

Проверка токена

Вы можете использовать CLI для проверки вашего токена. Пример

$CLI_HOME/apigee-remote-service-cli -c config.yaml token inspect -f path/to/file

или

$CLI_HOME/apigee-remote-service-cli -c config.yaml token inspect <<< $TOKEN

Отладка

См. раздел «Неверный ключ API» .

Ведение журнала

Вы можете настроить уровень ведения журнала в службе $REMOTE_SERVICE_HOME/apigee-remote-service-envoy. Все журналы отправляются на stdout и stderr.

Элемент	Необходимый	Описание
-l, --log-уровень	Допустимые уровни: отладка, информация, предупреждение, ошибка.	Регулирует уровень ведения журнала. По умолчанию: информация
-j, --json-log		Выдает выходные данные журнала в виде записей JSON.

Envoy обеспечивает ведение журнала. Для получения дополнительной информации см. следующие ссылки на документацию Envoy:

Использование сетевого прокси

HTTP-прокси можно вставить с помощью переменных среды HTTP_PROXY и HTTPS_PROXY в среде двоичного файла apigee-remote-service-envoy. При их использовании также можно использовать переменную среды NO_PROXY, чтобы исключить отправку определенных хостов через прокси.

HTTP_PROXY=http://[user]:[pass]@[proxy_ip]:[proxy_port]
HTTPS_PROXY=http://[user]:[pass]@[proxy_ip]:[proxy_port]
NO_PROXY=127.0.0.1,localhost

Помните, что прокси-сервер должен быть доступен из apigee-remote-service-envoy.

О метриках и аналитике

Конечная точка метрик Prometheus доступна по адресу :5001/metrics . Вы можете настроить этот номер порта. См. файл конфигурации .

Аналитика посланника

Следующие ссылки предоставляют информацию о получении данных аналитики прокси-сервера Envoy:

Истио аналитика

Следующие ссылки предоставляют информацию о получении данных аналитики прокси-сервера Envoy:

Апиджи-аналитика

Apigee Remote Service for Envoy отправляет статистику запросов в Apigee для аналитической обработки. Apigee сообщает об этих запросах под соответствующим названием продукта API.

Информацию об аналитике Apigee см. в разделе Обзор сервисов аналитики .

Поддержка мультитенантной среды

Теперь вы можете включить адаптер для обслуживания нескольких сред в организации Apigee. Эта функция позволяет вам использовать один адаптер Apigee для Envoy, связанный с одной организацией Apigee, для обслуживания нескольких сред. До этого изменения один адаптер всегда был привязан к одной среде Apigee.

Чтобы настроить поддержку нескольких сред, измените значение tenant:env_name на * в файле config.yaml . Например:

Откройте файл config.yaml в редакторе.

Измените значение tenant.env_name на * . Например:

apiVersion: v1
kind: ConfigMap
metadata:
  name: apigee-remote-service-envoy
  namespace: apigee
data:
  config.yaml: |
    tenant:
      remote_service_api: https://myorg-myenv.apigee.net/remote-service
      org_name: apigee-docs-hybrid-a
      env_name: *
      allow_unverified_ssl_cert: true
    analytics:
      collection_interval: 10s
    auth:
      jwt_provider_key: https://myorg-myenv.apigee.net.net/remote-token/token

Сохраните файл.
Примените файл:
```
kubectl apply -f $CLI_HOME/config.yaml
```

При настройке режима нескольких сред необходимо также настроить Envoy для отправки адаптеру соответствующего значения среды, добавив следующие метаданные в раздел virtual_hosts:routes файла envoy-config.yaml . Например:

Создайте файл envoy-config.yaml с помощью CLI. Например:

$CLI_HOME/apigee-remote-service-cli samples create \
  -t envoy-1.16 -c ./config.yaml --out myconfigs

Откройте сгенерированный файл (он называется envoy-config.yaml ).

Добавьте следующие метаданные в раздел virtual_host или routes файла:

typed_per_filter_config:
  envoy.filters.http.ext_authz:
    "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthzPerRoute
    check_settings:
      context_extensions:
        apigee_environment: test

В следующем примере показана конфигурация virtual_host с несколькими определенными маршрутами, где каждый маршрут отправляет трафик в определенную среду:

filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: ingress_http
          route_config:
            virtual_hosts:
            - name: default
              domains: "*"
              routes:
              - match: { prefix: /test }
                route:
                  cluster: httpbin
                typed_per_filter_config:
                  envoy.filters.http.ext_authz:
                    "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthzPerRoute
                    check_settings:
                      context_extensions:
                         apigee_environment: test
              - match: { prefix: /prod }
                route:
                  cluster: httpbin
                typed_per_filter_config:
                  envoy.filters.http.ext_authz:
                    "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthzPerRoute
                    check_settings:
                      context_extensions:
                         apigee_environment: prod

Повторите последний шаг, чтобы добавить дополнительные среды по мере необходимости.
Сохраните файл и примените его.
Примечание. Если для env_name в config.yaml установлено любое другое значение, кроме * , адаптер вернет Envoy ошибку, и запрос будет отклонен, если в конфигурации адаптера env_name не установлено значение * или свойство env_name не соответствует. переданные метаданные apigee_environment .

Настройка mTLS между адаптером и средой выполнения Apigee

Вы можете предоставить сертификаты TLS на стороне клиента в разделе tenant файла config.yaml адаптера, чтобы использовать mTLS между адаптером и средой выполнения Apigee. Это изменение применяется ко всем поддерживаемым платформам Apigee. Он также позволяет использовать mTLS для аналитики для платформы Apigee Edge for Private Cloud. Например:

tenant:
  tls:
    ca_file: path/ca.pem
    cert_file: path/cert.pem
    key_file: path/key.pem
    allow_unverified_ssl_cert: false