sa-kong
sa-kong
=======
Kong — это масштабируемый, открытый API-слой (также известный как API Gateway или API Middleware). Kong работает перед любым RESTful API и расширяется с помощью плагинов, которые добавляют дополнительные функции и услуги помимо основной платформы.
Kong изначально был разработан в компании Mashape для защиты, управления и расширения более 15 000 API и микросервисов для их API Marketplace, который обрабатывает миллиарды запросов в месяц для более 200 000 разработчиков. Сегодня Kong используется в критически важных развертываниях как в небольших, так и в крупных организациях.
Масштабируемый: Kong легко масштабируется горизонтально, просто добавляя больше машин, что позволяет вашей платформе справляться с практически любой нагрузкой, сохраняя при этом низкую задержку.
Модульный: Kong можно расширить, добавив новые плагины, которые легко настраиваются через RESTful Admin API.
Работает на любой инфраструктуре: Kong работает в любом месте. Вы можете развернуть Kong в облаке или на собственных серверах, включая одно- или многодатасетевые настройки, для публичных, частных или доступных только по приглашению API.
Вы, вероятно, слышали, что Kong построен на Nginx, используя его стабильность и эффективность. Но как это возможно?
Точнее говоря, Kong — это приложение на Lua, работающее в Nginx и обеспеченное модулем lua-nginx. Вместо того, чтобы компилировать Nginx с этим модулем, Kong распространяется вместе с OpenResty, который уже включает модуль lua-nginx. OpenResty не является ответвлением Nginx, а представляет собой набор модулей, расширяющих его возможности.
Это закладывает основу для архитектуры с возможностью подключения, где Lua-скрипты (называемые «плагинами») могут быть включены и выполнены во время выполнения. Из-за этого мы рассматриваем Kong как образец микросервисной архитектуры: в его основе реализована абстракция базы данных, маршрутизация и управление плагинами. Плагины могут находиться в отдельных кодовых базах и добавляться на любом этапе жизненного цикла запроса, всё это с помощью нескольких строк кода.
Примечание: версия Kong для сообщества не имеет пользовательского интерфейса. Вам может быть интересно рассмотреть некоторые open-source WEBUI, такие как https://github.com/PGBI/kong-dashboard или https://github.com/pantsel/konga/.
По нашему опыту, https://github.com/PGBI/kong-dashboard использует более надежные процессы разработки и выпуска, хотя konga выглядит более креативно.
# Установите Kong Dashboard
npm install -g kong-dashboard
# Запустите Kong Dashboard
kong-dashboard start --kong-url http://kong:8001
# Запустите Kong Dashboard на своем порту
kong-dashboard start \
--kong-url http://kong:8001 \
--port [порт]
roles:
- {
role: "sa-kong"
}
Расширенные настройки:
roles:
- {
role: "sa-kong",
kong_version: 2.0.1,
kong_activated_plugins: "bundled,oidc",
kong_luarocks_plugins:
- kong-oidc
kong_admin_http: "0.0.0.0:8001",
kong_admin_https: "127.0.0.1:8444",
kong_proxy_http: "0.0.0.0:8000",
kong_proxy_https: "0.0.0.0:8443",
kong_pg_host: "127.0.0.1",
kong_pg_port: 5432,
kong_pg_user: kong,
kong_pg_password: kong,
kong_pg_database: kong
}
Несортированные заметки для будущего использования
Плагины третьих сторон, которые могут вас заинтересовать
kong-oidc
https://github.com/nokia/kong-oidc
kong-oidc — это плагин для Kong, реализующий функциональность OpenID Connect Relying Party (RP).
Он аутентифицирует пользователей с помощью поставщика OpenID Connect, используя OpenID Connect Discovery и основной профиль клиента (т.е. поток авторизационного кода).
Он поддерживает сессии для аутентифицированных пользователей, используя lua-resty-openidc, предлагая настраиваемый выбор между хранением состояния сессии в куках браузера клиента или использованием серверных механизмов хранения, таких как shared-memory | memcache | redis.
Он поддерживает кэширование документов Discovery и валидированных токенов доступа на уровне сервера.
В целом вам потребуется сервер авторизации, поддерживающий OIDC с зарегистрированным клиентом, чтобы начать. Вы можете использовать решения, такие как Keycloak/Gluu, или те, которые предоставляются третьими сторонами (например, Google's https://developers.google.com/identity/protocols/OpenIDConnect; в этом случае вы использовали бы свою учетную запись Google для входа).
После того как у вас есть идентификатор клиента/секрет и URL Discovery OIDC (см. https://auth0.com/docs/tutorials/openid-connect-discovery), вы можете включить плагин.
Пример curl может выглядеть так:
curl -XPOST -d 'name=oidc' -d 'config.client_id=<идентификатор_клиента>' -d 'config.client_secret=<секрет_клиента>' -d 'config.discovery=<URL_Discovery_OIDC>' http://kong:8001/plugins
После этого, перед доступом к любым API, зарегистрированным в Kong, вы будете перенаправлены на сервер авторизации для входа.
Это также предоставит решение SSO для всех API в Kong.
Это делает Kong OIDC Relying Party, поэтому любой API за Kong может воспользоваться защитой аутентификации OIDC, не реализуя потоки OIDC.
На практике он использует грант авторизационного кода (https://auth0.com/docs/api-auth/grant/authorization-code). Если аутентифицированный пользователь пытается получить доступ к API в Kong, для которого включён этот плагин, он будет перенаправлен к странице входа на сервере авторизации (местоположение сервера авторизации задается через поле discovery в конфигурации). После успешного входа сервер авторизации предоставляет вам код доступа и перенаправляет обратно в Kong. Kong использует код доступа для получения доступа, идентификационного и обновляющего токенов.
Токены хранятся в зашифрованном куке сессии. Ключ шифрования представляет собой комбинацию нескольких переменных (агент пользователя, удаленный IP-адрес и т. д.) и session_secret, который можно определить при включении плагина (см. https://github.com/nokia/kong-oidc/blob/master/kong/plugins/oidc/schema.lua). Это поле является необязательным, но настоятельно рекомендуется и должно быть случайным!
Если плагин Kong увидит, что куки уже установлены, он расшифрует их и проверит токены. Также этот плагин обрабатывает обновление токена доступа с помощью токена обновления.
Он также добавляет некоторую информацию в запрос к серверу. Он устанавливает заголовок X-Userinfo с выводом из конечной точки Userinfo (https://connect2id.com/products/server/docs/api/userinfo).
В общем, поток OIDC и логика реализованы пакетом lua-resty-openidc.
Это безстатусное решение, хранилище данных Kong не используется. Поэтому, если вы используете этот куки в другом браузере или на другом компьютере — это не сработает. Чтобы аннулировать токены, вы можете обратиться к корневому URL /logout (http://
Исходные токены не отправляются на сервер защиты, но в заголовке X-Userinfo содержатся утверждения из идентификационного токена (но без подписей сервера авторизации).
Замечание: если вы собираетесь использовать плагин в контейнеризованном Kong, вам нужно будет
FROM kong:1.4.0-alpine
LABEL description="Alpine + Kong 1.4.0 + плагин kong-oidc"
RUN apk update && apk add git unzip luarocks
RUN luarocks install kong-oidc
В образе плагины могут быть активированы с помощью переменной окружения KONG_PLUGINS
KONG_PLUGINS=oidc
Пример из развертывания Kubernetes
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-kong
annotations:
plugins.konghq.com: oidc
spec:
rules:
- http:
paths:
- path: /graphql
backend:
serviceName: corphub-graphql-service
servicePort: 8082
---
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: kong-oidc
labels:
global: "true"
config:
client_id: kong
client_secret: XXX
discovery: http://keycloak:8180/auth/realms/master/.well-known/openid-configuration
plugin: oidc
Kong Middleman
https://github.com/pantsel/kong-middleman-plugin
Плагин Kong, который позволяет выполнить дополнительный HTTP POST-запрос перед проксированием оригинального запроса.
kong-external-oauth
https://github.com/mogui/kong-external-oauth
Плагин Kong, который позволяет использовать внешнего провайдера Oauth 2.0 для защиты вашего API.
$ luarocks install external-oauth
Чтобы сделать Kong осведомленным о том, что он должен искать новый плагин, вам нужно будет добавить его в свойство custom_plugins в конфигурационном файле.
custom_plugins:
- external-oauth
Вы можете добавить плагин с помощью следующего запроса:
$ curl -X POST http://kong:8001/apis/{api}/plugins \
--data "name=external-oauth" \
--data "config.authorize_url=https://oauth.something.net/openid-connect/authorize" \
--data "config.scope=openid+profile+email" \
--data "config.token_url=https://oauth.something.net/openid-connect/token" \
--data "config.client_id=SOME_CLIENT_ID" \
--data "config.client_secret=SOME_SECRET_KEY" \
--data "config.user_url=https://oauth.something.net/openid-connect/userinfo" \
--data "config.user_keys=email,name,sub" \
--data "config.hosted_domain=mycompany.com" \
--data "config.email_key=email"
| Параметр формы | по умолчанию | описание |
|---|---|---|
name |
имя плагина external-oauth |
|
config.authorize_url |
авторизационный URL провайдера OAUTH (по которому вы будете перенаправлены при отсутствии аутентификации) | |
config.scope |
область OAUTH запроса авторизации | |
config.token_url |
URL провайдера Oauth для запроса токена доступа | |
config.client_id |
Идентификатор клиента OAUTH | |
config.client_secret |
Секрет клиента OAUTH | |
config.user_url |
URL провайдера oauth, используемый для получения информации о пользователе и также для проверки действительности токена доступа | |
config.user_keys Необязательный |
username,email |
ключи для извлечения из возвращаемого json-объекта конечной точки user_url, они также будут добавлены в заголовки сервера как X-OAUTH-XXX |
config.hosted_domain |
домен, пользователи которого должны принадлежать для входа в систему. Игнорируется, если пустой | |
config.email_key |
ключ, который должен проверяться для хостинг-домена, взятый с конечной точки информации о пользователе | |
config.user_info_periodic_check |
60 | время в секундах между проверками токена |
В дополнение к user_keys будет добавлен заголовок X-OAUTH-TOKEN с токеном доступа провайдера.
Подключение базы данных Postgres
Файл pg_hba.conf после модификаций будет выглядеть примерно так:
local all postgres peer
# TYPE DATABASE USER ADDRESS METHOD
# "local" предназначен только для соединений по сокету Unix
local all all md5
# local all all peer
# IPv4 локальные соединения:
host all all 127.0.0.1/32 password
host all all 127.0.0.1/32 md5
# IPv6 локальные соединения:
host all all ::1/128 md5
# Разрешить соединения репликации с localhost пользователем с
# привилегиями репликации.
#local replication postgres peer
#host replication postgres 127.0.0.1/32 md5
#host replication postgres ::1/128 md5
Ссылки на третьи стороны
Панели управления
Konga https://github.com/pantsel/konga (Kong > 1)
Kong-Dashboard https://github.com/PGBI/kong-dashboard (Kong > 0.9)
Инструменты декларативной конфигурации
kongfig https://github.com/mybuilder/kongfig (Kong < 1)
Deck https://github.com/hbagdi/deck (Kong >= 1)
Использование в рабочем процессе ansible galaxy
Если вы установили роль sa-kong с помощью команды
ansible-galaxy install softasap.sa-kong
Роль будет доступна в папке library/sa-kong.
Пожалуйста, отредактируйте путь соответственно.
- {
role: "softasap.sa-kong"
}
Авторские права и лицензия
Код лицензируется по двум лицензиям: BSD 3 clause и MIT License. Выберите тот, который лучше всего подходит вам.
Свяжитесь с нами:
Подписывайтесь на обновления ролей в FB
Присоединяйтесь к обсуждению в Gitter в канале Gitter
Откройте для себя другие роли на http://www.softasap.com/roles/registry_generated.html
Посетите наш блог на http://www.softasap.com/blog/archive.html
ansible-galaxy install softasap/sa-kong