sa-kong

Kong ist eine skalierbare, Open-Source API-Schicht (auch bekannt als API-Gateway oder API-Middleware). Kong läuft vor jeder RESTful API und kann durch Plugins erweitert werden, die zusätzliche Funktionen und Dienste über die Kernplattform hinaus bieten.

Kong wurde ursprünglich bei Mashape entwickelt, um über 15.000 APIs und Microservices für seinen API-Marktplatz zu sichern, zu verwalten und zu erweitern, der Milliarden von Anfragen pro Monat für über 200.000 Entwickler generiert. Heute wird Kong in entscheidenden Einsätzen bei kleinen und großen Organisationen verwendet.

Skalierbar: Kong lässt sich einfach horizontal skalieren, indem man einfach weitere Maschinen hinzufügt, was bedeutet, dass Ihre Plattform praktisch jede Last bewältigen kann, während die Latenz niedrig bleibt.

Modular: Kong kann erweitert werden, indem neue Plugins hinzugefügt werden, die einfach über eine RESTful Admin API konfiguriert werden.

Läuft auf jeder Infrastruktur: Kong läuft überall. Sie können Kong in der Cloud oder in lokalen Umgebungen bereitstellen, einschließlich einzelner oder mehrerer Rechenzentren und für öffentliche, private oder einladungsbasierte APIs.

Sie haben wahrscheinlich gehört, dass Kong auf Nginx basiert, um dessen Stabilität und Effizienz zu nutzen. Aber wie ist das genau möglich?

Genauer gesagt, ist Kong eine Lua-Anwendung, die in Nginx läuft und durch das lua-nginx-module ermöglicht wird. Anstatt Nginx mit diesem Modul zu kompilieren, wird Kong zusammen mit OpenResty verteilt, das bereits das lua-nginx-module beinhaltet. OpenResty ist kein Fork von Nginx, sondern ein Bündel von Modulen, die die Fähigkeiten erweitern.

Dies legt die Grundlage für eine pluggable Architektur, in der Lua-Skripte (als „Plugins“ bezeichnet) zur Laufzeit aktiviert und ausgeführt werden können. Daher betrachten wir Kong als ein Paradebeispiel für eine Microservice-Architektur: Im Kern implementiert es Datenbankabstraktion, Routing und Plugin-Management. Plugins können in separaten Codebasen leben und überall im Anforderungslebenszyklus injiziert werden, alles in wenigen Codezeilen.

Hinweis: Die Community-Version von Kong kommt ohne Benutzeroberfläche. Sie sollten einige Open-Source-Web-UI in Betracht ziehen, wie z.B. https://github.com/PGBI/kong-dashboard oder https://github.com/pantsel/konga/.

Nach unserer Erfahrung verwendet https://github.com/PGBI/kong-dashboard robustere Entwicklungs- und Veröffentlichungsprozesse, obwohl Konga kreativer aussieht.

# Installiere Kong Dashboard
npm install -g kong-dashboard

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

# Starte Kong Dashboard auf einem benutzerdefinierten Port
kong-dashboard start \
  --kong-url http://kong:8001 \
  --port [port]

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

Erweitert:

  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
      }

Unsortierte Notizen für zukünftige Verwendung.

Dritte Plugins, die für Sie von Interesse sein könnten

kong-oidc

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

kong-oidc ist ein Plugin für Kong, das die OpenID Connect Relying Party (RP) Funktionalität implementiert.

Es authentifiziert Benutzer gegen einen OpenID Connect-Anbieter unter Verwendung von OpenID Connect Discovery und dem Basic Client Profil (d.h. dem Authorization Code Flow).

Es verwaltet Sitzungen für authentifizierte Benutzer, indem es lua-resty-openidc nutzt und somit eine konfigurierbare Wahl zwischen der Speicherung des Sitzungsstatus in einem clientseitigen Browser-Cookie oder der Verwendung von serverseitigen Speichermechanismen wie shared-memory | memcache | redis bietet.

Es unterstützt serverweite Zwischenspeicherung von aufgelösten Entdeckungsdokumenten und validierten Zugriffstoken.

Im Allgemeinen benötigen Sie einen Autorisierungsserver, der OIDC unterstützt, mit einem registrierten Client, um zu beginnen. Hier können Sie entweder Lösungen wie Keycloak/Gluu oder die von Dritten bereitgestellten verwenden (z.B. Googles https://developers.google.com/identity/protocols/OpenIDConnect; in diesem Fall würden Sie Ihr Google-Konto für die Anmeldung verwenden).

Nachdem Sie die Client-ID/Secret und die OIDC Discovery-URL (siehe https://auth0.com/docs/tutorials/openid-connect-discovery) erhalten haben, können Sie das Plugin aktivieren.

Ein Beispiel für einen curl-Befehl könnte folgendermaßen aussehen:

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

Danach werden Sie vor dem Zugriff auf APIs, die in Kong registriert sind, zur Anmeldeseite des Autorisierungsservers umgeleitet. Dies wird ebenfalls eine SSO-Lösung für alle APIs in Kong bereitstellen.

Es macht Kong zu einem OIDC Relying Party, sodass jede API hinter Kong von dem OIDC-Authentifizierungsschutz profitieren kann, ohne die OIDC-Flows implementieren zu müssen.

In der Praxis verwendet es den Authorization Code Grant (https://auth0.com/docs/api-auth/grant/authorization-code). Wenn ein nicht authentifizierter Benutzer versucht, auf eine API in Kong zuzugreifen, auf der dieses Plugin aktiviert ist, wird der Benutzeragent (Browser) zur Anmeldeseite des AS umgeleitet (Der Standort des AS wird über das Discover-Feld in der Konfiguration festgelegt). Nach erfolgreicher Anmeldung gibt der AS Ihnen einen Zugriffs-Code und leitet Sie zurück zu Kong. Kong verwendet den Zugriffs-Code, um das Zugriffs-, ID- und Aktualisierungstoken zu erhalten.

Die Token werden in einem verschlüsselten Sitzungscookie gespeichert. Der Verschlüsselungsschlüssel ist eine Kombination aus einigen Variablen (Benutzeragent, Remote-IP-Adresse...) und dem session_secret, das beim Aktivieren des Plugins definiert werden kann (siehe https://github.com/nokia/kong-oidc/blob/master/kong/plugins/oidc/schema.lua). Dieses Feld ist optional, wird jedoch dringend empfohlen und muss zufällig sein!

Wenn das Kong-Plugin sieht, dass bereits ein Cookie gesetzt ist, wird es dieses entschlüsseln und die Token validieren. Das Aktualisieren des Zugriffstokens mithilfe des Aktualisierungstokens wird ebenfalls von diesem Plugin behandelt.

Es fügt auch einige Informationen zur Anfrage für den upstream Server hinzu. Es setzt den X-Userinfo-Header mit der Ausgabe vom Userinfo Endpoint (https://connect2id.com/products/server/docs/api/userinfo).

Im Allgemeinen wird der OIDC-Flow und die Logik durch das lua-resty-openidc-Paket implementiert.

Es ist zustandslos, der Kong-Datenspeicher wird nicht verwendet. Wenn Sie dieses Cookie in einem anderen Browser oder von einem anderen Gerät verwenden würden – es wird nicht funktionieren. Um die Token ungültig zu machen, können Sie einen Aufruf an die Root-URL /logout (http:///logout) durchführen. Dies löst einen Aufruf an den OIDC End Session Endpoint aus.

Die ursprünglichen Token werden nicht an den upstream Server gesendet, sondern der X-Userinfo-Header enthält Ansprüche aus dem ID-Token (aber ohne AS-Signaturen).

Nebenbemerkung – Wenn Sie das Plugin in einem dockerisierten Kong verwenden möchten, benötigen Sie

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

In Images können Plugins mit der Umgebungsvariable KONG_PLUGINS aktiviert werden.

KONG_PLUGINS=oidc

Beispiel aus einer Kubernetes-Bereitstellung

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

Ein Kong-Plugin, das eine zusätzliche HTTP POST-Anfrage ermöglicht, bevor die ursprüngliche Anfrage weitergeleitet wird.

kong-external-oauth

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

Ein Kong-Plugin, das es Ihnen ermöglicht, einen externen OAuth 2.0-Anbieter zum Schutz Ihrer API zu verwenden.

$ luarocks install external-oauth

Um Kong darüber zu informieren, dass nach dem neuen Plugin gesucht werden muss, müssen Sie es im benutzerdefinierten 属性 in Ihrer Konfigurationsdatei hinzufügen.

custom_plugins:
    - external-oauth

Sie können das Plugin mit der folgenden Anfrage hinzufügen:

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

| Formularparameter | Standard | Beschreibung | | --- | --- | --- | | name | | Pluginname external-oauth | | config.authorize_url | | Autorisierungs-URL des OAUTH-Anbieters (die, zu der Sie umgeleitet werden, wenn Sie nicht authentifiziert sind) | | config.scope | | OAUTH-Bereich der Autorisierungsanfrage | | config.token_url | | URL des OAUTH-Anbieters zur Anforderung des Zugriffstokens | | config.client_id | | OAUTH-Client-ID | | config.client_secret | | OAUTH-Client-Secret | | config.user_url | | URL des OAUTH-Anbieters, die zur Abrufung von Benutzerdaten und zur Überprüfung der Gültigkeit des Zugriffstokens verwendet wird | | config.user_keys
Optional | username,email | Schlüssel, die aus dem zurückgegebenen JSON-Endpunkt user_url extrahiert werden, sie werden auch in die Header des upstream Servers als X-OAUTH-XXX hinzugefügt | | config.hosted_domain | | Domain, deren Benutzer zur Anmeldung berechtigt sein müssen. Wird ignoriert, wenn leer | | config.email_key | | Schlüssel, der für die gehostete Domain überprüft wird, stammt vom Benutzerinfo-Endpunkt | | config.user_info_periodic_check | 60 | Zeit in Sekunden zwischen Tokenprüfungen |

Zusätzlich zu den user_keys wird ein X-OAUTH-TOKEN-Header mit dem Zugriffstoken des Anbieters hinzugefügt.

Postgres-Backend

pg_hba.conf nach Modifikationen sieht ähnlich aus wie

local   all             postgres                                peer

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" ist nur für Unix-Domain-Socket-Verbindungen
local   all             all                                     md5
# lokal   all             all                                     peer
# IPv4 lokale Verbindungen:
host    all             all             127.0.0.1/32            password
host    all             all             127.0.0.1/32            md5
# IPv6 lokale Verbindungen:
host    all             all             ::1/128                 md5
# Erlauben Sie Replikationsverbindungen von localhost, von einem Benutzer mit den Replikationsberechtigungen.
# local   replication     postgres                                peer
# host    replication     postgres        127.0.0.1/32            md5
# host    replication     postgres        ::1/128                 md5

Dritte Referenzen

Dashboards

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

Deklarative Konfigurationstools

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

Verwendung mit Ansible-Galaxy-Workflow

Wenn Sie die sa-kong-Rolle mit dem Befehl

ansible-galaxy install softasap.sa-kong

installiert haben, ist die Rolle im Ordner library/sa-kong verfügbar.

Bitte passen Sie den Pfad entsprechend an.

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

Urheberrecht und Lizenz

Code ist unter BSD 3-Klausel und MIT-Lizenz dual lizenziert. Wählen Sie die, die Ihnen am besten passt.

Erreichen Sie uns:

Abonnieren Sie die Rollenupdates auf FB

Treten Sie dem Gitter-Diskussionskanal bei Gitter

Entdecken Sie andere Rollen unter http://www.softasap.com/roles/registry_generated.html

Besuchen Sie unseren Blog unter http://www.softasap.com/blog/archive.html