sa-kong

Kong est une couche API évolutive et open source (également connue comme une passerelle API ou middleware API). Kong fonctionne devant n'importe quelle API RESTful et peut être étendu par des plugins, qui ajoutent des fonctionnalités et des services au-delà de la plateforme de base.

Kong a été initialement créé chez Mashape pour sécuriser, gérer et étendre plus de 15 000 API et microservices pour son marché API, qui génère des milliards de requêtes par mois pour plus de 200 000 développeurs. Aujourd'hui, Kong est utilisé dans des déploiements critiques par des organisations grandes et petites.

Évolutif : Kong s'adapte facilement à la charge en ajoutant simplement plus de machines, ce qui signifie que votre plateforme peut gérer pratiquement n'importe quelle charge tout en maintenant une faible latence.

Modulaire : Kong peut être étendu en ajoutant de nouveaux plugins, qui sont facilement configurés via une API d’administration RESTful.

Fonctionne sur n'importe quelle infrastructure : Kong fonctionne partout. Vous pouvez déployer Kong dans le cloud ou sur site, y compris dans des configurations à un ou plusieurs centres de données, et pour des APIs publiques, privées ou sur invitation seulement.

Vous avez probablement entendu que Kong est construit sur Nginx, tirant profit de sa stabilité et de son efficacité. Mais comment cela est-il possible exactement ?

Pour être plus précis, Kong est une application Lua fonctionnant dans Nginx, rendue possible par le module lua-nginx. Au lieu de compiler Nginx avec ce module, Kong est distribué avec OpenResty, qui inclut déjà le module lua-nginx. OpenResty n'est pas une version modifiée de Nginx, mais un ensemble de modules qui étendent ses capacités.

Cela établit les bases d'une architecture pluggable, où des scripts Lua (appelés "plugins") peuvent être activés et exécutés à l'exécution. Pour cette raison, nous considérons Kong comme un exemple parfait d'architecture de microservice : au coeur, il implémente une abstraction de base de données, un routage et une gestion des plugins. Les plugins peuvent résider dans des bases de code distinctes et être injectés n'importe où dans le cycle de vie de la requête, le tout en quelques lignes de code.

Remarque : la version communautaire de Kong ne vient pas avec une interface utilisateur. Vous pourriez envisager certaines interfaces WEB open source, comme https://github.com/PGBI/kong-dashboard ou https://github.com/pantsel/konga/.

D'après notre expérience, https://github.com/PGBI/kong-dashboard utilise des processus de développement et de publication plus robustes, bien que konga ait un aspect plus créatif.

# Installer Kong Dashboard
npm install -g kong-dashboard

# Démarrer Kong Dashboard
kong-dashboard start --kong-url http://kong:8001

# Démarrer Kong Dashboard sur un port personnalisé
kong-dashboard start \
  --kong-url http://kong:8001 \
  --port [port]

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

Avancé :

  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
      }

Notes non triées pour une utilisation future.

Plugins tiers qui pourraient vous intéresser

kong-oidc

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

kong-oidc est un plugin pour Kong qui implémente la fonctionnalité de partie de confiance (RP) OpenID Connect.

Il authentifie les utilisateurs via un fournisseur OpenID Connect en utilisant la découverte OpenID Connect et le profil de client de base (c'est-à-dire le flux de code d'autorisation).

Il maintient des sessions pour les utilisateurs authentifiés en utilisant lua-resty-openidc, offrant ainsi un choix configurable entre le stockage de l'état de session dans un cookie côté client ou l'utilisation de mécanismes de stockage côté serveur partagés : mémoire partagée | memcache | redis.

Il prend en charge la mise en cache à l'échelle du serveur des documents de découverte résolus et des jetons d'accès validés.

En général, vous aurez besoin d'un serveur d'autorisation prenant en charge OIDC avec un client enregistré pour commencer. Vous pouvez utiliser des solutions comme Keycloak/Gluu ou celles fournies par des tiers (par exemple, Google https://developers.google.com/identity/protocols/OpenIDConnect ; dans ce cas, vous utiliseriez votre compte Google pour vous connecter).

Après avoir obtenu l'ID client/le secret et l'URL de découverte OIDC (voir https://auth0.com/docs/tutorials/openid-connect-discovery), vous pouvez activer le plugin.

Un exemple de requête curl pourrait ressembler à :

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

Après cela, avant d'accéder à toute API enregistrée dans Kong, vous serez redirigé vers le serveur d'autorisation pour vous y connecter. Cela fournira également une solution SSO pour toutes les APIs dans Kong.

Cela fait de Kong une partie de confiance OIDC, donc toute API derrière Kong peut profiter de la protection d'authentification OIDC sans implémenter les flux OIDC.

En pratique, il utilise le flux de code d'autorisation (https://auth0.com/docs/api-auth/grant/authorization-code). Si un utilisateur non authentifié essaie d'accéder à une API sur Kong où ce plugin est activé, il sera redirigé vers la page de connexion du serveur d'autorisation (la localisation du serveur d'autorisation est définie via le champ de découverte dans la configuration). Après une connexion réussie, le serveur d'autorisation vous donne un code d'accès et redirige à nouveau vers Kong. Kong utilise le code d'accès pour obtenir les jetons d'accès, d'identité et de rafraîchissement.

Les jetons sont stockés dans un cookie de session chiffré. La clé de chiffrement est une combinaison de quelques variables (agent utilisateur, adresse IP distante, etc.) et le session_secret, qui peut être défini lors de l'activation du plugin (voir https://github.com/nokia/kong-oidc/blob/master/kong/plugins/oidc/schema.lua). Ce champ est facultatif, mais fortement recommandé et doit être aléatoire !

Si le plugin Kong détecte qu'il y a déjà un cookie défini, il le décryptera et validera les jetons. Le rafraîchissement du jeton d'accès à l'aide du jeton de rafraîchissement est également géré par ce plugin.

Il ajoute également des informations à la requête pour le serveur en amont. Il définit l'en-tête X-Userinfo avec la sortie du point de terminaison Userinfo (https://connect2id.com/products/server/docs/api/userinfo).

En général, le flux et la logique OIDC sont implémentés par le package lua-resty-openidc.

Il est sans état, le stockage de données de Kong n'est pas utilisé. Donc, si vous utilisez ce cookie dans un autre navigateur ou sur un autre appareil, cela ne fonctionnera pas. Pour invalider les jetons, vous pouvez faire un appel à l'URL racine /logout (http:///logout). Cela déclenchera un appel au point de terminaison de fin de session OIDC.

Les jetons originaux ne sont pas envoyés au serveur en amont, mais l'en-tête X-Userinfo contient des affirmations du jeton d'identité (mais sans signatures du serveur d'autorisation).

Remarque - si vous envisagez d'utiliser le plugin dans un Kong conteneurisé, vous aurez besoin de :

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

Dans l'image, les plugins peuvent être activés en utilisant la variable d'environnement KONG_PLUGINS.

KONG_PLUGINS=oidc

Exemple d'un déploiement 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

Un plugin Kong qui permet une requête HTTP POST supplémentaire avant de proxy l'original.

kong-external-oauth

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

Un plugin Kong, qui vous permet d'utiliser un fournisseur Oauth 2.0 externe pour protéger votre API.

$ luarocks install external-oauth

Pour que Kong sache qu’il doit rechercher le nouveau plugin, vous devrez l'ajouter à la propriété custom_plugins dans votre fichier de configuration.

custom_plugins:
    - external-oauth

Vous pouvez ajouter le plugin avec la requête suivante :

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

Paramètre de formulaire	défaut	description
name		nom du plugin external-oauth
config.authorize_url		URL d'autorisation du fournisseur OAUTH (celle vers laquelle vous serez redirigé lorsque vous n'êtes pas authentifié)
config.scope		portée OAUTH de la requête d'autorisation
config.token_url		URL du fournisseur Oauth pour demander le jeton d'accès
config.client_id		ID Client OAUTH
config.client_secret		Clé Secrète OAUTH
config.user_url		URL du fournisseur d'oauth utilisée pour récupérer les informations utilisateur et aussi vérifier la validité du jeton d'accès
config.user_keys Optionnel	username,email	clés à extraire du json retourné par l'endpoint user_url, elles seront également ajoutées aux en-têtes du serveur en amont en tant que X-OAUTH-XXX
config.hosted_domain		domaine dont les utilisateurs doivent faire partie pour se connecter. Ignoré si vide
config.email_key		clé à vérifier pour le domaine hébergé, tirée de l'endpoint d'informations utilisateur
config.user_info_periodic_check	60	temps en secondes entre les vérifications de jeton

En plus des user_keys, un en-tête X-OAUTH-TOKEN sera ajouté avec le jeton d'accès du fournisseur.

Backend Postgres

pg_hba.conf après modifications ressemblera à :

local   all             postgres                                peer

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" est uniquement pour les connexions par socket Unix
local   all             all                                     md5
# local   all             all                                     peer
# Connexions locales IPv4 :
host    all             all             127.0.0.1/32            password
host    all             all             127.0.0.1/32            md5
# Connexions locales IPv6 :
host    all             all             ::1/128                 md5
# Autoriser les connexions de réplication depuis localhost, par un utilisateur ayant le
# privilège de réplication.
#local   replication     postgres                                peer
#host    replication     postgres        127.0.0.1/32            md5
#host    replication     postgres        ::1/128                 md5

Références tierces

Dashboards

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

Outils de configuration déclarative

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

Utilisation avec le workflow Ansible Galaxy

Si vous avez installé le rôle sa-kong en utilisant la commande :

ansible-galaxy install softasap.sa-kong

le rôle sera disponible dans le dossier library/sa-kong.

Veuillez ajuster le chemin en conséquence.

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

Droits d'auteur et licence

Le code est sous double licence BSD 3 clauses et MIT License. Choisissez celui qui vous convient le mieux.

Contactez-nous :

Abonnez-vous pour des mises à jour de rôles sur FB

Rejoignez le canal de discussion Gitter sur Gitter

Découvrez d'autres rôles sur http://www.softasap.com/roles/registry_generated.html

Visitez notre blog à http://www.softasap.com/blog/archive.html