Авторизация ключа API для Амбассадора
Я пытаюсь понять, как создать простой прокси-сервер, защищенный ключом API, с помощью Ambassador на k8s, но, похоже, не могу найти никаких документов по этому поводу.
В частности, я просто хочу настроить его так, чтобы он мог принимать запрос с заголовком API-KEY, аутентифицировать его и, если API-KEY действителен для какого-либо клиента, передавать его на мой сервер.
Ответы 2
Я предлагаю вам сделать следующее:
Создайте приложение аутентификации: для каждой защищенной конечной точки это приложение будет отвечать за проверку ключа API.
Настройка Ambassador для перенаправления запросов к этой службе: вам просто нужно аннотировать определение службы приложения для проверки подлинности. Пример:
---
apiVersion: v1
kind: Service
metadata:
name: auth-app
annotations:
getambassador.io/config: |
---
apiVersion: ambassador/v1
kind: AuthService
name: authentication
auth_service: "auth-app:8080"
allowed_request_headers:
- "API-KEY"
spec:
type: ClusterIP
selector:
app: auth-app
ports:
- port: 8080
name: auth-app
targetPort: auth-app
- Настройте конечную точку в приложение авторизации, соответствующую конечной точке приложения, которое вы хотите аутентифицировать. Предположим, у вас есть приложение с таким отображением:
apiVersion: ambassador/v1
kind: Mapping
name: myapp-mapping
prefix: /myapp/
service: myapp:8000
Затем вам нужно иметь конечную точку "/мое приложение/" в приложение авторизации. Там вы прочтете свой заголовок API-КЛЮЧ. Если ключ действителен, верните HTTP 200 (ОК). Затем представитель отправит исходное сообщение на мое приложение. Если приложение авторизации возвращает что-либо еще, кроме HTTP 200, представитель вернет этот ответ клиенту.
- Обход аутентификации в необходимых приложениях. Например, вам может понадобиться приложение для входа в систему, отвечающее за предоставление ключа API клиентам. Вы можете обойти аутентификацию для этих приложений, используя bypass_auth: правда в сопоставлении:
apiVersion: ambassador/v1
kind: Mapping
name: login-mapping
prefix: /login/
service: login-app:8080
bypass_auth: true
Проверь это, если вы хотите узнать больше об аутентификации в Ambassador
Обновлено: Согласно этому ответу рекомендуется использовать в качестве заголовка Authorization: Bearer {base64-API-KEY}. В Ambassador заголовок Авторизация разрешен по умолчанию, поэтому вам не нужно передавать его в поле allow_request_headers.
В случае версии с открытым исходным кодом — да, единственный метод аутентификации — через внешнюю службу. Моя команда разработчиков также была разочарована этим, но после разработки дополнительной службы мы получили возможность создавать собственные правила и механизмы аутентификации, которые могут быть разными для каждой конечной точки. Согласно странице платной версии Амбассадор Про, эта версия имеет интеграцию с OAuth, проверкой JWT и функцией ключей API, которая появится в ближайшее время. Версия Pro довольно новая, поэтому я предполагаю, что большинство пользователей Ambassador прекрасно справились с внешней аутентификацией.
Я остановился на этом быстром и грязном решении после того, как не нашел простого подхода (который не включал бы запуск внешней службы аутентификации).
Вы можете использовать Маршрутизация на основе заголовков и разрешать входящие запросы только с соответствующим header:value.
---
apiVersion: getambassador.io/v2
kind: Mapping
metadata:
name: protected-mapping
namespace: default
spec:
prefix: /protected-path/
rewrite: /
headers:
# Poorman's Bearer authentication
# Ambassador will return a 404 error unless the Authorization header value is set as below on the incoming requests.
Authorization: "Bearer <token>"
service: app:80
Тестирование
# Not authenticated => 404
$ curl -sI -X GET https://ambassador/protected-path/
HTTP/1.1 404 Not Found
date: Thu, 11 Mar 2021 18:30:27 GMT
server: envoy
content-length: 0
# Authenticated => 200
$ curl -sI -X GET -H 'Authorization: Bearer eEVCV1JtUzBSVUFvQmw4eVRVM25BenJa' https://ambassador/protected-path/
HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
vary: Origin
date: Thu, 11 Mar 2021 18:23:20 GMT
content-length: 15
x-envoy-upstream-service-time: 3
server: envoy
Хотя технически здесь можно использовать любую пару header:value (например, x-my-auth-header: header-value), схема Authorization: Bearer ... выглядит как лучший вариант, если вы хотите следовать стандарту.
Будете ли вы кодировать base64 или нет ваш токен в этом случае, зависит от вас.
Вот подробное объяснение того, как читать и понимать спецификации в этом отношении: https://stackoverflow.com/a/56704746/4550880
Это сводится к следующему формату регулярного выражения для значения токена:
[-a-zA-Z0-9._~+/]+=*
Означает ли это, что Ambassador не выполняет никаких проверок ключей API самостоятельно, и мне всегда придется предоставлять для этого дополнительную услугу?