softasap.sa-kong

sa-kong

Kong to skalowalna, otwarta warstwa API (znana również jako brama API lub middleware API). Kong działa przed każdym API RESTful i może być rozszerzany za pomocą wtyczek, które oferują dodatkowe funkcjonalności i usługi poza podstawową platformą.

Kong został początkowo stworzony w firmie Mashape w celu zabezpieczenia, zarządzania i rozszerzania ponad 15 000 API i mikroserwisów w jej rynku API, który generuje miliardy żądań miesięcznie dla ponad 200 000 deweloperów. Dziś Kong jest używany w kluczowych wdrożeniach w małych i dużych organizacjach.

Skalowalny: Kong łatwo skaluje się poziomo poprzez dodawanie kolejnych maszyn, co oznacza, że Twoja platforma może obsługiwać praktycznie każdy ładunek przy niskiej latencji.

Modularny: Kong można rozszerzać, dodając nowe wtyczki, które można łatwo skonfigurować za pomocą RESTful Admin API.

Działa na każdej infrastrukturze: Kong działa wszędzie. Możesz wdrożyć Kong w chmurze lub w lokalnych środowiskach, w tym w jednolitych lub wielo-datacenter, oraz dla publicznych, prywatnych lub wyłącznie zaproszonych API.

Prawdopodobnie słyszałeś, że Kong jest zbudowany na Nginx, wykorzystując jego stabilność i wydajność. Ale jak to jest możliwe?

Mówiąc dokładniej, Kong jest aplikacją napisaną w Lua, działającą w Nginx i możliwą dzięki modułowi lua-nginx. Zamiast kompilować Nginx z tym modułem, Kong jest dystrybuowany razem z OpenResty, który już zawiera lua-nginx-module. OpenResty nie jest forką Nginx, ale zestawem modułów rozszerzających jego możliwości.

To tworzy podstawy architektury z wtyczkami, gdzie skrypty Lua (określane jako "wtyczki") mogą być aktywowane i wykonywane w czasie rzeczywistym. Z tego powodu lubimy myśleć o Kongu jako o wzorze architektury mikroserwisów: w swoim rdzeniu implementuje abstrakcję bazy danych, routing i zarządzanie wtyczkami. Wtyczki mogą żyć w oddzielnych bazach kodu i być wstrzykiwane w dowolne miejsce w cyklu żądań, wszystko w kilku linijkach kodu.

architektura

Uwaga: wersja społecznościowa Konga nie ma interfejsu użytkownika. Możesz rozważyć użycie jakiegoś otwarto-źródłowego WEBUI, jak https://github.com/PGBI/kong-dashboard lub https://github.com/pantsel/konga/.

Z naszego doświadczenia wynika, że https://github.com/PGBI/kong-dashboard używa bardziej zaawansowanych procesów rozwoju i wydania, choć konga wygląda bardziej kreatywnie.

# Zainstaluj Kong Dashboard
npm install -g kong-dashboard

# Uruchom Kong Dashboard
kong-dashboard start --kong-url http://kong:8001

# Uruchom Kong Dashboard na niestandardowym porcie
kong-dashboard start \
  --kong-url http://kong:8001 \
  --port [port]

  roles:
    - {
        role: "sa-kong"
      }

Zaawansowane:

  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
      }

Niesortowane notatki do przyszłego użytku.

Wtyczki zewnętrzne, które mogą Cię interesować

kong-oidc

https://github.com/nokia/kong-oidc

kong-oidc to wtyczka do Konga implementująca funkcjonalność Relying Party OpenID Connect (RP).

Autoryzuje użytkowników w stosunku do dostawcy OpenID Connect, wykorzystując OIDC Discovery i podstawowy profil klienta (tj. przepływ kodu autoryzacyjnego).

Zarządza sesjami dla autoryzowanych użytkowników, wykorzystując lua-resty-openidc, oferując konfigurowalny wybór między przechowywaniem stanu sesji w cookie przeglądarki klienta lub używaniem serwerowych mechanizmów przechowywania shared-memory|memcache|redis.

Obsługuje pamięć podręczną dla dokumentów Discovery i zwalidowanych tokenów dostępu w całym serwerze.

Ogólnie będziesz potrzebować serwera autoryzacji wspierającego OIDC z zarejestrowanym klientem, aby rozpocząć. Możesz używać np. rozwiązań takich jak Keycloak/Gluu lub tych dostarczanych przez strony trzecie (np. Google’a: https://developers.google.com/identity/protocols/OpenIDConnect; w tym przypadku użyjesz swojego konta Google do zalogowania).

Po uzyskaniu identyfikatora klienta/sekretu i adresu URL OIDC Discovery (patrz https://auth0.com/docs/tutorials/openid-connect-discovery), możesz aktywować wtyczkę.

Przykład żądania curl może wyglądać tak:

curl -XPOST -d 'name=oidc' -d 'config.client_id=<client_id>' -d 'config.client_secret=<client_secret>' -d 'config.discovery=<OIDC_Discovery_url>' http://kong:8001/plugins

Po tym, przed dostępem do jakichkolwiek API zarejestrowanych w Kongu, zostaniesz przekierowany do serwera autoryzacyjnego w celu zalogowania się. To również zapewni rozwiązanie SSO dla wszystkich API w Kongu.

Kong staje się Relying Party OIDC, więc każde API za Kongiem może korzystać z ochrony uwierzytelniania OIDC bez implementowania przepływów OIDC.

W praktyce wykorzystuje Grant kodu autoryzacyjnego (https://auth0.com/docs/api-auth/grant/authorization-code). Jeśli użytkownik, który nie jest zalogowany, spróbuje uzyskać dostęp do API na Kongu, na którym ta wtyczka jest aktywowana, system przekieruje użytkownika (przeglądarkę) na stronę logowania na AS (LOKALIZACJA AS jest ustawiana za pomocą pola discovery w konfiguracji). Po pomyślnym zalogowaniu, AS daje Ci kod dostępu i przekierowuje z powrotem do Konga. Kong używa kodu dostępu do uzyskania tokenów dostępu, identyfikacji i odświeżania.

Tokeny są przechowywane w szyfrowanym cookie sesji. Klucz szyfrowania jest kombinacją kilku zmiennych (agenta użytkownika, zdalnego adresu IP…) i secretu sesji, który można zdefiniować podczas aktywacji wtyczki (patrz https://github.com/nokia/kong-oidc/blob/master/kong/plugins/oidc/schema.lua). To pole jest opcjonalne, ale bardzo zalecane i musi być losowe!

Jeśli wtyczka Konga zobaczy, że istnieje już ustawione cookie, zdekoduje je i zweryfikuje tokeny. Odświeżanie tokenu dostępu za pomocą tokenu odświeżania również jest obsługiwane przez tę wtyczkę.

Dodaje także pewne informacje do żądania dla serwera upstream. Ustawia nagłówek X-Userinfo z danymi z endpointu Userinfo (https://connect2id.com/products/server/docs/api/userinfo).

Ogólnie rzecz biorąc, przepływ OIDC i logika są zaimplementowane przez paczkę lua-resty-openidc.

Jest stateless, baza danych Konga nie jest używana. Tak więc, jeśli użyjesz tego cookie w innej przeglądarce lub na innym komputerze - nie zadziała. Aby unieważnić tokeny, możesz złożyć zapytanie do adresu głównego /logout (http:///logout). To spowoduje wywołanie punktu końcowego kończącego sesję OIDC.

Oryginalne tokeny nie są wysyłane do serwera upstream, ale nagłówek X-Userinfo zawiera roszczenia z tokena ID (ale bez podpisów AS).

Uwaga - jeśli planujesz używać wtyczki w dockerowym kongu, będziesz potrzebować:

FROM kong:1.4.0-alpine
LABEL description="Alpine + Kong 1.4.0 + wtyczka kong-oidc"
RUN apk update && apk add git unzip luarocks
RUN luarocks install kong-oidc

w obrazie można aktywować wtyczki za pomocą zmiennej środowiskowej KONG_PLUGINS

KONG_PLUGINS=oidc

Przykład z wdrożeniem 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

Wtyczka Konga, która umożliwia dodatkowe żądanie HTTP POST przed przekazaniem oryginalnego żądania.

kong-external-oauth

https://github.com/mogui/kong-external-oauth

Wtyczka Konga, która pozwala wykorzystać zewnętrznego dostawcę Oauth 2.0 do ochrony Twojego API.

$ luarocks install external-oauth

Aby Kong mógł wiedzieć, że powinien szukać nowej wtyczki, musisz ją dodać do właściwości custom_plugins w pliku konfiguracyjnym.

custom_plugins:
    - external-oauth

Możesz dodać wtyczkę za pomocą następującego żądania:

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

Parametr formularza	domyślnie	opis
`name`		nazwa wtyczki `external-oauth`
`config.authorize_url`		adres URL autoryzacji dostawcy OAUTH (na który będziesz przekierowywany, gdy nie jesteś uwierzytelniony)
`config.scope`		zakres OAUTH żądania autoryzacji
`config.token_url`		adres URL dostawcy Oauth do żądania tokenu dostępu
`config.client_id`		identyfikator klienta OAUTH
`config.client_secret`		sekret klienta OAUTH
`config.user_url`		adres URL dostawcy oauth używany do pobierania informacji o użytkowniku i sprawdzania ważności tokenu dostępu
`config.user_keys` Opcjonalne	`username,email`	klucze do pobrania z odpowiedzi json endpointu `user_url`, będą one również dodane do nagłówków serwera upstream jako `X-OAUTH-XXX`
`config.hosted_domain`		domena, której użytkownicy muszą należeć, aby się zalogować. Ignorowane jeśli puste
`config.email_key`		klucz do sprawdzenia domeny hostowanej, pobierany z endpointu informacji o użytkowniku
`config.user_info_periodic_check`	60	czas w sekundach między kontrolami tokenów

Oprócz user_keys dodany zostanie nagłówek X-OAUTH-TOKEN z tokenem dostawcy.

Backend Postgres

pg_hba.conf po modyfikacjach będzie wyglądał podobnie jak

local   all             postgres                                peer

# TYP  BAZA DANYCH        UŻYTKOWNIK            ADRES                 METODA

# "local" jest tylko dla lokalnych połączeń UNIX.
local   all             all                                     md5
# local   all             all                                     peer
# Połączenia lokalne IPv4:
host    all             all             127.0.0.1/32            password
host    all             all             127.0.0.1/32            md5
# Połączenia lokalne IPv6:
host    all             all             ::1/128                 md5
# Pozwól na połączenia replikacji z localhost przez użytkownika z prawami replikacji.
#local   replication     postgres                                peer
#host    replication     postgres        127.0.0.1/32            md5
#host    replication     postgres        ::1/128                 md5

Przydatne odniesienia

Pulpity

Konga             https://github.com/pantsel/konga              (Kong > 1)
Kong-Dashboard    https://github.com/PGBI/kong-dashboard        (Kong > 0.9)

Narzędzia do konfiguracji deklaratywnej

kongfig           https://github.com/mybuilder/kongfig          (Kong < 1)
Deck              https://github.com/hbagdi/deck                (Kong >= 1)

Wykorzystanie z workflow ansible galaxy

Jeśli zainstalowałeś rolę sa-kong przy użyciu komendy

ansible-galaxy install softasap.sa-kong

rola będzie dostępna w folderze library/sa-kong.

Proszę dostosować ścieżkę odpowiednio.


     - {
         role: "softasap.sa-kong"
       }

Copyright i licencja

Kod jest licencjonowany w systemie dualnym w ramach [BSD 3-clauses] (https://opensource.org/licenses/BSD-3-Clause) i [MIT License] (http://opensource.org/licenses/MIT). Wybierz tę, która najlepiej Ci odpowiada.

Skontaktuj się z nami:

Subskrybuj aktualizacje ról na [FB] (https://www.facebook.com/SoftAsap/)

Dołącz do dyskusji na kanale gitterowym na Gitter

Odkryj inne role pod http://www.softasap.com/roles/registry_generated.html

odwiedź nasz blog pod http://www.softasap.com/blog/archive.html

O projekcie