Vorgangs- und Konfigurationsreferenz für Edge Microgateway

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Edge Microgateway Version 3.1.5 und höher

In diesem Thema wird erläutert, wie Sie Edge Microgateway verwalten und konfigurieren.

Edge Microgateway aktualisieren, wenn Sie eine Internetverbindung haben

In diesem Abschnitt wird erläutert, wie Sie eine vorhandene Installation von Edge Microgateway aktualisieren. Falls Sie ohne Internetverbindung arbeiten, lesen Sie Kann ich Edge Microgateway ohne Internetverbindung installieren?

Apigee empfiehlt, Ihre vorhandene Konfiguration mit die neue Version vor dem Upgrade der Produktionsumgebung.

1. Führen Sie den folgenden npm-Befehl aus, um ein Upgrade auf die neueste Version von Edge durchzuführen Microgateway:

   npm upgrade edgemicro -g

   Für ein Upgrade auf eine bestimmte Version von Edge Microgateway müssen Sie die Version Nummer im Upgrade-Befehl ein. Wenn Sie keine Versionsnummer angeben, wird die neueste Version installiert. Wenn Sie beispielsweise ein Upgrade auf Version 3.1.0 durchführen möchten, verwenden Sie die Methode folgenden Befehl:

   npm upgrade edgemicro@3.1.0 -g

2. Prüfen Sie die Versionsnummer. Wenn Sie beispielsweise Version 3.1.0 installiert haben:

   edgemicro --version
   current nodejs version is v12.5.0
   current edgemicro version is 3.1.0
       

3. Führen Sie abschließend ein Upgrade auf die neueste Version des Proxys edgemicro-auth durch:

   edgemicro upgradeauth -o $ORG -e $ENV -u $USERNAME

Konfigurationsänderungen vornehmen

Zu den Konfigurationsdateien, die Sie kennen sollten, gehören:

• Standardsystemkonfigurationsdatei
• Standardkonfigurationsdatei für eine neu initialisierte Edge Microgateway-Instanz
• Dynamische Konfigurationsdatei für ausgeführte Instanzen

In diesem Abschnitt werden diese Dateien erläutert und Sie erfahren, was Sie wissen müssen, wenn Sie sie ändern.

Standardsystemkonfiguration Datei

Wenn Sie Edge Microgateway installieren, wird hier eine Standardsystemkonfigurationsdatei abgelegt:

prefix/lib/node_modules/edgemicro/config/default.yaml

Dabei ist prefix das Präfixverzeichnis npm. Weitere Informationen finden Sie unter . Wo ist Edge Microgateway installiert, wenn Sie dieses Verzeichnis nicht finden können.

Wenn Sie die Systemkonfigurationsdatei ändern, müssen Sie Edge neu initialisieren, neu konfigurieren und neu starten Microgateway:

edgemicro init
edgemicro configure [params]
edgemicro start [params]

Standardkonfigurationsdatei für neu initialisierte Edge Microgateway-Instanzen

Wenn Sie edgemicro init ausführen, ist die Systemkonfigurationsdatei oben), default.yaml, im Verzeichnis ~/.edgemicro platziert.

Wenn Sie die Konfigurationsdatei in ~/.edgemicro ändern, müssen Sie sie neu konfigurieren und neu starten Edge Microgateway:

edgemicro stop
edgemicro configure [params]
edgemicro start [params]

Dynamisch Konfigurationsdatei für ausgeführte Instanzen

Wenn Sie edgemicro configure [params] ausführen, wird eine dynamische Konfigurationsdatei wird in ~/.edgemicro erstellt. Der Name der Datei lautet Muster: org-env-config.yaml, wobei org und env sind Ihre Apigee Edge-Organisation und Ihre Umgebungsnamen. Sie können diese Datei zur Konfiguration und sie anschließend ohne Ausfallzeit neu laden. Wenn Sie beispielsweise ein Plug-in hinzufügen und konfigurieren, können Sie die Konfiguration aktualisieren, ohne dass es zu Ausfallzeiten kommt, wie unten erläutert.

Wenn Edge Microgateway ausgeführt wird (Option ohne Ausfallzeiten):

1. Aktualisieren Sie die Edge Microgateway-Konfiguration:

   edgemicro reload -o $ORG -e $ENV -k $KEY -s $SECRET

   Wobei:

   • $ORG ist der Name Ihrer Edge-Organisation (Sie müssen eine Organisation sein) Administrator).
   • $ENV ist eine Umgebung in Ihrer Organisation, z. B. „test“ oder „prod“).
   • $KEY ist der zuvor vom Befehl „configure“ zurückgegebene Schlüssel.
   • $SECRET ist der zuvor vom Befehl „configure“ zurückgegebene Schlüssel.

   Beispiel:

   edgemicro reload -o docs -e test -k 701e70ee718ce6dc188...78b6181d000723 \
     -s 05c14356e42ed1...4e34ab0cc824

Wenn Edge Microgateway beendet ist:

1. Starten Sie Edge Microgateway neu:

   edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET

   Wobei:

   • $ORG ist der Name Ihrer Edge-Organisation (Sie müssen eine Organisation sein) Administrator).
   • $ENV ist eine Umgebung in Ihrer Organisation, z. B. „test“ oder „prod“).
   • $KEY ist der zuvor vom Befehl „configure“ zurückgegebene Schlüssel.
   • $SECRET ist der zuvor vom Befehl „configure“ zurückgegebene Schlüssel.

   Beispiel:

   edgemicro start -o docs -e test -k 701e70ee718ce...b6181d000723 \
     -s 05c1435...e34ab0cc824

Hier ist eine Beispielkonfigurationsdatei. Weitere Informationen zu den Einstellungen von Konfigurationsdateien finden Sie in der Konfigurationsreferenz für Edge Microgateway.

edge_config:
  bootstrap: >-
    https://edgemicroservices-us-east-1.apigee.net/edgemicro/bootstrap/organization/docs/environment/test
  jwt_public_key: 'https://docs-test.apigee.net/edgemicro-auth/publicKey'
  managementUri: 'https://api.enterprise.apigee.com'
  vaultName: microgateway
  authUri: 'https://%s-%s.apigee.net/edgemicro-auth'
  baseUri: >-
    https://edgemicroservices.apigee.net/edgemicro/%s/organization/%s/environment/%s
  bootstrapMessage: Please copy the following property to the edge micro agent config
  keySecretMessage: The following credentials are required to start edge micro
  products: 'https://docs-test.apigee.net/edgemicro-auth/products'
edgemicro:
  port: 8000
  max_connections: 1000
  max_connections_hard: 5000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - oauth
headers:
  x-forwarded-for: true
  x-forwarded-host: true
  x-request-id: true
  x-response-time: true
  via: true
oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  verify_api_key_url: 'https://docs-test.apigee.net/edgemicro-auth/verifyApiKey'
analytics:
  uri: >-
    https://edgemicroservices-us-east-1.apigee.net/edgemicro/axpublisher/organization/docs/environment/test

Umgebungsvariablen festlegen

Die Befehlszeilenbefehle, die Werte für Ihre Edge-Organisation und und der Schlüssel und das Secret, die zum Starten von Edge Microgateway erforderlich sind, in diesen Umgebungsvariablen:

• EDGEMICRO_ORG
• EDGEMICRO_ENV
• EDGEMICRO_KEY
• EDGEMICRO_SECRET

Das Festlegen dieser Variablen ist optional. Wenn Sie diese festlegen, müssen Sie ihre Werte nicht angeben. wenn Sie Edge Microgateway über die Befehlszeile konfigurieren und starten.

SSL auf dem Edge Microgateway konfigurieren Server

In den folgenden Videos erfahren Sie, wie Sie TLS in Apigee Edge Microgateway konfigurieren:

Sie können den Microgateway-Server für die Verwendung von SSL konfigurieren. Wenn SSL beispielsweise konfiguriert ist, kann APIs über Edge Microgateway mit dem wie hier gezeigt:

https://localhost:8000/myapi

So konfigurieren Sie SSL auf dem Microgateway-Server:

1. Generieren oder erhalten Sie ein SSL-Zertifikat und den Schlüssel mit dem Dienstprogramm openssl oder einer anderen Methode.
2. Fügen Sie der Edge Microgateway-Konfigurationsdatei das Attribut edgemicro:ssl hinzu. Eine vollständige finden Sie in der Tabelle unten. Beispiel:
   

   edgemicro:
     ssl:
      key: <absolute path to the SSL key file>
      cert: <absolute path to the SSL cert file>
      passphrase: admin123 #option added in v2.2.2
      rejectUnauthorized: true #option added in v2.2.2
      requestCert: true

3. Starten Sie Edge Microgateway neu. Befolgen Sie die Schritte in Konfigurationsänderungen vornehmen, je nachdem, Konfigurationsdatei, die Sie bearbeitet haben: die Standarddatei oder die Laufzeit-Konfigurationsdatei.

Hier sehen Sie ein Beispiel für den Abschnitt edgemicro der Konfigurationsdatei mit SSL konfiguriert:

edgemicro:
  port: 8000
  max_connections: 1000
  max_connections_hard: 5000
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - oauth
  ssl:
    key: /MyHome/SSL/em-ssl-keys/server.key
    cert: /MyHome/SSL/em-ssl-keys/server.crt
    passphrase: admin123 #option added in v2.2.2
    rejectUnauthorized: true #option added in v2.2.2

Im Folgenden finden Sie eine Liste aller unterstützten Serveroptionen:

Client-SSL/TLS-Optionen verwenden

Sie können Edge Microgateway beim Herstellen einer Verbindung zum Ziel als TLS- oder SSL-Client konfigurieren Endpunkten. Verwenden Sie in der Microgateway-Konfigurationsdatei das Element "targets", um SSL/TLS festzulegen. Optionen.

Dieses Beispiel enthält Einstellungen, die auf alle Hosts angewendet werden:

edgemicro:
...
targets:
  ssl:
    client:
      key: /Users/jdoe/nodecellar/twowayssl/ssl/client.key
      cert: /Users/jdoe/nodecellar/twowayssl/ssl/ca.crt
      passphrase: admin123
      rejectUnauthorized: true

In diesem Beispiel werden die Einstellungen nur auf den angegebenen Host angewendet:

edgemicro:
...
targets:
  - host: 'myserver.example.com'
    ssl:
      client:
        key: /Users/myname/twowayssl/ssl/client.key
        cert: /Users/myname/twowayssl/ssl/ca.crt
        passphrase: admin123
        rejectUnauthorized: true

Hier ist ein Beispiel für TLS:

edgemicro:
...
targets:
  - host: 'myserver.example.com'
    tls:
      client:
        pfx: /Users/myname/twowayssl/ssl/client.pfx
        passphrase: admin123
        rejectUnauthorized: true

Hier ist eine Liste aller unterstützten Clientoptionen:

Edgemicro-auth-Proxy anpassen

Standardmäßig verwendet Edge Microgateway für die OAuth2-Authentifizierung einen Proxy, der auf Apigee Edge bereitgestellt ist. Dieser Proxy wird bereitgestellt, wenn Sie edgemicro configure zum ersten Mal ausführen. Sie können Die Standardkonfiguration dieses Proxys, um Unterstützung für benutzerdefinierte Anforderungen an ein JSON Web Token hinzuzufügen (JWT), konfigurieren den Ablauf von Tokens und generieren Aktualisierungstokens. Weitere Informationen finden Sie auf der Seite edgemicro-auth in GitHub.

Benutzerdefinierten Authentifizierungsdienst verwenden

Standardmäßig verwendet Edge Microgateway für die OAuth2-Authentifizierung einen Proxy, der auf Apigee Edge bereitgestellt ist. Dieser Proxy wird bereitgestellt, wenn Sie edgemicro configure zum ersten Mal ausführen. Standardmäßig Die URL des Proxys wird in der Edge Microgateway-Konfigurationsdatei so angegeben:

authUri: https://myorg-myenv.apigee.net/edgemicro-auth

Wenn Sie Ihren eigenen benutzerdefinierten Dienst für die Authentifizierung verwenden möchten, ändern Sie den authUri-Wert in der Konfigurationsdatei, um auf Ihren Dienst zu verweisen. Zum Beispiel haben Sie möglicherweise ein Dienst, der LDAP zur Identitätsüberprüfung verwendet.

Protokolldateien verwalten

Edge Microgateway protokolliert Informationen über jede Anfrage und Antwort. Protokolldateien bieten nützliche Informationen zur Fehlerbehebung.

Wo werden Protokolldateien gespeichert?

Standardmäßig werden Protokolldateien in /var/tmp gespeichert.

So ändern Sie das Standardprotokoll Dateiverzeichnis

Das Verzeichnis, in dem die Protokolldateien gespeichert sind, wird in der Edge Microgateway-Konfiguration angegeben -Datei. Siehe auch Konfiguration vornehmen Änderungen.

edgemicro:
  home: ../gateway
  port: 8000
  max_connections: -1
  max_connections_hard: -1
  logging:
    level: info
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

Ändern Sie den Wert dir, um ein anderes Protokolldateiverzeichnis anzugeben.

Protokolle an die Konsole senden

Sie können das Logging so konfigurieren, dass Loginformationen an die Standardausgabe und nicht an eine Protokolldatei. Legen Sie das Flag to_console so auf „true“ fest:

edgemicro:
  logging:
    to_console: true

Bei dieser Einstellung werden Logs an den Standard-Ausgang gesendet. Derzeit können Sie Logs nicht an beide senden stdout und in eine Protokolldatei.

Logging-Ebene festlegen

Sie können die Protokollebenen info, warn und error Die Informationsebene wird empfohlen. Es protokolliert alle API-Anfragen und -Antworten, Dies ist die Standardeinstellung.

Protokollintervalle ändern

Sie können diese Intervalle in der Edge Microgateway-Konfigurationsdatei konfigurieren. Weitere Informationen finden Sie unter Konfigurationsänderungen vornehmen.

Folgende konfigurierbare Attribute sind verfügbar:

• stats_log_interval: (Standard: 60) Intervall in Sekunden, wenn die Statistiken wird in die API-Protokolldatei geschrieben.
• rotate_interval: (Standard: 24) Intervall in Stunden, in dem die Protokolldateien gespeichert werden gedreht. Beispiel:

edgemicro:
  home: ../gateway
  port: 8000
  max_connections: -1
  max_connections_hard: -1
  logging:
    level: info
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

Gute Vorgehensweisen bei der Wartung von Logdateien

Da sich Protokolldatei-Daten im Laufe der Zeit ansammeln, empfiehlt Apigee die folgende Vorgehensweise: Best Practices:

• Da Protokolldateien sehr groß werden können, sollten Sie sicherstellen, dass das Protokolldateiverzeichnis ausreichend Speicherplatz. Weitere Informationen finden Sie in den folgenden Abschnitten Speicherort der Protokolldateien und So ändern Sie die Standardprotokolldatei. -Verzeichnis.
• Löschen oder verschieben Sie Protokolldateien mindestens einmal pro Woche in ein separates Archivverzeichnis.
• Wenn Sie Logs löschen möchten, können Sie den Befehl edgemicro log -c über die Befehlszeile verwenden. um ältere Logs zu entfernen (bereinigt).

Namenskonvention für Protokolldateien

Jede Edge Microgateway-Instanz erzeugt drei Typen von Protokolldateien:

• api - Protokolliert alle Anfragen und Antworten, die über Edge fließen. Microgateway. API-Zähler (Statistiken) und -Fehler werden ebenfalls in dieser Datei protokolliert.
• err – Protokolliert alles, was an stderr gesendet wurde.
• out – Protokolliert alles, was an stdout gesendet wurde.

Dies ist die Namenskonvention:

edgemicro-<Host Name>-<Instance ID>-<Log Type>.log

Beispiel:

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log
edgemicro-mymachine-local-MTQzNTg1NDMODAyMQ-err.log
edgemicro-mymachine-local-mtqzntgndmxodaymq-out.log

Inhalt der Protokolldatei

Hinzugefügt in: v2.3.3

Standardmäßig lässt der Logging-Dienst die JSON-Daten heruntergeladener Proxys, Produkte und JSON-Dateien weg. Webtoken (JWT). Wenn Sie diese Objekte an die Protokolldateien ausgeben möchten, legen Sie den Parameter DEBUG=*, wenn Sie Edge Microgateway starten. Beispiel:

DEBUG=* edgemicro start -o docs -e test -k abc123 -s xyz456

Inhalt von „api“ Protokolldatei

Die API Protokolldatei enthält detaillierte Informationen zum Fluss von Anfragen und Antworten. über Edge Microgateway. Die API Protokolldateien haben den folgenden Namen:

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

Für jede Anfrage an Edge Microgateway werden vier Ereignisse in der „API“ erfasst Protokoll Datei:

• Eingehende Anfrage vom Client
• Ausgehende Anfrage an das Ziel
• Eingehende Antwort des Ziels
• Ausgehende Antwort an den Client

Jeder dieser Einträge wird in Kurzschreibweise dargestellt, damit das Protokoll Dateien kompakter sein. Hier sind vier Beispieleinträge, die jedes der vier Ereignisse darstellen. Im Protokoll Datei sehen, sehen sie so aus (die Zeilennummern dienen nur als Referenz im Dokument, sie werden nicht in der Protokolldatei).

(1) 1436403888651 info req m=GET, u=/, h=localhost:8000, r=::1:59715, i=0
(2) 1436403888665 info treq m=GET, u=/, h=127.0.0.18080, i=0
(3) 1436403888672 info tres s=200, d=7, i=0
(4) 1436403888676 info res s=200, d=11, i=0

Sehen wir sie uns im Einzelnen an:

1. Beispiel für eine eingehende Anfrage vom Client:

1436403888651 info req m=GET, u=/, h=localhost:8000, r=::1:59715, i=0

• 1436403888651 – Unix-Datumsstempel
• info: Hängt vom Kontext ab. Das können Informationen, Warnungen oder Fehler sein. abhängig von der Logebene. Kann Statistiken für einen Statistikeintrag sein, bei Warnungen warnen oder für Fehler.
• req: Kennzeichnet das Ereignis. In diesem Fall muss die Anfrage vom Client.
• m – Das in der Anfrage verwendete HTTP-Verb.
• u – Der Teil der URL nach dem Basispfad.
• h – Die Host- und Portnummer für das Edge Microgateway. Zuhören.
• r – Remote-Host und Port, an den der Client anfordert entstand.
• i – Die Anfrage-ID. Alle vier Ereigniseinträge haben dieselbe ID. Jedes -Anfrage eine eindeutige Anfrage-ID zugewiesen. Das Korrelieren von Protokolleinträgen nach Anfrage-ID kann wertvolle Einblicke in die Latenz des Ziels.
• d – Dauer in Millisekunden seit dem Empfang der Anfrage durch Edge Microgateway. Im obigen Beispiel ist die Antwort des Ziels auf Anfrage 0 eingegangen nach 7 Millisekunden (Zeile 3) und die Antwort wurde nach weiteren 4 Millisekunden (Zeile 4). Mit anderen Worten, die gesamte Anfragelatenz betrug 11 Millisekunden, welche 7 Millisekunden vom Ziel und 4 Millisekunden vom Edge Microgateway erfasst wurden selbst.

2. Beispiel einer ausgehenden Anfrage an das Ziel:

1436403888665 info treq m=GET, u=/, h=127.0.0.1:8080, i=0

• 1436403888651 – Unix-Datumsstempel
• info: Hängt vom Kontext ab. Das können Informationen, Warnungen oder Fehler sein. abhängig von der Logebene. Kann Statistiken für einen Statistikeintrag sein, bei Warnungen warnen oder für Fehler.
• treq: Kennzeichnet das Ereignis. In diesem Fall ist dies die Zielanfrage.
• m – HTTP-Verb, das in der Zielanfrage verwendet wird.
• u – Der Teil der URL nach dem Basispfad.
• h – Host und Portnummer des Back-End-Ziels.
• i – Die ID des Logeintrags. Diese wird für alle vier Veranstaltungseinträge freigegeben. ID.

3. Beispiel einer eingehenden Antwort des Ziels

1436403888672 info tres s=200, d=7, i=0

1436403888651 – Unix-Datumsstempel

• info: Hängt vom Kontext ab. Das können Informationen, Warnungen oder Fehler sein. abhängig von der Logebene. Kann Statistiken für einen Statistikeintrag sein, bei Warnungen warnen oder für Fehler.
• tres: Kennzeichnet das Ereignis. in diesem Fall die Zielantwort.
• s – HTTP-Antwortstatus.
• d – Dauer in Millisekunden Die für den API-Aufruf vom das Ziel zu erreichen.
• i – Die ID des Logeintrags. Diese wird für alle vier Veranstaltungseinträge freigegeben. ID.

4. Beispiel für eine ausgehende Antwort an den Kunden

1436403888676 info res s=200, d=11, i=0

1436403888651 – Unix-Datumsstempel

• info: Hängt vom Kontext ab. Das können Informationen, Warnungen oder Fehler sein. abhängig von der Logebene. Kann Statistiken für einen Statistikeintrag sein, bei Warnungen warnen oder für Fehler.
• res: Kennzeichnet das Ereignis. In diesem Fall wird die Antwort auf die Client.
• s – HTTP-Antwortstatus.
• d – Dauer in Millisekunden Dies ist die Gesamtzeit, die durch den API-Aufruf, einschließlich der von der Ziel-API verbrauchten Zeit und der von Edge benötigten Zeit Microgateway selbst.
• i – Die ID des Logeintrags. Diese wird für alle vier Veranstaltungseinträge freigegeben. ID.

Zeitplan für Logdateien

Die Protokolldateien werden in dem durch rotate_interval angegebenen Intervall rotiert. Konfigurationsattribut. Die Einträge werden weiterhin dem bis das Rotationsintervall abläuft. Jedes Mal, wenn Edge Microgateway erhält er eine neue UID und erstellt einen neuen Satz von Protokolldateien mit dieser UID. Siehe auch Gute Pflege der Protokolldateien .

Fehlermeldungen

Einige Logeinträge enthalten Fehlermeldungen. Um zu ermitteln, wo und warum die Fehler auftreten, sehen Sie sich den Edge Microgateway-Fehler Referenz.

Edge Microgateway-Konfigurationsreferenz

Standort des Konfigurationsdatei

Die in diesem Abschnitt beschriebenen Konfigurationsattribute befinden sich im Edge Microgateway. Konfigurationsdatei. Siehe auch Konfiguration vornehmen Änderungen.

Edge_config-Attribute

Mit diesen Einstellungen wird die Interaktion zwischen der Edge Microgateway-Instanz und Apigee Edge

• bootstrap: (Standardeinstellung: keine) Eine URL, die auf einen Edge verweist. Microgateway-spezifischer Dienst, der auf Apigee Edge ausgeführt wird. Edge Microgateway verwendet diesen Dienst, um mit Apigee Edge kommunizieren können. Diese URL wird zurückgegeben, wenn Sie den Befehl zum Generieren des Paar aus öffentlichem/privatem Schlüssel: edgemicro genkeys. Weitere Informationen finden Sie im Abschnitt Einrichtung und Edge Microgateway konfigurieren.
• jwt_public_key: (Standardeinstellung: none) Eine URL, die auf das Edge Microgateway verweist Proxy, der in Apigee Edge bereitgestellt wird. Dieser Proxy dient als Authentifizierungsendpunkt für Ausstellen signierter Zugriffstokens an Clients Diese URL wird zurückgegeben, wenn Sie den Befehl für Stellen Sie den Proxy edgemicro configure bereit. Weitere Informationen finden Sie im Abschnitt Einrichtung und Edge Microgateway konfigurieren.
• quotaUri: Diese Konfiguration festlegen Property, wenn Sie Kontingente über den edgemicro-auth-Proxy verwalten möchten, der die in Ihrer Organisation bereitgestellt wurden. Wenn diese Eigenschaft nicht festgelegt ist, ist der Kontingentendpunkt standardmäßig der interne Edge Microgateway-Endpunkt.

  edge_config:
    quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
  

Edgemicro-Attribute

Mit diesen Einstellungen wird der Edge Microgateway-Prozess konfiguriert.

• port: (Standard: 8000) Die Portnummer, auf der das Edge Microgateway verwendet wird. Prozessüberwachung.
• max_connections: (Standard: -1) Gibt die maximale Anzahl von Verbindungen an gleichzeitig eingehende Verbindungen, die Edge Microgateway empfangen kann. Wenn diese Nummer gleich wird der folgende Status zurückgegeben:
  
  res.statusCode = 429; // Too many requests
  
• max_connections_hard: (Standard: -1) Die maximale Anzahl gleichzeitiger Verbindungen. Anforderungen, die Edge Microgateway empfangen kann, bevor die Verbindung unterbrochen wird. Diese Einstellung soll Denial-of-Service-Angriffe verhindern. Legen Sie dafür eine Zahl fest, die größer als max_connections.
• logging: <ph type="x-smartling-placeholder">
  </ph>
  • level: (Standard: Fehler) <ph type="x-smartling-placeholder">
    </ph>
    • Info - Protokolliert alle Anfragen und Antworten, die durch eine Edge Microgateway-Instanz
    • warn: protokolliert nur Warnmeldungen.
    • error – protokolliert nur Fehlermeldungen.
  • dir: (Standard: /var/tmp) Das Verzeichnis, in dem sich die Protokolldateien befinden. gespeichert sind.
  • stats_log_interval: (Standard: 60) Intervall in Sekunden, wenn die Statistiken wird in die API-Protokolldatei geschrieben.
  • rotate_interval: (Standard: 24) Intervall in Stunden, in dem die Protokolldateien gespeichert werden gedreht.

• plugins: Plug-ins bieten Edge Microgateway Funktionen. Weitere Informationen Informationen zur Entwicklung von Plug-ins finden Sie unter Benutzerdefinierte Plug-ins entwickeln.

• dir: Ein relativer Pfad vom ./gateway-Verzeichnis zum ./plugins-Verzeichnis oder einen absoluten Pfad angeben.
• Sequenz: Eine Liste der Plug-in-Module, die dem Edge Microgateway hinzugefügt werden Instanz. Die Module werden in der hier angegebenen Reihenfolge ausgeführt.

• debug: Fügt dem Edge Microgateway-Prozess das Remote-Debugging hinzu.
  • port: Die Portnummer, die überwacht werden soll. Richten Sie beispielsweise Ihren IDE-Debugger ein. um diesen Port zu überwachen.
  • args: Argumente für den Debug-Prozess. Beispiel: args --nolazy
    
• config_change_poll_interval: (Standard: 600 Sekunden) Edge Microgateway lädt regelmäßig eine neue Konfiguration und führt eine Aktualisierung durch, falls sich etwas geändert hat. Das Polling erfasst alle in Edge vorgenommenen Änderungen (Änderungen an Produkten, Microgateway-fähigen Proxys usw.) sowie Änderungen an der lokalen Konfigurationsdatei.
  
• disable_config_poll_interval: (Standard: „false“), festgelegt auf true, um das automatische Änderungsabfrage zu deaktivieren.
• request_timeout: Legt ein Zeitlimit für Zielanfragen fest. Das Zeitlimit wird eingestellt in Sekunden. Wenn eine Zeitüberschreitung auftritt, antwortet Edge Microgateway mit dem Statuscode 504. (Hinzugefügt v2.4.x)
• keep_alive_timeout: Mit dieser Eigenschaft können Sie das Edge Microgateway festlegen. Timeout (in Millisekunden). (Standardeinstellung: 5 Sekunden) (Hinzugefügt v3.0.6)
• headers_timeout: Dieses Attribut begrenzt den Zeitraum (in Millisekunden). wartet der HTTP-Parser auf den Empfang des vollständige HTTP-Header.

  Beispiel:

  edgemicro:
    keep_alive_timeout: 6000
    headers_timeout: 12000

  Der Parameter legt intern die Node.js-Datei fest. Server.headersTimeout bei Anfragen ändern. (Standardeinstellung: 5 Sekunden länger als die mit edgemicro.keep_alive_timeout festgelegte Zeit. Diese Standardeinstellung verhindert, dass Load-Balancer oder Proxys die Verbindung fälschlicherweise unterbrechen.) (Hinzugefügt v3.1.1)

• noRuleMatchAction: (String) Die auszuführende Aktion (Zugriff erlauben oder ablehnen), wenn die Die im Plug-in accesscontrol angegebene Übereinstimmungsregel wird nicht aufgelöst (keine Übereinstimmung). Gültige Werte: ALLOW oder DENY Standard: ALLOW (Hinzugefügt: v3.1.7)
• enableAnalytics:: (Standardeinstellung: true) Setzen Sie das Attribut auf enableAnalytics:, um um das Analyse-Plug-in zu verhindern, geladen werden kann. In diesem Fall werden keine Apigee Edge-Analysen aufgerufen. Wenn dieser Wert auf true gesetzt ist oder wenn nicht angegeben ist, funktioniert das Analyse-Plug-in wie gewohnt. Weitere Informationen finden Sie unter edgemicro-Attribute für Details. (Version 3.1.8 hinzugefügt).

  Beispiel:

  edgemicro
    enableAnalytics=false|true

Headerattribute

Mit diesen Einstellungen wird festgelegt, wie bestimmte HTTP-Header behandelt werden.

• x-forwarded-for: (Standardeinstellung: true) Auf „false“ setzen, um zu verhindern x-forwarded-for-Header, die an das Ziel übergeben werden sollen. Wenn ein x-forwarded-for-Header sich in der Anfrage befindet, wird sein Wert auf den Wert der Client-IP in Edge Analytics festgelegt.
• x-forwarded-host: (Standardeinstellung: true) Auf „false“ setzen, um zu verhindern x-forwarded-host-Header, die an das Ziel übergeben werden sollen.
• x-request-id: (Standard: true) Auf „false“ setzen, um zu verhindern x-request-id-Header, die an das Ziel übergeben werden sollen.
• x-response-time: (Standard: true) Auf „false“ setzen, um zu verhindern x-response-time-Header, die an das Ziel übergeben werden sollen.
• via: (Standard: true) Auf „false“ setzen, um zu verhindern, dass Via-Header in an das Ziel übergeben wird.

OAuth-Attribute

Diese Einstellungen konfigurieren, wie die Clientauthentifizierung von Edge Microgateway erzwungen wird.

• allowNoAuthorization (Standardeinstellung: false) Wenn die Richtlinie auf „true“ gesetzt ist, werden API-Aufrufe Edge Microgateway ohne Autorisierungsheader passieren darf. Setzen auf false, um einen Autorisierungsheader anzufordern (Standardeinstellung).
• allowInvalidAuthorization: (Standardeinstellung: false) Wenn die Richtlinie auf „true“ gesetzt ist, werden API-Aufrufe übergeben werden, wenn das im Autorisierungsheader übergebene Token ungültig oder abgelaufen ist. Festlegen auf „false“, um gültige Tokens anzufordern (Standardeinstellung).
• authorization-header: (Standard: Authorization: Bearer) Dieser Header wird verwendet, um das Zugriffstoken an Edge Microgateway senden. Sie können die Standardeinstellung ändern, Das Ziel muss den Autorisierungsheader für einen anderen Zweck verwenden.
• api-key-header: (Standard: x-api-key) Name des Headers oder der Abfrage Parameter zum Übergeben eines API-Schlüssels an Edge Microgateway. Siehe auch Verwendung von API-Schlüssel
• keep-authorization-header: (Standard: false) Wenn der Wert auf „true“ gesetzt ist, wird der Autorisierungsheader die in der Anfrage gesendet wurden, an das Ziel übergeben (wird beibehalten).
• allowOAuthOnly: Wenn die Richtlinie auf "true" gesetzt ist, muss jede API eine Autorisierung enthalten. mit einem Bearer Access Token. Sie können festlegen, dass nur das OAuth-Sicherheitsmodell Aufrechterhaltung der Abwärtskompatibilität). (Hinzugefügt 2.4.x)
• allowAPIKeyOnly: Wenn die Richtlinie auf "true" gesetzt ist, muss jede API einen x-api-key (oder einen benutzerdefinierten Speicherort) mit einem API-Schlüssel.Erlaubt Ihnen, nur das Sicherheitsmodell des API-Schlüssels (unter Aufrechterhaltung der Abwärtskompatibilität). (Hinzugefügt 2.4.x)
• gracePeriod: Dieser Parameter verhindert Fehler aufgrund geringfügiger Abweichungen zwischen Ihrer Systemuhr und den Zeiten für „Nicht vor“ (nbf) oder „Ausgestellt um“ (iat) das im JWT-Autorisierungstoken angegeben ist. Legen Sie für diesen Parameter die zulässige Anzahl von Sekunden fest auf solche Abweichungen hin. (Hinzugefügt 2.5.7)

Plug-in-spezifisch Attribute

Einzelheiten zu den konfigurierbaren Attributen für die einzelnen Plug-ins finden Sie unter Plug-ins verwenden.

Proxys filtern

Sie können filtern, welche Microgateway-fähigen Proxys eine Edge Microgateway-Instanz verarbeitet. Beim Start von Edge Microgateway werden alle Microgateway-fähigen Proxys im Organisation zugeordnet ist. Verwenden Sie die folgende Konfiguration, um einzuschränken, welche Proxys den Microgateway verarbeitet. Diese Konfiguration schränkt beispielsweise die Proxys des Microgateways ein werden auf drei Elemente verarbeitet: edgemicro_proxy-1, edgemicro_proxy-2, und edgemicro_proxy-3:

edgemicro:
  proxies:
  - edgemicro_proxy-1
  - edgemicro_proxy-2
  - edgemicro_proxy-3

Produkte nach Name filtern

Verwenden Sie die folgende Konfiguration, um die Anzahl der API-Produkte zu begrenzen, die Edge Microgateway verwendet Downloads und Prozesse. Füge die productnamefilter hinzu, um heruntergeladene Produkte zu filtern Abfrageparameter für die in Edge Microgateway *.config.yaml aufgeführte API /products -Datei. Beispiel:

edge_config:
  bootstrap: >-
    https://edgemicroservices.apigee.net/edgemicro/bootstrap/organization/willwitman/environment/test
  jwt_public_key: 'https://myorg-test.apigee.net/edgemicro-auth/publicKey'
  managementUri: 'https://api.enterprise.apigee.com'
  vaultName: microgateway
  authUri: 'https://%s-%s.apigee.net/edgemicro-auth'
  baseUri: >-
    https://edgemicroservices.apigee.net/edgemicro/%s/organization/%s/environment/%s
  bootstrapMessage: Please copy the following property to the edge micro agent config
  keySecretMessage: The following credentials are required to start edge micro
  products: 'https://myorg-test.apigee.net/edgemicro-auth/products?productnamefilter=%5E%5BEe%5Ddgemicro.%2A%24'

Der Wert des Suchparameters muss im Format eines regulären Ausdrucks angegeben werden und URL-codiert sein. Der reguläre Ausdruck ^[Ee]dgemicro.*$ fängt beispielsweise folgende Namen ab: „edgemicro-test-1“ , „edgemicro_demo“ und „Edgemicro_New_Demo“. Der URL-codierte Wert, der für im Abfrageparameter verwendet wird: %5E%5BEe%5Ddgemicro.%2A%24.

Die folgende Debug-Ausgabe zeigt, dass nur die gefilterten Produkte heruntergeladen wurden:

...
2020-05-27T03:13:50.087Z [76060] [microgateway-config network] products download from https://gsc-demo-prod.apigee.net/edgemicro-auth/products?productnamefilter=%5E%5BEe%5Ddgemicro.%2A%24 returned 200 OK
...
....
....
{
   "apiProduct":[
      {
         "apiResources":[

         ],
         "approvalType":"auto",
         "attributes":[
            {
               "name":"access",
               "value":"public"
            }
         ],
         "createdAt":1590549037549,
         "createdBy":"k***@g********m",
         "displayName":"test upper case in name",
         "environments":[
            "prod",
            "test"
         ],
         "lastModifiedAt":1590549037549,
         "lastModifiedBy":"k***@g********m",
         "name":"Edgemicro_New_Demo",
         "proxies":[
            "catchall"
         ],
         "quota":"null",
         "quotaInterval":"null",
         "quotaTimeUnit":"null",
         "scopes":[

         ]
      },
      {
         "apiResources":[

         ],
         "approvalType":"auto",
         "attributes":[
            {
               "name":"access",
               "value":"public"
            }
         ],
         "createdAt":1590548328998,
         "createdBy":"k***@g********m",
         "displayName":"edgemicro test 1",
         "environments":[
            "prod",
            "test"
         ],
         "lastModifiedAt":1590548328998,
         "lastModifiedBy":"k***@g********m",
         "name":"edgemicro-test-1",
         "proxies":[
            "Lets-Encrypt-Validation-DoNotDelete"
         ],
         "quota":"null",
         "quotaInterval":"null",
         "quotaTimeUnit":"null",
         "scopes":[

         ]
      },
      {
         "apiResources":[
            "/",
            "/**"
         ],
         "approvalType":"auto",
         "attributes":[
            {
               "name":"access",
               "value":"public"
            }
         ],
         "createdAt":1558182193472,
         "createdBy":"m*********@g********m",
         "displayName":"Edge microgateway demo product",
         "environments":[
            "prod",
            "test"
         ],
         "lastModifiedAt":1569077897465,
         "lastModifiedBy":"m*********@g********m",
         "name":"edgemicro_demo",
         "proxies":[
            "edgemicro-auth",
            "edgemicro_hello"
         ],
         "quota":"600",
         "quotaInterval":"1",
         "quotaTimeUnit":"minute",
         "scopes":[

         ]
      }
   ]
}

Produkte nach benutzerdefinierten Attributen filtern

So filtern Sie Produkte anhand von benutzerdefinierten Attributen:

1. Wählen Sie in der Edge-Benutzeroberfläche den Proxy edgemicro_auth in der Organisation/Umgebung aus. auf dem Sie Edge Microgateway konfiguriert haben.
2. Öffnen Sie unter „Develop“ die Richtlinie „JavaCallout“ im Editor.
3. Fügen Sie ein benutzerdefiniertes Attribut mit dem Schlüssel products.filter.attributes mit einem kommagetrennten Wert Liste der Attributnamen. Nur Produkte, die einen der benutzerdefinierten Attributnamen enthalten an Edge Microgateway zurückgegeben.
4. Sie können die Prüfung auch um zu sehen, ob das Produkt für die aktuelle Umgebung aktiviert ist, indem Sie das benutzerdefinierte Attribut products.filter.env.enable auf false. Der Standardwert ist „true“.
5. (Nur Private Cloud) Wenn Sie sich in Edge für die private Cloud befinden, legen Sie das Attribut org.noncps auf true, um Produkte für Umgebungen ohne CPS abzurufen.

Beispiel:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<JavaCallout async="false" continueOnError="false" enabled="true" name="JavaCallout">
    <DisplayName>JavaCallout</DisplayName>
    <FaultRules/>
    <Properties>
        <Property name="products.filter.attributes">attrib.one, attrib.two</Property>
        <Property name="products.filter.env.enable">false</Property>
        <Property name="org.noncps">true</Property>
    </Properties>
    <ClassName>io.apigee.microgateway.javacallout.Callout</ClassName>
    <ResourceURL>java://micro-gateway-products-javacallout-2.0.0.jar</ResourceURL>
</JavaCallout>

Push-Häufigkeit für Analysen konfigurieren

Verwenden Sie diese Konfigurationsparameter, um die Häufigkeit zu steuern, mit der Edge Microgateway sendet zu Apigee hinzufügen:

• bufferSize (optional): Die maximale Anzahl an Analysedatensätzen, die der Puffer enthalten sein kann, bevor die ältesten Datensätze gelöscht werden. Standardeinstellung: 10.000
• batchSize (optional): Die maximale Größe eines Batches von Analysedatensätzen. an Apigee gesendet. Standardwert: 500
• flushInterval (optional): Die Anzahl der Millisekunden zwischen den einzelnen Leerungen des einen Batch von Analysedatensätzen, der an Apigee gesendet wurde. Standardeinstellung: 5.000

Beispiel:

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

Analysedaten maskieren

Die folgende Konfiguration verhindert, dass in Edge Informationen zum Anforderungspfad angezeigt werden Analytics. Fügen Sie der Microgateway-Konfiguration Folgendes hinzu, um den Anfrage-URI zu maskieren und/oder Anfragepfad. Der URI besteht aus dem Hostnamen und den Pfadteilen der Anfrage.

analytics:
  mask_request_uri: 'string_to_mask'
  mask_request_path: 'string_to_mask'

API-Aufrufe in Edge Analytics trennen

Sie können das Analyse-Plug-in so konfigurieren, dass ein bestimmter API-Pfad getrennt wird, sodass er wie folgt angezeigt wird: einen separaten Proxy in den Edge Analytics-Dashboards. So können Sie zum Beispiel Trennen Sie eine Systemdiagnose-API im Dashboard, um sie nicht mit tatsächlichen API-Proxy-Aufrufen zu verwechseln. Im Analytics-Dashboard, getrennte Proxys folgen diesem Namensmuster:

edgemicro_proxyname-health

Die folgende Abbildung zeigt zwei getrennte Proxys im Analytics-Dashboard: edgemicro_hello-health und edgemicro_mock-health:

Diese verwenden, um relative und absolute Pfade im Analytics-Dashboard als separate Proxys zu trennen:

• relativePath (optional): Gibt einen relativen Pfad zum Trennen in der Analytics-Dashboard. Wenn Sie beispielsweise /healthcheck angeben, werden alle API-Aufrufe, die den Pfad enthalten, /healthcheck wird im Dashboard als edgemicro_proxyname-health angezeigt. Beachten Sie, dass dieses Flag den Proxy-Basispfad ignoriert. Verwenden Sie das Flag proxyPath, um die Daten anhand eines vollständigen Pfads einschließlich Basispfad zu trennen.
• proxyPath (optional): Gibt einen vollständigen API-Proxy-Pfad an, einschließlich des Proxys Basispfad, um im Analyse-Dashboard zu trennen. Wenn Sie beispielsweise /mocktarget/healthcheck angeben, wobei /mocktarget der Proxy-Basispfad ist, werden alle API-Aufrufe mit dem Pfad /mocktarget/healthcheck werden im Dashboard als edgemicro_proxyname-health angezeigt.

In der folgenden Konfiguration wird beispielsweise jeder API-Pfad, der /healthcheck enthält, vom Analytics-Plug-in getrennt. Das bedeutet, /foo/healthcheck und /foo/bar/healthcheck wird im Analyse-Dashboard als separater Proxy mit dem Namen edgemicro_proxyname-health getrennt.

analytics:
  uri: >-
    https://xx/edgemicro/ax/org/docs/environment/test
  bufferSize: 100
  batchSize: 50
  flushInterval: 500
  relativePath: /healthcheck

In der folgenden Konfiguration wird jede API mit dem Proxypfad /mocktarget/healthcheck wird als separater Proxy namens edgemicro_proxyname-health in des Analytics-Dashboards.

analytics:
  uri: >-
    https://xx/edgemicro/ax/org/docs/environment/test
  bufferSize: 100
  batchSize: 50
  flushInterval: 500
  proxyPath: /mocktarget/healthcheck

Einrichten von Edge Microgateway hinter einem Unternehmensfirewall

HTTP-Proxy für die Kommunikation mit Apigee Edge verwenden

In Version 3.1.2 hinzugefügt.

Führen Sie die folgenden Schritte aus, um einen HTTP-Proxy für die Kommunikation zwischen Edge Microgateway und Apigee Edge zu verwenden: Folgendes:

1. Umgebungsvariablen festlegen HTTP_PROXY, HTTPS_PROXY und NO_PROXY. Diese Variablen steuern die Hosts für jeden HTTP-Proxy, den Sie für die Kommunikation mit Apigee Edge oder die Hosts, die die Kommunikation mit Apigee Edge nicht übernehmen sollen. Beispiel:

   export HTTP_PROXY='http://localhost:3786'
   export HTTPS_PROXY='https://localhost:3786'
   export NO_PROXY='localhost,localhost:8080'

   Beachten Sie, dass NO_PROXY eine durch Kommas getrennte Liste von Domains sein kann, die von Edge Microgateway keinen Proxy verwenden.

   Weitere Informationen zu diesen Variablen finden Sie unter https://www.npmjs.com/package/request#controlling-proxy-behaviour-using-environment-variables.

2. Starten Sie Edge Microgateway neu.

HTTP-Proxy für die Zielkommunikation verwenden

In Version 3.1.2 hinzugefügt.

Um einen HTTP-Proxy für die Kommunikation zwischen Edge Microgateway und Backend-Zielen zu verwenden, Gehen Sie so vor:

1. Fügen Sie der Microgateway-Konfigurationsdatei die folgende Konfiguration hinzu:

   edgemicro:
     proxy:
       tunnel: true | false
       url: proxy_url
       bypass: target_host # target hosts to bypass the proxy.
       enabled: true | false

   Wobei:

   • tunnel (optional): Wenn dieser Wert auf "true" gesetzt ist, verwendet Edge Microgateway die Methode "HTTP CONNECT", um ein HTTP-Tunneling durchzuführen. über eine einzelne TCP-Verbindung senden. Das Gleiche gilt, wenn die Umgebungsvariablen wie wie unten erwähnt, zum Konfigurieren des Proxys TLS aktiviert sind. Standard: false
   • url: Die HTTP-Proxy-URL.
   • bypass: (optional) Gibt eine oder mehrere durch Kommas getrennte Zielhost-URLs an, die den HTTP-Proxy umgehen sollte. Verwenden Sie NO_PROXY, wenn diese Eigenschaft nicht festgelegt ist. um festzulegen, welche Ziel-URLs umgangen werden sollen.
   • enabled: Wenn „true“ und proxy.url festgelegt ist, verwenden Sie den Wert proxy.url für den HTTP-Proxy. Wenn „true“ und proxy.url nicht festgelegt ist, die im HTTP-Proxy angegebenen Proxys verwenden Umgebungsvariablen HTTP_PROXY und HTTPS_PROXY, wie in HTTP-Proxy für die Kommunikation mit Apigee Edge verwenden

   Beispiel:

   edgemicro:
     proxy:
       tunnel: true
       url: 'http://localhost:3786'
       bypass: 'localhost','localhost:8080' # target hosts to bypass the proxy.
       enabled: true

2. Starten Sie Edge Microgateway neu.

Platzhalter in Microgateway-aware verwenden Proxys

Sie können einen oder mehrere „*“ verwenden im Basispfad eines edgemicro_*-Proxy (Microgateway-aware). Ein Basispfad von Mit /team/*/members können Kunden unter https://[host]/team/blue/members und https://[host]/team/green/members, ohne neue API-Proxys erstellen zu müssen um neue Teams zu unterstützen. Beachten Sie, dass /**/ nicht unterstützt wird.

Wichtig: Apigee unterstützt NICHT die Verwendung des Platzhalters „*“. als ersten Element eines Basispfads. Folgendes wird beispielsweise NICHT unterstützt: /*/-Suche.

JWT-Schlüssel rotieren

Irgendwann nach der anfänglichen Generierung eines JWT müssen Sie möglicherweise den Parameter ein öffentliches/privates Schlüsselpaar, das in der Edge-verschlüsselten KVM gespeichert ist. Dieser Prozess der Generierung eines neuen Schlüssels wird als Schlüsselrotation bezeichnet.

So verwendet Edge Microgateway JWTs

JSON Web Token (JWT) ist ein in RFC7519 beschriebener Tokenstandard. JWT bietet die Möglichkeit, eine Reihe von Anforderungen zu signieren, was vom Empfänger des JWT zuverlässig verifiziert werden kann.

Sie können ein JWT mit der Befehlszeile generieren und im Autorisierungsheader von API-Aufrufen anstelle eines API-Schlüssels. Beispiel:

curl -i http://localhost:8000/hello -H "Authorization: Bearer eyJhbGciOiJ..dXDefZEA"

Informationen zum Generieren von JWTs mit der Befehlszeile finden Sie unter Token generieren.

Was ist die Schlüsselrotation?

Irgendwann nach der anfänglichen Generierung eines JWT müssen Sie möglicherweise den Parameter ein öffentliches/privates Schlüsselpaar, das in der Edge-verschlüsselten KVM gespeichert ist. Dieser Prozess der Generierung eines neuen Schlüssels wird als Schlüsselrotation bezeichnet. Wenn Sie Schlüssel rotieren, wird ein neues Paar aus privatem und öffentlichem Schlüssel generiert. die im „Microgateway“ gespeichert sind KVM in Ihrer Apigee Edge-Organisation/-Umgebung. Darüber hinaus enthält der Der alte öffentliche Schlüssel wird zusammen mit seinem ursprünglichen Schlüssel-ID-Wert beibehalten.

Um ein JWT zu generieren, verwendet Edge Informationen, die in der verschlüsselten KVM gespeichert sind. A Die KVM mit dem Namen microgateway wurde bei der Ersteinrichtung erstellt und mit Schlüsseln gefüllt. Edge Microgateway. Die Schlüssel in der KVM werden zum Signieren und Verschlüsseln eines JWT verwendet.

Zu den KVM-Schlüsseln gehören:

• private_key: Der zuletzt erstellte private RSA-Schlüssel, der zum Signieren verwendet wurde. JWTs

• public_key – Das neueste (zuletzt erstellte) Zertifikat zur Überprüfung von JWTs. mit dem privaten_Schlüssel signiert.

• private_key_kid – Neueste (zuletzt erstellte) private Schlüssel-ID Diese Schlüssel-ID ist dem Wert "private_key" zugeordnet und wird verwendet, um die Schlüsselrotation zu unterstützen.

• public_key1_kid – Die letzte (zuletzt erstellte) öffentliche Schlüssel-ID. Dieser Schlüssel ist ist dem Wert public_key1 zugeordnet und wird zur Unterstützung der Schlüsselrotation verwendet. Dieser Wert ist mit dem untergeordneten Schlüssel des privaten Schlüssels identisch.

• public_key1 – Der zuletzt erstellte öffentliche Schlüssel.

Wenn Sie eine Schlüsselrotation durchführen, werden vorhandene Schlüssel/Wert-Paare in der Zuordnung ersetzt und Schlüssel werden hinzugefügt, um die alten öffentlichen Schlüssel beizubehalten. Beispiel:

• public_key2_kid – Die alte öffentliche Schlüssel-ID. Dieser Schlüssel ist mit dem public_key2. Dieser Wert wird zur Unterstützung der Schlüsselrotation verwendet.

• public_key2: Der alte öffentliche Schlüssel.

Zur Überprüfung vorgelegte JWTs werden mit dem neuen öffentlichen Schlüssel verifiziert. Wenn schlägt er fehl, wird der alte öffentliche Schlüssel verwendet, bis das JWT abläuft (nach dem Intervall „token_expiry*“, standardmäßig 30 Minuten). In können Sie auf diese Weise ohne den API-Traffic zu unterbrechen.

Schlüsselrotation

In diesem Abschnitt wird erläutert, wie eine Schlüsselrotation durchgeführt wird.

1. Verwenden Sie den Befehl edgemicro upgradekvm, um die KVM zu aktualisieren. Weitere Informationen zum Ausführen dieses Befehls finden Sie unter Upgrade die KVM. Sie müssen diesen Schritt nur einmal ausführen.
2. Verwenden Sie den Befehl edgemicro upgradeauth, um den edgemicro-oauth-Proxy zu aktualisieren. Einzelheiten zum Ausführen dieses Befehls finden Sie unter Upgrade des Edgemicro-auth-Proxys ausführen Sie müssen diesen Schritt nur einmal ausführen.
3. Fügen Sie der Datei ~/.edgemicro/org-env-config.yaml die folgende Zeile hinzu. Geben Sie dieselbe Organisation und Umgebung an, die Sie für das zu verwendende Microgateway konfiguriert haben:

   jwk_public_keys: 'https://$ORG-$ENV.apigee.net/edgemicro-auth/jwkPublicKeys'

4. Führen Sie den Befehl zur Schlüsselrotation aus, um die Schlüssel zu rotieren. Weitere Informationen zu diesem Befehl finden Sie unter Schlüssel drehen.

   edgemicro rotatekey -o $ORG -e $ENV -k $KEY -s $SECRET

   Beispiel:

   edgemicro rotatekey -o docs -e test \
   -k 27ee39567c75e4567a66236cbd4e86d1cc93df6481454301bd5fac4d3497fcbb \
   -s 4618b0008a6185d7327ebf53bee3c50282ccf45a3cceb1ed9828bfbcf1148b47
   

Nach der Schlüsselrotation gibt Edge mehrere Schlüssel an Edge Microgateway zurück. Hinweis im Im folgenden Beispiel hat jeder Schlüssel einen eindeutigen „Kinder“-Schlüssel, (Schlüssel-ID) zurückgegeben wird. Das Microgateway verwendet diese Schlüssel zum Validieren von Autorisierungstokens. Wenn die Tokenvalidierung fehlschlägt, sucht das Microgateway um zu sehen, ob es einen älteren Schlüssel im Schlüsselsatz gibt, und versucht diesen Schlüssel. Das Format des Die zurückgegebenen Schlüssel sind JSON Web Key (JWK). Informationen zu diesem Format finden Sie unter RFC 7517.

{
  "keys": [
    {
      "kty": "RSA",
      "n": "nSl7R_0wKLiWi6cO3n8aOJwYGBtinq723Jgg8i7KKWTSTYoszOjgGsJf_MX4JEW1YCScwpE5o4o8ccQN09iHVTlIhk8CNiMZNPipClmRVjaL_8IWvMQp1iN66qy4ldWXzXnHfivUZZogCkBNqCz7VSC5rw2Jf57pdViULVvVDGwTgf46sYveW_6h8CAGaD0KLd3vZffxIkoJubh0yMy0mQP3aDOeIGf_akeZeZ6GzF7ltbKGd954iNTiKmdm8IKhz6Y3gLpC9iwQ-kex_j0CnO_daHl1coYxUSCIdv4ziWIeM3dmjQ5_2dEvUDIGG6_Az9hTpNgPE5J1tvrOHAmunQ",
      "e": "AQAB",
      "kid": "2"
    },
    {
      "kty": "RSA",
      "n": "8BKwzx34BMUcHwTuQtmp8LFRCMxbkKg_zsWD6eOMIUTAsORexTGJsTy7z-4aH0wJ3fT-3luAAUPLBQwGcuHo0P1JnbtPrpuYjaJKSZOeIMOnlryJCspmv-1xG4qAqQ9XaZ9C97oecuj7MMoNwuaZno5MvsY-oi5B_gqED3vIHUjaWCErd4reONyFSWn047dvpE6mwRhZbcOTkAHT8ZyKkHISzopkFg8CD-Mij12unxA3ldcTV7yaviXgxd3eFSD1_Z4L7ZRsDUukCJkJ-8qY2-GWjewzoxl-mAW9D1tLK6qAdc89yFem3JHRW6L1le3YK37-bs6b2a_AqJKsKm5bWw",
      "e": "AQAB",
      "kid": "1"
    }
  ]
}

Ein "Nicht vorher"-Attribut konfigurieren Verspätung

Ab Version 3.1.5 dauerte der neue private Schlüssel, der durch den Befehl rotatekey generiert wurde, und die neu generierten Tokens wurden mit dem neuen privaten Schlüssel signiert. Sie können jedoch Der neue öffentliche Schlüssel wurde Edge Microgateway-Instanzen nur alle 10 Minuten zur Verfügung gestellt (standardmäßig) Zeitpunkt, zu dem die Microgateway-Konfiguration aktualisiert wurde. Aufgrund dieser Verzögerung zwischen der und Microgateway-Instanzen aktualisieren, werden Tokens, die mit dem neuesten Schlüssel signiert sind, bis zum Alle Instanzen haben den öffentlichen neuesten Schlüssel erhalten.

In Fällen, in denen mehrere Microgateway-Instanzen vorhanden sind, führte die Verzögerung beim öffentlichen Schlüssel manchmal zeitweilig auftretende Laufzeitfehler mit dem Status 403, da die Tokenvalidierung eine Instanz, aber bei einer anderen schlagen sie fehl, bis alle Instanzen aktualisiert wurden.

Ab Version 3.1.6 können Sie mit einem neuen Flag für den Befehl rotatekey eine Verzögerung für den neuen privaten Schlüssel wirksam werden, sodass alle Microgateway-Instanzen aktualisiert werden können. und den neuen öffentlichen Schlüssel erhalten. Das neue Flag ist --nbf, was für „not before“ (Nicht vorher) steht. Dieses Flag verwendet einen ganzzahligen Wert, d. h. die Anzahl der Minuten, die verzögert werden soll.

Im folgenden Beispiel ist die Verzögerung auf 15 Minuten festgelegt:

edgemicro rotatekey -o docs -e test \
-k 27ee39567c75e4567a66236cbd4e86d1cc93df6481454301bd5fac4d3497fcbb \
-s 4618b0008a6185d7327ebf53bee3c50282ccf45a3cceb1ed9828bfbcf1148b47 \
--nbf 15

Es empfiehlt sich, die Verzögerung auf einen größeren Wert als die Konfigurationseinstellung config_change_poll_internal festzulegen. der standardmäßig 10 Minuten beträgt. Siehe auch edgemicro-Attribute.

Heruntergeladene Proxys filtern

Standardmäßig lädt Edge Microgateway alle Proxys in Ihrer Edge-Organisation herunter die mit dem Präfix "edgemicro_" beginnen. Du kannst diese Standardeinstellung ändern, um Proxys herunterzuladen deren Namen mit einem Muster übereinstimmen.

1. Öffnen Sie die Edge Micro-Konfigurationsdatei: ~/.edgemicro/org-env-config.yaml
2. Fügen Sie das "proxyPattern"-Element unter "Edge_config" hinzu. Das folgende Muster wird beispielsweise Laden Sie Proxys wie Edgemicro_foo, Edgemicro_fast und Edgemicro_first herunter.

   edge_config:
   …
   proxyPattern: edgemicro_f*

Produkte ohne API-Proxys angeben

In Apigee Edge können Sie ein API-Produkt erstellen, das keine API-Proxys enthält. Bei dieser Produktkonfiguration kann ein API-Schlüssel, der mit diesem Produkt verknüpft ist, mit beliebigen der in Ihrer Organisation bereitgestellt wird. Ab Version 2.5.4 unterstützt Edge Microgateway dieses Produkt Konfiguration.

Debugging und Fehlerbehebung

Verbindung zu einem Debugger herstellen

Sie können Edge Microgateway mit einem Debugger wie node-inspector ausführen. Dies ist nützlich für und Debugging benutzerdefinierter Plug-ins.

1. Starten Sie Edge Microgateway im Debug-Modus neu. Fügen Sie dazu DEBUG=* zum Anfang des start-Befehls:

   DEBUG=* edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET

   Mit dem folgenden Befehl können Sie die Debug-Ausgabe an eine Datei weiterleiten:

   export DEBUG=* nohup edgemicro start \
   -o $ORG -e $ENV -k $KEY -s $SECRET 2>&1 | tee /tmp/file.log

2. Starten Sie den Debugger und richten Sie ihn so ein, dass für den Fehlerbehebungsprozess die Portnummer überwacht wird.
3. Sie können nun den Edge Microgateway-Code durchlaufen, Haltepunkte einstellen, Ausdrücke beobachten, und so weiter.

Sie können Node.js-Standard-Flags für den Debug-Modus angeben. Beispiel: --nolazy hilft beim Debuggen von asynchronem Code.

Protokolldateien prüfen

Prüfen Sie bei Problemen die Protokolldateien auf Ausführungsdetails und Fehler. Informationen. Weitere Informationen finden Sie unter Protokolldateien verwalten.

API-Schlüsselsicherheit verwenden

API-Schlüssel bieten einen einfachen Mechanismus zum Authentifizieren von Clients, die Anfragen an Edge stellen Microgateway. Sie können einen API-Schlüssel erhalten, indem Sie den Wert des Consumer-Keys (auch Client-ID genannt) kopieren von einem Apigee Edge-Produkt, das den Edge Microgateway-Authentifizierungs-Proxy enthält.

Zwischenspeichern von Schlüsseln

API-Schlüssel werden gegen Inhabertokens ausgetauscht, die im Cache gespeichert werden. Du kannst das Caching deaktivieren, indem du den Cache-Control: no-cache-Header bei eingehenden Anfragen an Edge Microgateway.

API-Schlüssel verwenden

Sie können den API-Schlüssel in einer API-Anfrage entweder als Abfrageparameter oder in einem Header übergeben. Standardmäßig Der Name des Headers und des Abfrageparameters ist x-api-key.

Beispiel für einen Abfrageparameter:

curl http://localhost:8000/foobar?x-api-key=JG616Gjz7xs4t0dvpvVsGdI49G34xGsz

Beispiel für Anzeigentitel:

curl http://localhost:8000/foobar -H "x-api-key:JG616Gjz7xs4t0dvpvVsGdI49G34xGsz"

API-Schlüsselnamen konfigurieren

Standardmäßig ist x-api-key der Name, der für den Header des API-Schlüssels und den Abfrageparameter verwendet wird. Sie können diese Standardeinstellung in der Konfigurationsdatei ändern, wie unter Konfigurationsänderungen vornehmen erläutert. Um beispielsweise den Name in apiKey:

oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  api-key-header: apiKey

In diesem Beispiel werden sowohl der Suchparameter als auch der Headername in apiKey geändert. Die mit dem Namen x-api-key funktioniert. Siehe auch Konfigurationsänderungen vornehmen

Beispiel:

curl http://localhost:8000/foobar -H "apiKey:JG616Gjz7xs4t0dvpvVsGdI49G34xGsz"

Weitere Informationen zur Verwendung von API-Schlüsseln mit Proxyanfragen finden Sie unter Secure Edge Microgateway

Upstream-Antwortcodes aktivieren

Standardmäßig gibt das Plug-in oauth nur 4xx-Fehlerstatuscodes zurück, wenn ist die Antwort kein 200-Status. Sie können dieses Verhalten so ändern, gibt je nach Fehler den genauen 4xx- oder 5xx-Code zurück.

Fügen Sie oauth.useUpstreamResponse: true hinzu, um diese Funktion zu aktivieren an Ihre Edge Microgateway-Konfiguration an. Beispiel:

oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  gracePeriod: 10
  useUpstreamResponse: true

OAuth2-Tokensicherheit verwenden

In diesem Abschnitt wird erläutert, wie Sie OAuth2-Zugriffstokens und Aktualisierungstokens erhalten. Zugriffstokens werden verwendet, sichere API-Aufrufe über Microgateway. Aktualisierungstokens werden verwendet, um neue Zugriffstokens abzurufen.

Zugriffstoken abrufen

In diesem Abschnitt wird erläutert, wie Sie den edgemicro-auth-Proxy zum Abrufen eines Zugriffstokens verwenden.

Sie können ein Zugriffstoken auch mit dem Befehl edgemicro token über die Befehlszeile abrufen. Weitere Informationen zur Befehlszeile finden Sie unter Tokens verwalten.

API 1: Anmeldedaten als Textparameter senden

Ersetzen Sie die Namen Ihrer Organisation und Umgebung in der URL. Sie ersetzen die Werte der Nutzer-ID und des Consumer-Secrets, die aus einer Entwickler-App auf Apigee abgerufen wurden. Edge für die Textparameter client_id und client_secret:

curl -i -X POST "http://<org>-<test>.apigee.net/edgemicro-auth/token" \
-d '{"grant_type": "client_credentials", "client_id": "your_client_id", \
"client_secret": "your_client_secret"}' -H "Content-Type: application/json"

API 2: Anmeldedaten in einem Basic Auth-Header senden

Senden Sie die Client-Anmeldedaten als Basic Authentication-Header und den grant_type als Formularparameter. Dieses Befehlsform wird auch im RFC 6749: Das OAuth 2.0-Autorisierungs-Framework.

http://<org>-<test>.apigee.net/edgemicro-auth/token -v -u your_client_id:your_client_secret \
-d 'grant_type=client_credentials' -H "Content-Type: application/x-www-form-urlencoded"

Beispielausgabe

{
"token": "eyJraWQiOiIxIiwidHlwIjoi",
"access_token": "eyJraWQiOiIxIiwid",
"token_type": "bearer",
"expires_in": "108000"
}

Aktualisierungstoken erhalten

Um ein Aktualisierungstoken zu erhalten, führen Sie einen API-Aufruf an den Endpunkt /token der edgemicro-auth-Proxy. Du MÜSSEN diesen API-Aufruf mit der password durchführen Erteilungstyp. Die folgenden Schritte führen Sie durch den Prozess.

1. Rufen Sie mit der /token API ein Zugriffs- und Aktualisierungstoken ab. Beachten Sie, dass der Berechtigungstyp ist password:

   curl -X POST \
     https://your_organization-your_environment.apigee.net/edgemicro-auth/token \
     -H 'Content-Type: application/json' \
     -d '{
      "client_id":"mpK6l1Bx9oE5zLdifoDbF931TDnDtLq",
      "client_secret":"bUdDcFgv3nXffnU",
      "grant_type":"password",
      "username":"mpK6lBx9RoE5LiffoDbpF931TDnDtLq",
      "password":"bUdD2FvnMsXffnU"
   }'

   Die API gibt ein Zugriffstoken und ein Aktualisierungstoken zurück. Die Antwort sieht in etwa so aus: dies:

   {
       "token": "your-access-token",
       "access_token": "your-access-token",
       "token_type": "bearer",
       "expires_in": "108000",
       "refresh_token": "your-refresh-token",
       "refresh_token_expires_in": "431999",
       "refresh_token_issued_at": "1562087304302",
       "refresh_token_status": "approved"
   }

2. Sie können jetzt das Aktualisierungstoken verwenden, um ein neues Zugriffstoken zu erhalten, indem Sie Folgendes aufrufen: den Endpunkt /refresh derselben API. Beispiel:

   curl -X POST \
     https://willwitman-test.apigee.net/edgemicro-auth/refresh \
     -H 'Content-Type: application/json' \
     -d '{
      "client_id":"mpK6l1Bx9RoE5zLifoDbpF931TDnDtLq",
      "client_secret":"bUdDc2Fv3nMXffnU",
      "grant_type":"refresh_token",
      "refresh_token":"your-refresh-token"
   }'

   Die API gibt ein neues Zugriffstoken zurück. Die Antwort sieht in etwa so aus:

   {
       "token": "your-new-access-token"
       }

Permanente Überwachung

Forever ist ein Node.js-Tool, das startet eine Node.js-Anwendung automatisch neu, wenn der Prozess unterbrochen wird oder ein Fehler auftritt. Rand Microgateway verfügt über eine Datei forever.json, mit der Sie steuern können, wie viele mit welchen Intervallen Edge Microgateway neu gestartet werden soll. Diese Datei konfiguriert ein Forever-Dienst namens forever-monitor, der Forever verwaltet Programmatisch garantiert.

Sie finden die Datei forever.json in der Root-Installation von Edge Microgateway. -Verzeichnis. Weitere Informationen finden Sie unter . Wo ist Edge Microgateway installiert? Details zu den Konfigurationsoptionen finden Sie in der forever-monitor.

Der Befehl edgemicro forever enthält Flags, mit denen Sie den Speicherort der Die Datei forever.json (Flag -f) und das Forever-Monitoring starten/stoppen (das Flag -a). Beispiel:

edgemicro forever -f ~/mydir/forever.json -a start

Weitere Informationen finden Sie in der Befehlszeilen-Referenz unter Forevermonitoring.

Endpunkt für Konfigurationsdatei angeben

Wenn Sie mehrere Edge Microgateway-Instanzen ausführen, möchten Sie möglicherweise deren Konfigurationen verwalten von einem einzigen Ort aus. Geben Sie dazu einen HTTP-Endpunkt an, an dem Edge Micro die zugehörige Konfigurationsdatei herunterladen. Sie können diesen Endpunkt beim Starten von Edge Micro mit -u-Flag.

Beispiel:

edgemicro start -o jdoe -e test -u http://mylocalserver/mgconfig -k public_key -s secret_key

Dabei gibt der Endpunkt "mgconfig" den Inhalt der Konfigurationsdatei zurück. Dies ist die Datei die sich standardmäßig in ~/.edgemicro befindet und folgende Namenskonvention hat: org-env-config.yaml.

Zwischenspeichern von TCP-Verbindungsdaten deaktivieren

Mit dem Konfigurationsattribut nodelay können Sie die Datenzwischenspeicherung für Von Edge Microgateway verwendete TCP-Verbindungen.

Standardmäßig verwenden TCP-Verbindungen den Nagle , um Daten vor dem Senden zu puffern. Wenn nodelay auf true festgelegt wird, deaktiviert dieses Verhalten (Daten werden jedes Mal sofort Daten ausgelöst) socket.write() wird aufgerufen). Weitere Informationen finden Sie im Hilfeartikel Node.js in der Dokumentation.

Bearbeiten Sie die Edge Micro-Konfigurationsdatei so, um nodelay zu aktivieren:

edgemicro:
  nodelay: true
  port: 8000
  max_connections: 1000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

Edge Microgateway im eigenständigen Modus ausführen

Sie können Edge Microgateway unabhängig von jedem Apigee Edge-Abhängigkeit In diesem Szenario, dem eigenständigen Modus, können Sie Edge Microgateway ausführen und testen ohne Internetverbindung nutzen zu können.

Im eigenständigen Modus funktionieren die folgenden Funktionen nicht, da dafür eine Verbindung erforderlich ist. an Apigee Edge:

• OAuth und API-Schlüssel
• Kontingent
• Analytics

Benutzerdefinierte Plug-ins und Spike Arrest funktionieren hingegen normal, da sie eine Verbindung zu Apigee Edge. Darüber hinaus können Sie mit dem neuen Plug-in extauth im eigenständigen Modus API-Aufrufe an das Microgateway mit einem JWT autorisieren.

Gateway konfigurieren und starten

So führen Sie Edge Microgateway im eigenständigen Modus aus:

1. Erstellen Sie eine Konfigurationsdatei mit folgendem Namen: $HOME/.edgemicro/$ORG-$ENV-config.yaml

   Beispiel:

   vi $HOME/.edgemicro/foo-bar-config.yaml

2. Fügen Sie folgenden Code in die Datei ein:

   edgemicro:
     port: 8000
     max_connections: 1000
     config_change_poll_interval: 600
     logging:
       level: error
       dir: /var/tmp
       stats_log_interval: 60
       rotate_interval: 24
     plugins:
       sequence:
         - extauth
         - spikearrest
   headers:
     x-forwarded-for: true
     x-forwarded-host: true
     x-request-id: true
     x-response-time: true
     via: true
   extauth:
     publickey_url: https://www.googleapis.com/oauth2/v1/certs
   spikearrest:
     timeUnit: second
     allow: 10
     buffersize: 0

3. Exportieren Sie die folgende Umgebungsvariable mit dem Wert „1“:

   export EDGEMICRO_LOCAL=1

4. Führen Sie den folgenden start-Befehl aus. Dabei geben Sie Werte zum Instanziieren der lokaler Proxy:

   edgemicro start -o $ORG -e $ENV -a $LOCAL_PROXY_NAME \
     -v $LOCAL_PROXY_VERSION -t $TARGET_URL -b $BASE_PATH

   Wobei:

   • $ORG ist die „Organisation“ den Sie im Namen der Konfigurationsdatei verwendet haben.
   • $ENV ist die „Umgebung“. Namen, den Sie in der Konfigurationsdatei verwendet haben. Namen.
   • $LOCAL_PROXY_NAME ist der Name des lokalen Proxys, der erstellt wird. Sie können einen beliebigen Namen.
   • $LOCAL_PROXY_VERSION ist die Versionsnummer für den Proxy.
   • $TARGET_URL ist die URL für das Ziel des Proxys. (Das Ziel ist der den der Proxy aufruft.)
   • $BASE_PATH ist der Basispfad des Proxys. Dieser Wert muss mit „Vorwärts“ beginnen Schrägstrich. Geben Sie für einen Stammpfad nur einen Schrägstrich an. Beispiel: „/“.

   Beispiel:

   edgemicro start -o local -e test -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /

5. Die Konfiguration testen.

   curl http://localhost:8000/echo  { "error" : "missing_authorization" }

   Da sich das Plug-in extauth in der Datei foo-bar-config.yaml befindet, eine „missing_authorization“ abrufen Fehler. Dieses Plug-in validiert ein JWT, das in der Autorisierung vorhanden sein muss des API-Aufrufs an. Im nächsten Abschnitt erhalten Sie ein JWT, das API-Aufrufe zulässt. ohne Fehler durchlaufen werden.

Beispiel: Autorisierungstoken abrufen

Das folgende Beispiel zeigt, wie Sie ein JWT vom Edge Microgateway-JWT-Endpunkt auf Apigee Edge (edgemicro-auth/jwkPublicKeys) abrufen. Dieser Endpunkt wird bereitgestellt, wenn Sie Edge Microgateway standardmäßig einrichten und konfigurieren. Um das JWT vom Apigee-Endpunkt abzurufen, müssen Sie zuerst Edge Microgateway standardmäßig einrichten. mit dem Internet verbunden sein. Der Apigee-Endpunkt wird hier zu Beispielzwecken verwendet und ist nicht erforderlich. Sie können bei Bedarf einen anderen JWT-Tokenendpunkt verwenden. In diesem Fall musst du das JWT mit die für diesen Endpunkt bereitgestellte API.

In den folgenden Schritten wird erläutert, wie Sie ein Token über den Endpunkt edgemicro-auth/jwkPublicKeys abrufen:

1. Sie müssen eine Standardeinstellung Edge Microgateway einrichten und konfigurieren, um den edgemicro-auth-Proxy bereitzustellen für Ihre Organisation/Umgebung auf Apigee Edge. Wenn Sie diesen Schritt bereits ausgeführt haben, müssen Sie ihn nicht wiederholen.
2. Wenn Sie Edge Microgateway auf Apigee Cloud bereitgestellt haben, müssen Sie mit dem Internet verbunden sein, damit Sie ein JWT von diesem Endpunkt abrufen können.
3. Beenden Sie Edge Microgateway:

   edgemicro stop

4. Gehen Sie in der zuvor erstellten Konfigurationsdatei ($HOME/.edgemicro/org–env-config.yaml) so vor: Zeige auf extauth:publickey_url Attribut zu dem Endpunkt edgemicro-auth/jwkPublicKeys in Ihrer Apigee Edge-Organisation/-Umgebung. Beispiel:

   extauth:
     publickey_url: 'https://your_org-your_env.apigee.net/edgemicro-auth/jwkPublicKeys'

5. Starten Sie Edge Microgateway wie zuvor neu und verwenden Sie dabei die Organisations-/Umgebungsnamen, die Sie im Namen der Konfigurationsdatei verwendet haben. Beispiel:

   edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /

6. Ruft ein JWT-Token vom Autorisierungsendpunkt ab. Weil du edgemicro-auth/jwkPublicKeys verwendest Endpunkt, können Sie den folgenden Befehl über die Befehlszeile verwenden:

Sie können ein JWT für Edge Microgateway mit dem Befehl edgemicro token oder eine API. Beispiel:

edgemicro token get -o your_org -e your_env \
  -i G0IAeU864EtBo99NvUbn6Z4CBwVcS2 -s uzHTbwNWvoSmOy

Wobei:

• your_org ist der Name Ihrer Apigee-Organisation, für die Sie zuvor angegeben haben. konfiguriertes Edge Microgateway.
• your_env ist eine Umgebung in der Organisation.
• Die Option i gibt den Consumer Key einer Entwickler-App an, die ein Produkt enthält. der den edgemicro-auth-Proxy enthält.
• Die Option s gibt das Consumer-Secret einer Entwickler-App an, die ein das den edgemicro-auth-Proxy enthält.

Dieser Befehl fordert Apigee Edge auf, ein JWT zu generieren, mit dem dann die API überprüft werden kann. Anrufe.

Eigenständige Konfiguration testen

Um die Konfiguration zu testen, rufen Sie die API mit dem Token auf, das im Autorisierungsheader wie folgt hinzugefügt wird:

curl http://localhost:8000/echo -H "Authorization: Bearer your_token

Beispiel:

curl http://localhost:8000/echo -H "Authorization: Bearer eyJraWQiOiIxIiwidHlwIjo...iryF3kwcDWNv7OQ"

Beispielausgabe:

{
   "headers":{
      "user-agent":"curl/7.54.0",
      "accept":"*/*",
      "x-api-key":"DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP",
      "client_received_start_timestamp":"1535134472699",
      "x-authorization-claims":"eyJhdDbiO...M1OTE5MTA1NDkifQ==",
      "target_sent_start_timestamp":"1535134472702",
      "x-request-id":"678e3080-a7ae-11e8-a70f-87ae30db3896.8cc81cb0-a7c9-11e8-a70f-87ae30db3896",
      "x-forwarded-proto":"http",
      "x-forwarded-host":"localhost:8000",
      "host":"mocktarget.apigee.net",
      "x-cloud-trace-context":"e2ac4fa0112c2d76237e5473714f1c85/1746478453618419513",
      "via":"1.1 localhost, 1.1 google",
      "x-forwarded-for":"::1, 216.98.205.223, 35.227.194.212",
      "connection":"Keep-Alive"
   },
   "method":"GET",
   "url":"/",
   "body":""
}

Lokalen Proxymodus verwenden

Im lokalen Proxy-Modus benötigt Edge Microgateway kein microgateway-aware-Proxy auf Apigee Edge bereitgestellt werden. Stattdessen konfigurieren Sie einen „lokalen Proxy“ indem Sie einen lokalen Proxy-Namen, einen Basispfad und eine Ziel-URL, Starten Sie das Microgateway. API-Aufrufe an das Microgateway werden dann an das Ziel URL des lokalen Proxys. Abgesehen davon funktioniert der lokale Proxymodus genauso Edge Microgateway im normalen Modus Die Authentifizierung funktioniert wie die Spitze, und Kontingentdurchsetzung, benutzerdefinierte Plug-ins und so weiter.

Anwendungsfall und Beispiel

Der lokale Proxy-Modus ist nützlich, wenn Sie nur einen einzelnen Proxy mit einem Edge Microgateway verknüpfen müssen Instanz. Sie können beispielsweise Edge Microgateway als Sidecar-Proxy in Kubernetes einfügen, wobei ein Microgateway und einem Dienst werden jeweils in einem einzigen Pod ausgeführt, und das Microgateway verwaltet den Traffic zu und vom zugehörigen Begleitdienst. Die folgende Abbildung zeigt diese Architektur, in der Edge Microgateway fungiert als Sidecar-Proxy in einem Kubernetes-Cluster. Jede Microgateway-Instanz kommuniziert nur an einen einzelnen Endpunkt im Companion-Dienst gesendet werden:

Ein Vorteil dieses Architekturstils besteht darin, dass Edge Microgateway API Verwaltung einzelner Dienste, die in einer Containerumgebung bereitgestellt werden, z. B. ein Kubernetes-Cluster.

Lokalen Proxymodus konfigurieren

So konfigurieren Sie Edge Microgateway für die Ausführung im lokalen Proxymodus:

1. Führen Sie edgemicro init aus, um Ihre lokale Konfigurationsumgebung genau einzurichten. wie bei einer typischen Edge Microgateway-Einrichtung. Siehe auch Edge Microgateway konfigurieren
2. Führen Sie edgemicro configure wie bei einer typischen Edge Microgateway-Einrichtung aus Verfahren. Beispiel:

   edgemicro configure -o your_org -e your_env -u your_apigee_username

   Dieser Befehl stellt die Richtlinie edgemicro-auth in Edge bereit und gibt einen Schlüssel zurück und das Secret, das Sie zum Starten des Microgateways benötigen. Weitere Informationen findest du unter Edge Microgateway konfigurieren

3. Erstellen Sie in Apigee Edge ein API-Produkt mit der folgenden obligatorischen Konfiguration (Sie können alle anderen Konfigurationen nach Bedarf verwalten): <ph type="x-smartling-placeholder">
   </ph>
   • Sie müssen dem Produkt den Proxy edgemicro-auth hinzufügen. Dieser Proxy wurde automatisch bereitgestellt, als Sie edgemicro configure ausgeführt haben.
   • Sie müssen einen Ressourcenpfad angeben. Apigee empfiehlt, diesen Pfad zum das Produkt: /**. Weitere Informationen finden Sie unter Verhalten des Ressourcenpfads konfigurieren. Siehe auch API erstellen Produkte in der Edge-Dokumentation.

4. Erstellen Sie in Apigee Edge einen Entwickler oder verwenden Sie einen vorhandenen Entwickler, wenn Sie Weitere Informationen finden Sie unter Entwickler mithilfe der Edge-Verwaltungsbenutzeroberfläche hinzufügen.

5. Erstellen Sie in Apigee Edge eine Entwickler-App. Sie müssen das API-Produkt hinzufügen, das Sie die Sie gerade in der App erstellt haben. Weitere Informationen finden Sie unter Registrieren einer App in Edge. Management-UI.
6. Exportieren Sie auf dem Computer, auf dem Edge Microgateway installiert ist, Folgendes: den Wert „1“ haben.

   export EDGEMICRO_LOCAL_PROXY=1

7. Führen Sie folgenden start-Befehl aus:

   edgemicro start -o your_org -e your_environment -k your_key -s your_secret \
       -a local_proxy_name -v local_proxy_version -t target_url -b base_path

   Wobei:

   • your_org ist Ihre Apigee-Organisation.
   • your_environment ist eine Umgebung in Ihrer Organisation.
   • your_key ist der Schlüssel, der bei der Ausführung zurückgegeben wurde. edgemicro configure.
   • your_secret ist das Secret, das bei der Ausführung zurückgegeben wurde edgemicro configure.
   • local_proxy_name ist der Name des lokalen Proxys, der erstellt wird.
   • local_proxy_version ist die Versionsnummer für den Proxy.
   • target_url ist die URL für das Ziel des Proxys (der Dienst, den der Proxy aufrufen).
   • base_path ist der Basispfad des Proxys. Dieser Wert muss mit „Vorwärts“ beginnen Schrägstrich. Geben Sie für einen Stammpfad nur einen Schrägstrich an. Beispiel: „/“.

   Beispiel:

   edgemicro start -o your_org -e test -k 7eb6aae644cbc09035a...d2eae46a6c095f \
     -s e16e7b1f5d5e24df...ec29d409a2df853163a -a proxy1 -v 1 \
     -t http://mocktarget.apigee.net -b /echo

Konfiguration testen

Sie können die lokale Proxykonfiguration testen, indem Sie den Proxy-Endpunkt aufrufen. Beispiel: Wenn Sie den Basispfad /echo angegeben haben, können Sie den Proxy so aufrufen:

curl  http://localhost:8000/echo
{
  "error" : "missing_authorization",
  "error_description" : "Missing Authorization header"
}

Bei diesem ersten API-Aufruf ist ein Fehler aufgetreten, da Sie keinen gültigen API-Schlüssel angegeben haben. Sie finden den Schlüssel in der zuvor erstellten Entwickler-App. Öffnen Sie die App in der Edge-Benutzeroberfläche, kopieren Sie den Consumer-Key und verwenden Sie diesen Schlüssel wie folgt:

curl  http://localhost:8000/echo -H 'x-api-key:your_api_key'

Beispiel:

curl  http://localhost:8000/echo -H "x-api-key:DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP"

Beispielausgabe:

{
  "headers":{
    "user-agent":"curl/7.54.0",
    "accept":"*/*",
    "x-api-key":"DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP",
    "client_received_start_timestamp":"1535134472699",
    "x-authorization-claims":"eyJhdWQiOi...TQ0YmUtOWNlOS05YzM1OTE5MTA1NDkifQ==",
    "target_sent_start_timestamp":"1535134472702",
    "x-request-id":"678e3080-a7ae-11e8-a70f-87ae30db3896.8cc81cb0-a7c9-11e8-a70f-87ae30db3896",
    "x-forwarded-proto":"http",
    "x-forwarded-host":"localhost:8000",
    "host":"mocktarget.apigee.net",
    "x-cloud-trace-context":"e2ac4fa0112c2d76237e5473714f1c85/1746478453618419513",
    "via":"1.1 localhost, 1.1 google",
    "x-forwarded-for":"::1, 216.98.205.223, 35.227.194.212",
    "connection":"Keep-Alive"
  },
  "method":"GET",
  "url":"/",
  "body":""
}

Synchronisierer verwenden

In diesem Abschnitt wird die Verwendung des Synchronisierers (optionales Funktion) erläutert, verbessert die Ausfallsicherheit von Edge Microgteway, um Konfigurationsdaten von Apigee Edge abzurufen und in eine lokale Redis-Datenbank zu schreiben. Mit eine Synchronisierer-Instanz, andere Edge Microgateway-Instanzen, die auf verschiedenen Knoten ausgeführt werden können ihre Konfiguration direkt aus dieser Datenbank abrufen.

Die Syncrhonizer-Funktion wird derzeit für die Arbeit mit Redis 5.0.x unterstützt.

Was ist der Synchronisierer?

Der Synchronisierer bietet ein gewisses Maß an Ausfallsicherheit für Edge Microgateway. Es trägt dazu bei, dass jede Instanz von Edge Microgateway dieselbe Konfiguration verwendet Bei einer Internetunterbrechung können Edge Microgateway-Instanzen gestartet und ausgeführt werden. ordnungsgemäß funktioniert.

Standardmäßig müssen Edge Microgateway-Instanzen mit Apigee Edge kommunizieren können, um Konfigurationsdaten wie API-Proxy- und API-Produktkonfigurationen abzurufen und zu aktualisieren. Wenn die Internetverbindung mit Edge unterbrochen wird, können Microgateway-Instanzen weiterhin da die neuesten Konfigurationsdaten im Cache gespeichert werden. Neue Microgateway-Instanzen kann ohne klare Verbindung nicht gestartet werden. Außerdem kann ein Internet Unterbrechung, sodass eine oder mehrere Microgateway-Instanzen mit der Konfiguration ausgeführt werden Daten, die nicht mit anderen Instanzen synchron sind.

Der Edge Microgateway-Synchronisierer bietet einen alternativen Mechanismus für Edge Microgateway Instanzen, um Konfigurationsdaten abzurufen, die sie zum Starten und Verarbeiten des API-Proxy-Traffics benötigen. Zu den aus Aufrufen von Apigee Edge abgerufenen Konfigurationsdaten gehören: der jwk_public_keys-Aufruf, die Aufrufe jwt_public_key, Bootstrap und API-Produkte. Der Synchronisierer ermöglicht es, dass alle Edge Microgateways auf verschiedenen Knoten ausgeführt werden, um ordnungsgemäß zu starten und synchron zu bleiben, Die Internetverbindung zwischen Edge Microgateway und Apigee Edge ist unterbrochen.

Der Synchronisierer ist eine speziell konfigurierte Instanz von Edge Microgateway. Sein einziger Zweck ist das Abfragen von Apigee Edge (das Timing ist konfigurierbar), Konfigurationsdaten abzurufen und in eine lokale Redis-Datenbank schreiben. Die Synchronisierungsinstanz selbst kann den API-Proxy nicht verarbeiten. Zugriffe. Andere Instanzen von Edge Microgateway, die auf verschiedenen Knoten ausgeführt werden, so konfiguriert sein, dass Konfigurationsdaten aus der Redis-Datenbank und nicht aus Apigee abgerufen werden Edge Da alle Microgateway-Instanzen ihre Konfigurationsdaten aus der lokalen können sie auch im Falle einer Internetverbindung API-Anfragen starten und verarbeiten. Störungen.

Synchronisierer-Instanz konfigurieren

Fügen Sie der Datei org-env/config.yaml die folgende Konfiguration für die Edge Microgateway-Installation, die Sie als Synchronisierer verwenden möchten:

edgemicro:
  redisHost: host_IP
  redisPort: host_port
  redisDb: database_index
  redisPassword: password
edge_config:
  synchronizerMode: 1
  redisBasedConfigCache: true

Beispiel:

edgemicro:
  redisHost: 192.168.4.77
  redisPort: 6379
  redisDb: 0
  redisPassword: codemaster
edge_config:
  synchronizerMode: 1
  redisBasedConfigCache: true

Speichern Sie schließlich die Konfigurationsdatei und starten Sie die Edge Microgateway-Instanz. Es beginnt Apigee Edge abfragen und heruntergeladene Konfigurationsdaten in der Redis-Datenbank speichern.

Reguläre Edge Microgateway-Instanzen konfigurieren

Wenn der Synchronisierer ausgeführt wird, können Sie zusätzliche Edge Microgateway-Knoten konfigurieren um reguläre Microgateway-Instanzen auszuführen, die API-Proxy-Traffic verarbeiten. Sie konfigurieren jedoch um die Konfigurationsdaten dieser Instanzen aus der Redis-Datenbank abzurufen, Apigee Edge

Fügen Sie jedem zusätzlichen Edge Microgateway-Knoten die folgende Konfiguration hinzu org-env/config.yaml-Datei. Beachten Sie, dass die synchronizerMode ist auf 0 festgelegt. Dieses Attribut legt fest, dass die Instanz normal arbeitet. Edge Microgateway-Instanz, die den API-Proxy-Traffic verarbeitet, und die Instanz erhält seine Konfigurationsdaten aus der Redis-Datenbank.

edgemicro:
  redisHost: host_IP
  redisPort: host_port
  redisDb: database_index
  redisPassword: password
edge_config:
  synchronizerMode: 0
  redisBasedConfigCache: true

Beispiel:

edgemicro:
  redisHost: 192.168.4.77
  redisPort: 6379
  redisDb: 0
  redisPassword: codemaster
edge_config:
  synchronizerMode: 0
  redisBasedConfigCache: true

Konfigurationsattribute

Die folgenden Konfigurationseigenschaften wurden hinzugefügt, um die Verwendung des Synchronisierers zu unterstützen:

Ausschluss-URLs für Plug-ins konfigurieren

Sie können das Mikrogateway so konfigurieren, dass die Verarbeitung von Plug-ins für angegebenen URLs. Sie können diese „ausschließen“ URLs weltweit (für alle Plug-ins) oder für bestimmte Plug-ins.

Beispiel:

...
edgemicro:
  ...
  plugins:
    excludeUrls: '/hello,/proxy_one' # global exclude urls
    sequence:
      - oauth
      - json2xml
      - quota
json2xml:
  excludeUrls: '/hello/xml'  # plugin level exclude urls
...

In diesem Beispiel verarbeiten Plug-ins keine eingehenden API-Proxy-Aufrufe mit dem Pfad /hello oder /proxy_one. Außerdem enthält die json2xml wird das Plug-in für APIs mit /hello/xml im Pfad übersprungen.

Konfigurationsattribute mit Werten von Umgebungsvariablen festlegen

Sie können Umgebungsvariablen mithilfe von Tags in der Konfiguration angeben -Datei. Die angegebenen Umgebungsvariablen-Tags werden durch die tatsächliche Umgebung ersetzt. Variablenwerte. Ersatzgeräte werden nur im Arbeitsspeicher gespeichert, nicht im Original Konfigurations- oder Cache-Dateien.

In diesem Beispiel wird das Attribut key durch den Wert des TARGETS_SSL_CLIENT_KEY usw.

targets:
  - ssl:
      client:
        key: <E>TARGETS_SSL_CLIENT_KEY</E>
        cert: <E>TARGETS_SSL_CLIENT_CERT</E>
        passphrase: <E>TARGETS_SSL_CLIENT_PASSPHRASE</E>

In diesem Beispiel wird das Tag <n> verwendet, um einen ganzzahligen Wert anzugeben. Nur positive Ganzzahlen unterstützt werden.

edgemicro:
  port: <E><n>EMG_PORT</n></E>

In diesem Beispiel wird das <b>-Tag verwendet, um einen booleschen Wert ( wahr oder false).

quotas:
  useRedis: <E><b>EMG_USE_REDIS</b></E>