Pods, Services, Ingress & Co.

In Kubernetes Clustern ist der Weg einer eingehenden HTTP/HTTPS-Requests zum Ziel klar definiert:

• Ingress Resources identifizieren aufgrund von Request-Details wie Server-Name oder Pfad die anzusprechenden Services
• Services leiten die empfangen Anfragen nach Art eines internen Load Balancers auf verfügbare Pods weiter
• Anwendungen in Pods (bzw. Containern) verarbeiten schließlich die Anfragen

(Quelle: https://kubernetes.io/docs/concepts/services-networking/ingress/)

Für die Einrichtung einer Ingress Resource sind sog. Ingress Controller zuständig. Oftmals kommt dabei der NGINX Ingress Controller zum Einsatz, der leichtgewichtig und effizient arbeitet. Als Alternative bietet sich der hier vorgestellte Kong Ingress Controller an, welcher im Bereich API & Services über Plugins einigen Mehrwert bietet. Auf einige dieser Plugins soll im Folgenden eingegangen werden.

Der Kong Ingress Controller kann über einen entsprechenden Helm-Chart ohne viel Aufwand installiert werden. Dabei muss im Vorfeld in einer Datei (hier:values.yml) die grundsätzliche Konfiguration festgelegt werden.

Installation Kong Ingress Controller via helm

helm repo add kong https://charts.konghq.com
helm repo update
helm install kong-proxy kong/kong --namespace kong-proxy --create-namespace -f values.yml

Da ein Cluster über mehr als einen Ingress Controller verfügen kann, muss bei der Deklaration von Ingress Resources der Kong Ingress Controller über das AttributingressClassNameadressiert werden:

Konfiguration Ingress mit Kong Controller

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
   [..]
spec:
  ingressClassName: kong

Nach der Installation des Kong Ingress Controllers können zusätzliche Funktionen über Plugins aktiviert werden. Das Vorgehen ist dabei immer identisch:

1. Anlage einer neuen Custom Resource vom Typ (Kind) KongPlugin 
2. Konfiguration des Plugins über ConfigMap
3. Aktivierung des Plugins durch Annotation eines Ingress Rule oder eines Services

Plugin: Correlation ID

Ein eher einfacher Plugin, der dennoch hilfreich sein kann, ist Correlation ID. Der Plugin fügt eingehenden Anfragen und optional den ausgehenden Antworten eine eindeutige, generierte ID als HTTP Header hinzu. So kann der Verlauf einer Anfrage vom Eingang an der Cluster Grenze bis zur Anwendung und wieder zurückverfolgt werden. Der Name des HTTP Headers kann dabei definiert werden. Ist ein gleichnamiger Header bereits in der Anfrage enthalten, wird er nicht überschrieben.

Konfiguration Correlation ID Plugin

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: request-id
  namespace: kong-proxy
config:
  header_name: my-request-id
plugin: correlation-id

Plugin: Rate Limiting

Eindeutig stärker auf APIs & Services zugeschnitten ist Rate Limiting. Über diesen Plugin kann auf vielfältige Art und Weise der Zugriff auf eine Anwendung limitiert werden. Dabei kann über die Konfiguration bestimmt werden, an welcher Eigenschaft das Limit ausgerichtet wird.
Zur Verfügung stehen:

• (remote) IP-Adresse
• (remote) Consumer
• Authentifizierungsdaten
• angesprochener Service
• verwendeter Pfad

Außerdem kann der Betrachtungszeitraum für das Limit präzise eingestellt werden. Das Beispiel verwendet die IP-Adresse. Dies ist auch der Fallback, falls keine der anderen Eigenschaften (Consumer, etc.) ermittelt werden kann. Kommen innerhalb einer Minute fünf Anfragen von der gleichen IP-Adresse, werden weitere Anfragen blockiert.

Konfiguration Rate Limiting Plugin

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rl-by-ip
  namespace: kong-proxy
config:
  minute: 5
  limit_by: ip
  policy: local
plugin: rate-limiting

Damit der Plugin wirksam wird, muss er via Annotation am entsprechenden Service vermerkt werden:

Konfiguration Service mit Rate Limiting

apiVersion:v1
kind: Service
metadata:
  [...]
annotations:
    konghq.com/plugins: rl-by-ip

Plugin: JWT

Deutlich umfangreicher in Funktionsumfang und Konfigurationsaufwand ist der Plugin JWT. Der Plugin prüft, ob ein valides JSON Web Token (JWT) im Request vorhanden ist und verwirft Anfragen mit negativem Ergebnis. So kann der Plugin nachgelagerte Services von ungültigen Anfragen und Angriffsversuchen entlasten.

Consumer und Consumer Secret
Voraussetzung für die Nutzung des Plugins ist das Vorhandensein eines bekannten Consumers (einer Anwendung, welche die lokale API aufruft). Damit der Consumer eindeutig identifiziert werden kann, benötigt er ein entsprechendes Secret. In unserem Falle wird das Secret die erforderlichen Details des JWT beinhalten:

Konfiguration Consumer Secret

apiVersion: v1
kind: Secret
metadata:
  name: myclient
  namespace: kong-proxy
type: Opaque
stringData:
  kongCredType: jwt
  key: myclient
  algorithm: HS256
  secret: 4e4df73799c76b4df844be893ec96154406d36b8c1d1cc143b2a2e69c2671687

Der eigentliche Consumer wird dann wie in Kubernetes üblich, über eine entsprechende Custom Resource angelegt. Das jüngst angelegte Secret wird dabei referenziert (s.credentials):

apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
  name: myclient
  namespace: kong-proxy
  annotations:
      kubernetes.io/ingress.class: kong
username: myclient
credentials:
- myclient

Plugin Konfiguration

Zunächst ist wie immer das Plugin global zu konfigurieren:

Konfiguration JWT Plugin

apiVersion:configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: app-jwt
  namespace: kong-proxy
config:
  secret_is_base64: false
plugin: jwt

Anschließend wird z. B. das Plugin für eine Ingress aktiviert.

Definition Ingress mit JWT Plugin

apiVersion:networking.k8s.io/v1
kind: Ingress
metadata:
  [...]
  annotations:
    konghq.com/plugins: app-jwt

Mit der Aktivierung des Plugins werden alle eingehenden Anfragen abgewiesen (HTTP/1.1 401 Unauthorized), welche

• über kein JWT im HTTP-Header Authorization verfügen oder
• ein JWT mit einer ungültigen / nicht prüfbaren Signatur beinhalten.

Der Kong Ingress Controller stellt eine leichte Alternative zu einem Service Mesh oder der Abbildung nicht-funktionaler Anforderungen in einer Anwendung dar. Viele der Plugins sind bereits in der kostenlosen Community Edition von Kong nutzbar, bei Bedarf können spezifischere Plugins lizensiert oder selbst geschrieben werden.

Die Einrichtung ist dank Helm Charts sehr einfach. Die Konfiguration der Plugins sowie die Integration in Ingress und Services ist geradlinig und verständlich. Für mich stellt der Kong Ingress Controller eine sinnvolle Alternative bzw. Ergänzung zum NGINX Ingress Controller dar. Dies gilt nicht nur für APIs und Services, sondern auch für andere Anwendungen, welche via HTTP/HTTS angesprochen werden.

Referenzen:

Weiterführende Informationen finden sich hinter den folgenden Links:

• Kubernetes Ingress
• Kubernetes Service
• Kong Ingress Controller
• Kong Plugin Hub
• NGINX Ingress Controller

Sie haben Fragen an unsere Expertinnen und Experten? Oder möchten mehr über unsere digitalen Lösungen erfahren?
Kontaktieren Sie uns gerne!