Questa pagina è stata tradotta dall'API Cloud Translation.

Riferimento per le operazioni e la configurazione di Edge Microgateway

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

Edge Microgateway versione 3.3.x

Questo argomento illustra come gestire e configurare Edge Microgateway.

Upgrade di Edge Microgateway se disponi di una connessione a internet

Questa sezione spiega come eseguire l'upgrade di un'installazione esistente di Edge Microgateway. Se non disponi di una connessione Internet, vedi Posso installare Edge Microgateway senza una connessione a internet?.

Apigee consiglia di testare la configurazione esistente con la nuova versione prima di eseguire l'upgrade dell'ambiente di produzione.

Esegui questo comando npm per eseguire l'upgrade alla versione più recente di Edge Microgateway:
```
npm upgrade edgemicro -g
```
Per installare una versione specifica di Edge Microgateway, devi specificare la versione numero nel comando di installazione. Ad esempio, per eseguire l'installazione nella versione 3.2.3, utilizza la seguente comando:
```
npm install edgemicro@3.2.3 -g
```

Controlla il numero di versione. Ad esempio, se hai installato la versione 3.2.3:

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

Infine, esegui l'upgrade alla versione più recente del proxy edgemicro-auth:
```
edgemicro upgradeauth -o $ORG -e $ENV -u $USERNAME
```

Apportare modifiche alla configurazione

I file di configurazione che devi conoscere includono:

File di configurazione di sistema predefinito
File di configurazione predefinito per un'istanza Edge Microgateway appena inizializzata
File di configurazione dinamica per l'esecuzione delle istanze

Questa sezione illustra questi file e tutto ciò che devi sapere sulla loro modifica.

Configurazione di sistema predefinita file

Quando installi Edge Microgateway, viene inserito un file di configurazione di sistema predefinito qui:

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

Dove prefix è la directory del prefisso npm. Vedi Dov'è installato Edge Microgateway se non riesci a trovare questa directory.

Se modifichi il file di configurazione di sistema, devi reinizializzare, riconfigurare e riavviare Edge Microgateway:

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

File di configurazione predefinito per le istanze Edge Microgateway appena inizializzate

Quando esegui edgemicro init, il file di configurazione del sistema (descritto sopra), default.yaml, si trova nella directory ~/.edgemicro.

Se modifichi il file di configurazione in ~/.edgemicro, devi riconfigurarlo e riavviarlo Microgateway Edge:

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

Dinamico del file di configurazione per l'esecuzione delle istanze

Quando esegui edgemicro configure [params], viene generata una query viene creato in ~/.edgemicro. Il file è denominato in questo modo pattern: org-env-config.yaml, dove org e env sono i nomi dell'organizzazione e dell'ambiente Apigee Edge. Puoi utilizzare questo file per configurare modifiche e quindi ricaricarle senza tempi di inattività. Ad esempio, se aggiungi e configuri un plug-in, puoi ricaricare la configurazione senza tempi di inattività, come spiegato di seguito.

Se Edge Microgateway è in esecuzione (opzione senza tempo di inattività):

Ricarica la configurazione di Edge Microgateway:
```
edgemicro reload -o $ORG -e $ENV -k $KEY -s $SECRET
```
Dove:
- $ORG è il nome della tua organizzazione Edge (devi essere un'organizzazione) amministratore).
- $ENV è un ambiente della tua organizzazione (ad esempio "test" o "prod").
- $KEY è la chiave restituita in precedenza dal comando di configurazione.
- $SECRET è la chiave restituita in precedenza dal comando di configurazione.
Ad esempio:
```
edgemicro reload -o docs -e test -k 701e70ee718ce6dc188...78b6181d000723 \
  -s 05c14356e42ed1...4e34ab0cc824
```

Se Edge Microgateway viene arrestato:

Riavvia Edge Microgateway:
```
edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET
```
Dove:
- $ORG è il nome della tua organizzazione Edge (devi essere un'organizzazione) amministratore).
- $ENV è un ambiente della tua organizzazione (ad esempio "test" o "prod").
- $KEY è la chiave restituita in precedenza dal comando di configurazione.
- $SECRET è la chiave restituita in precedenza dal comando di configurazione.
Ad esempio:
```
edgemicro start -o docs -e test -k 701e70ee718ce...b6181d000723 \
  -s 05c1435...e34ab0cc824
```

Ecco un esempio di file di configurazione. Per maggiori dettagli sulle impostazioni del file di configurazione, consulta Riferimento per la configurazione di 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

Imposta le variabili di ambiente

I comandi dell'interfaccia a riga di comando che richiedono valori per l'organizzazione Edge e di sicurezza, la chiave e il segreto necessari per avviare Edge Microgateway possono essere archiviati in variabili di ambiente:

EDGEMICRO_ORG
EDGEMICRO_ENV
EDGEMICRO_KEY
EDGEMICRO_SECRET

L'impostazione di queste variabili è facoltativa. Se le imposti, non devi specificarne i valori quando utilizzi l'interfaccia a riga di comando (CLI) per configurare e avviare Edge Microgateway.

Configurazione di SSL su Edge Microgateway server

Guarda i video seguenti per scoprire di più sulla configurazione di TLS in Apigee Edge Microgateway:

Video	Descrizione
Configurare TLS unidirezionale verso nord	Scopri come configurare TLS in Apigee Edge Microgateway. Questo video offre una panoramica di TLS e della sua importanza, presentando TLS in Edge Microgateway e dimostra come configurare il TLS unidirezionale verso nord.
Configurare il protocollo TLS bidirezionale verso nord	Questo è il secondo video sulla configurazione di TLS in Apigee Edge Microgateway. Questo il video spiega come configurare il protocollo TLS bidirezionale in direzione nord.
Configurare il protocollo TLS unidirezionale e bidirezionale verso sud	Il terzo video sulla configurazione di TLS in Apigee Edge Microgateway spiega come configurare il TLS unidirezionale e bidirezionale verso sud.

Puoi configurare il server Microgateway per l'utilizzo di SSL. Ad esempio, con SSL configurato, può chiamare le API tramite Edge Microgateway con il prefisso "https" in questo modo:

https://localhost:8000/myapi

Per configurare SSL sul server Microgateway, segui questi passaggi:

Genera o ottieni un certificato e una chiave SSL utilizzando l'utilità openssl o il metodo che preferisci.

Aggiungi l'attributo edgemicro:ssl al file di configurazione di Edge Microgateway. Per un elenco di opzioni, consulta la tabella seguente. Ad esempio:

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

Riavvia Edge Microgateway. Segui i passaggi descritti in Apportare modifiche alla configurazione in base al tipo di configurazione modificato: il file predefinito o il file di configurazione del runtime.

Ecco un esempio della sezione edgemicro del file di configurazione, con SSL configurato:

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

Ecco un elenco di tutte le opzioni server supportate:

Opzione	Descrizione
`key`	Percorso di un file `ca.key` (in formato PEM).
`cert`	Percorso di un file `ca.cert` (in formato PEM).
`pfx`	Percorso di un file `pfx` contenente la chiave privata, il certificato e i certificati CA del client in formato PFX.
`passphrase`	Una stringa contenente la passphrase per la chiave privata o PFX.
`ca`	Percorso di un file contenente un elenco di certificati attendibili in formato PEM.
`ciphers`	Una stringa che descrive le crittografie da utilizzare separate da un ":".
`rejectUnauthorized`	Se impostato su true, il certificato del server viene verificato in base all'elenco di CA fornite. Se la verifica non va a buon fine, viene restituito un errore.
`secureProtocol`	Il metodo SSL da utilizzare. Ad esempio, SSLv3_method per forzare SSL nella versione 3.
`servername`	Il nome del server per l'estensione TLS SNI (Server Name Indication).
`requestCert`	true per SSL a 2 vie; false per SSL unidirezionale

Utilizzo delle opzioni SSL/TLS client

Puoi configurare Edge Microgateway come client TLS o SSL quando ti connetti alla destinazione endpoint. Nel file di configurazione di Microgateway, utilizza l'elemento target per impostare SSL/TLS le opzioni di CPU e memoria disponibili. Tieni presente che puoi specificare più target specifici. È incluso un esempio di più target di seguito.

Questo esempio fornisce le impostazioni che verranno applicate a tutti gli host:

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 questo esempio, le impostazioni vengono applicate solo all'host specificato:

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

Ecco un esempio per TLS:

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

Se vuoi applicare le impostazioni TLS/SSL a più destinazioni specifiche, devi specificare il primo host nella configurazione come "vuoto", che consente richieste universali, quindi specifica specifici host in qualsiasi ordine. In questo esempio, le impostazioni vengono applicate a più host specifici:

targets:
 - host:   ## Note that this value must be "empty"
   ssl:
     client:
       key: /Users/myname/twowayssl/ssl/client.key
       cert: /Users/myname/twowayssl/ssl/ca.crt
       passphrase: admin123
       rejectUnauthorized: true
 - host: 'myserver1.example.com'
   ssl:
     client:
       key: /Users/myname/twowayssl/ssl/client.key
       cert: /Users/myname/twowayssl/ssl/ca.crt
       rejectUnauthorized: true
 - host: 'myserver2.example.com'
   ssl:
     client:
       key: /Users/myname/twowayssl/ssl/client.key
       cert: /Users/myname/twowayssl/ssl/ca.crt
       rejectUnauthorized: true

Ecco un elenco di tutte le opzioni client supportate:

Opzione	Descrizione
`pfx`	Percorso di un file `pfx` contenente la chiave privata, il certificato e i certificati CA del client in formato PFX.
`key`	Percorso di un file `ca.key` (in formato PEM).
`passphrase`	Una stringa contenente la passphrase per la chiave privata o PFX.
`cert`	Percorso di un file `ca.cert` (in formato PEM).
`ca`	Percorso di un file contenente un elenco di certificati attendibili in formato PEM.
`ciphers`	Una stringa che descrive le crittografie da utilizzare separate da un ":".
`rejectUnauthorized`	Se impostato su true, il certificato del server viene verificato in base all'elenco di CA fornite. Se la verifica non va a buon fine, viene restituito un errore.
`secureProtocol`	Il metodo SSL da utilizzare. Ad esempio, SSLv3_method per forzare SSL nella versione 3.
`servername`	Il nome del server per l'estensione TLS SNI (Server Name Indication).

Personalizzazione del proxy edgemicro-auth

Per impostazione predefinita, Edge Microgateway utilizza un proxy di cui è stato eseguito il deployment su Apigee Edge per l'autenticazione OAuth2. Il deployment di questo proxy è stato eseguito quando esegui la prima esecuzione di edgemicro configure. Puoi modificare la configurazione predefinita di questo proxy per aggiungere il supporto per le attestazioni personalizzate a un token web JSON (JWT), configurare la scadenza del token e generare token di aggiornamento. Per maggiori dettagli, consulta la pagina edgemicro-auth su GitHub.

Utilizzo di un servizio di autenticazione personalizzato

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

Se vuoi utilizzare un tuo servizio personalizzato per gestire l'autenticazione, modifica il authUri nel file di configurazione in modo che punti al tuo servizio. Ad esempio, potresti avere un servizio che usa LDAP per verificare l'identità.

Importante: se esegui l'override dell'autorizzazione predefinita proxy, il nuovo proxy o servizio deve restituire un formato di risposta identico a quello predefinito proxy edgemicro-auth.

Gestione dei file di log

Edge Microgateway registra le informazioni su ogni richiesta e risposta. I file di log forniscono utili informazioni per il debug e la risoluzione dei problemi.

Dove vengono archiviati i file di log

Per impostazione predefinita, i file di log vengono archiviati in /var/tmp.

Come modificare il log predefinito directory dei file

La directory in cui sono archiviati i file di log è specificata nella configurazione di Edge Microgateway . Consulta anche la sezione modifiche.

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

Modifica il valore dir in modo da specificare una directory diversa per il file di log.

Invia i log alla console

Puoi configurare il logging in modo che le informazioni di log vengano inviate all'output standard anziché a un di log. Imposta il flag to_console su true in questo modo:

edgemicro:
  logging:
    to_console: true

Con questa impostazione, i log verranno inviati all'uscita standard. Al momento, non puoi inviare log a entrambi stdout e in un file di log.

Come impostare il livello di logging

Devi specificare il livello di log da utilizzare nella configurazione edgemicro. Per un per l'elenco completo dei livelli di log e delle relative descrizioni, vedi attributi edgemicro.

Ad esempio, la seguente configurazione imposta il livello di logging su debug:

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

Come modificare gli intervalli di log

Puoi configurare questi intervalli nel file di configurazione di Edge Microgateway. Vedi anche Apportare modifiche alla configurazione.

Gli attributi configurabili sono:

stats_log_interval: (valore predefinito: 60): intervallo, in secondi, quando le statistiche viene scritto nel file di log dell'API.
rotate_interval: (valore predefinito: 24) intervallo, in ore, quando i file di log vengono ruotato. Ad esempio:

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

Come concedere autorizzazioni rigide per i file di log

Per impostazione predefinita, Edge Microgateway genera il file di log dell'applicazione (api-log.log) con l'autorizzazione del file impostato su 0600. Questo livello di autorizzazione non consente applicazioni o utenti esterni per leggere il file di log. Per ridurre questo livello di autorizzazione rigorosa, imposta logging:disableStrictLogFile a true. Se questo attributo è true, il file di log viene creato con il permesso del file è impostato su 0755. Se false o se l'attributo non viene fornito, il valore predefinito per l'autorizzazione è 0600.

Aggiunta nella versione 3.2.3.

Ad esempio:

edgemicro:
 logging:
   disableStrictLogFile: true

Buone pratiche di manutenzione del file di log

Man mano che i dati dei file di log si accumulano nel tempo, Apigee consiglia di adottare quanto segue pratiche:

Dato che i file di log possono diventare piuttosto grandi, assicurati che la directory del file di log spazio a sufficienza. Consulta le seguenti sezioni: Dove vengono archiviati i file di log e Come modificare il file di log predefinito? .
Eliminare o spostare i file di log in una directory di archivio separata almeno una volta alla settimana.
Se il tuo criterio prevede l'eliminazione dei log, puoi utilizzare il comando dell'interfaccia a riga di comando edgemicro log -c per rimuovere (pulire) i log meno recenti.

Convenzione di denominazione dei file di log

Ogni istanza di Edge Microgateway produce un file di log con estensione .log. La di denominazione per i file di log è la seguente:

edgemicro-HOST_NAME-INSTANCE_ID-api.log

Ad esempio:

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log

Informazioni sui contenuti dei file di log

Aggiunto in: versione 2.3.3

Per impostazione predefinita, il servizio di logging omette il codice JSON dei proxy, dei prodotti e dei file JSON scaricati token web (JWT). Se vuoi inviare questi oggetti alla console, imposta il flag della riga di comando DEBUG=* all'avvio di Edge Microgateway. Ad esempio:

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

Su Windows, utilizza SET DEBUG=*

Contenuti dell'"api" file di log

L'"API" Il file di log contiene informazioni dettagliate sul flusso di richieste e risposte attraverso Edge Microgateway. L'"API" i file di log hanno il seguente nome:

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

Per ogni richiesta effettuata a Edge Microgateway, nell'API vengono acquisiti quattro eventi registrare file:

Richiesta in entrata dal client
Richiesta in uscita inviata alla destinazione
Risposta in arrivo dal target
Risposta in uscita al client

Ognuna di queste voci separate è rappresentata da una notazione abbreviata per aiutarti a rendere il log è più compatta. Ecco quattro voci di esempio che rappresentano ciascuno dei quattro eventi. Nel log file avranno il seguente aspetto (i numeri di riga servono solo come riferimento nel documento, non nel file di log).

(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

Vediamoli uno alla volta:

1. Esempio di richiesta in entrata dal client:

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

1436403888651 - Timbro data Unix
informazioni - Il livello di registrazione nel log. Questo valore dipende dal contesto della transazione e dal livello di logging impostato nella configurazione edgemicro. Consulta Come impostare il livello di logging. Per i record delle statistiche, il livello è impostato su stats. I record delle statistiche sono riportati in un intervallo regolare impostato con la configurazione stats_log_interval. Vedi anche Come modificare gli intervalli di log.
req: identifica l'evento. In questo caso, la richiesta da parte di alto profilo.
m - Il verbo HTTP utilizzato nella richiesta.
u - La parte dell'URL che segue il percorso di base.
h - L'host e il numero di porta dove si trova Edge Microgateway in ascolto.
r: l'host remoto e la porta in cui la richiesta del client ha avuto origine.
i: l'ID richiesta. Tutte e quattro le voci degli eventi condividono questo ID. Ciascuna alla richiesta viene assegnato un ID richiesta univoco. La correlazione dei record dei log per ID richiesta insight preziosi sulla latenza del target.
d: il tempo in millisecondi trascorso da quando la richiesta è stata ricevuta da Microgateway Edge. Nell'esempio precedente, la risposta del target per la richiesta 0 è stata ricevuta dopo 7 millisecondi (riga 3) e la risposta è stata inviata al client dopo altre 4 millisecondi (riga 4). In altre parole, la latenza totale della richiesta è stata di 11 millisecondi, su quali 7 millisecondi sono stati presi dal target e 4 millisecondi da Edge Microgateway per trovare le regole.

2. Esempio di richiesta in uscita inviata alla destinazione:

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

1436403888651 - Timbro data Unix
informazioni - Il livello di registrazione nel log. Questo valore dipende dal contesto della transazione e dal livello di logging impostato nella configurazione edgemicro. Consulta Come impostare il livello di logging. Per i record delle statistiche, il livello è impostato su stats. I record delle statistiche sono riportati in un intervallo regolare impostato con la configurazione stats_log_interval. Vedi anche Come modificare gli intervalli di log.
treq - Identifica l'evento. In questo caso, richiesta target.
m - Il verbo HTTP utilizzato nella richiesta di destinazione.
u - La parte dell'URL che segue il percorso di base.
h - L'host e il numero di porta del target del backend.
i - L'ID della voce di log. Tutte e quattro le voci dell'evento condivideranno ID.

3. Esempio di risposta in arrivo dal target

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

1436403888651 - Timbro data Unix

informazioni - Il livello di registrazione nel log. Questo valore dipende dal contesto della transazione e dal livello di logging impostato nella configurazione edgemicro. Consulta Come impostare il livello di logging. Per i record delle statistiche, il livello è impostato su stats. I record delle statistiche sono riportati in un intervallo regolare impostato con la configurazione stats_log_interval. Vedi anche Come modificare gli intervalli di log.
tres - Identifica l'evento. In questo caso, la risposta target.
s - Lo stato della risposta HTTP.
d: la durata in millisecondi. Il tempo impiegato per la chiamata API da l'obiettivo.
i - L'ID della voce di log. Tutte e quattro le voci dell'evento condivideranno ID.

4. Esempio di risposta in uscita inviata al client

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

1436403888651 - Timbro data Unix

informazioni - Il livello di registrazione nel log. Questo valore dipende dal contesto della transazione e dal livello di logging impostato nella configurazione edgemicro. Consulta Come impostare il livello di logging. Per i record delle statistiche, il livello è impostato su stats. I record delle statistiche sono riportati in un intervallo regolare impostato con la configurazione stats_log_interval. Vedi anche Come modificare gli intervalli di log.
res - Identifica l'evento. In questo caso, la risposta alla richiesta di alto profilo.
s - Lo stato della risposta HTTP.
d: la durata in millisecondi. Questo è il tempo totale impiegato dalla chiamata API, incluso il tempo impiegato dall'API target e il tempo impiegato da Edge Il microgateway stesso.
i - L'ID della voce di log. Tutte e quattro le voci dell'evento condivideranno ID.

Pianificazione file di log

I file di log vengono ruotati in base all'intervallo specificato dalla funzione rotate_interval di configurazione. Le voci continueranno a essere aggiunte al stesso file di log fino alla scadenza dell'intervallo di rotazione. Tuttavia, ogni volta che Edge Microgateway riavviato, riceve un nuovo UID e crea un nuovo set di file di log con questo UID. Vedi anche Buona manutenzione del file di log pratiche.

Messaggi di errore

Alcune voci di log conterranno messaggi di errore. Per identificare meglio dove e perché si verificano gli errori, vedi l'errore Edge Microgateway riferimento.

Riferimento per la configurazione di Edge Microgateway

Località del file di configurazione

Gli attributi di configurazione descritti in questa sezione si trovano nel Microgateway Edge di configurazione del deployment. Consulta anche la sezione modifiche.

Attributi edge_config

Queste impostazioni vengono utilizzate per configurare l'interazione tra l'istanza Edge Microgateway e Apigee Edge

bootstrap: (impostazione predefinita: nessuno) un URL che indirizza a un perimetro Servizio specifico del microgateway in esecuzione su Apigee Edge. Edge Microgateway utilizza questo servizio per comunicare con Apigee Edge. Questo URL viene restituito quando esegui il comando per generare coppia di chiavi pubblica/privata: edgemicro genkeys. Consulta la Guida di riferimento e configurazione di Edge Microgateway per maggiori dettagli.
jwt_public_key: (valore predefinito: nessuno) un URL che rimanda al Microgateway Edge di cui viene eseguito il deployment su Apigee Edge. Questo proxy funge da endpoint di autenticazione per mediante l'emissione di token di accesso firmati ai client. Questo URL viene restituito quando esegui il comando per per il deployment del proxy: edgemicro configure. Consulta la Guida di riferimento e configurazione di Edge Microgateway per maggiori dettagli.
quotaUri: imposta questa configurazione se vuoi gestire le quote tramite il proxy edgemicro-auth, di cui è stato eseguito il deployment nella tua organizzazione. Se questa proprietà non è impostata, Per impostazione predefinita, l'endpoint della quota è l'endpoint interno di Edge Microgateway.
```
edge_config:
  quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
```

attributi edgemicro

Queste impostazioni configurano il processo Edge Microgateway.

port: (valore predefinito: 8000) il numero di porta sul quale il Microgateway Edge di ascolto dei processi.
max_connections: (valore predefinito: -1) specifica il numero massimo di connessioni in entrata simultanee che Edge Microgateway può ricevere. Se questo numero è superato, viene restituito il seguente stato:

res.statusCode = 429; // Too many requests
max_connections_hard: (valore predefinito: -1) il numero massimo di connessioni simultanee richieste che Edge Microgateway può ricevere prima di arrestare la connessione. Questa impostazione ha lo scopo di contrastare gli attacchi denial of service. In genere, imposta il valore su un numero maggiore di max_connections.
logging:
- level: (predefinito: errore)
  - informazioni - (consigliato): registra tutte le richieste e le risposte che passano attraverso un Istanza Edge Microgateway.
  - warn - Registra solo i messaggi di avviso.
  - error: registra solo i messaggi di errore.
  - debug: registra i messaggi di debug insieme a messaggi informativi, di avviso ed errore.
  - trace - Registra le informazioni di traccia degli errori, oltre a informazioni, avvisi e messaggi di errore.
  - none: non creare un file di log.
- dir: (predefinito: /var/tmp) la directory in cui vengono messi a disposizione i file di log archiviati.
- stats_log_interval: (valore predefinito: 60): intervallo, in secondi, quando le statistiche viene scritto nel file di log dell'API.
- rotate_interval: (valore predefinito: 24) intervallo, in ore, quando i file di log vengono ruotato.

plugins: i plug-in aggiungono funzionalità a Edge Microgateway. Per maggiori dettagli sullo sviluppo di plug-in, consulta l'articolo Sviluppare plug-in personalizzati.

dir: un percorso relativo dalla directory ./gateway alla ./plugins o un percorso assoluto.
Sequenza: un elenco di moduli di plug-in da aggiungere a Edge Microgateway in esecuzione in un'istanza Compute Engine. I moduli verranno eseguiti nell'ordine in cui sono specificati qui.

Debug: aggiunge il debug remoto al processo Edge Microgateway.
- port: il numero di porta su cui rimanere in ascolto. Ad esempio, imposta il debugger IDE per rimanere in ascolto su questa porta.
- args: argomenti del processo di debug. Ad esempio: args --nolazy
config_change_poll_interval: (valore predefinito: 600 secondi) Edge Microgateway carica periodicamente una nuova configurazione ed esegue un ricaricamento se è stato modificato. Il sondaggio rileva eventuali modifiche apportate su Edge (modifiche ai prodotti, ai proxy sensibili al microgateway e così via) come nonché le modifiche apportate al file di configurazione locale.
disable_config_poll_interval: (valore predefinito: false). Imposta su true per disattivare la modifica automatica del polling.
request_timeout: imposta un timeout per le richieste target. Il timeout è impostato in secondi. Se si verifica un timeout, Edge Microgateway risponde con un codice di stato 504. (Aggiunta v2.4.x)
keep_alive_timeout: questa proprietà consente di impostare il Microgateway Edge (in millisecondi). (Predefinito: 5 secondi) (Aggiunta v3.0.6)
headers_timeout: questo attributo limita la quantità di tempo (in millisecondi) il parser HTTP attenderà di ricevere intestazioni HTTP complete.
Ad esempio:
```
edgemicro:
  keep_alive_timeout: 6000
  headers_timeout: 12000
```
Internamente, il parametro imposta il valore Node.js Server.headersTimeout nelle richieste. (valore predefinito: 5 secondi in più di l'orario impostato con edgemicro.keep_alive_timeout. Questo valore predefinito impedisce ai bilanciatori del carico o ai proxy di interrompere per errore la connessione.) (Aggiunta la versione 3.1.1)
noRuleMatchAction: (stringa) l'azione da intraprendere (consentire o negare l'accesso) se la regola di corrispondenza specificata nel plug-in accesscontrol non è stata risolta (non corrisponde). Valori validi: ALLOW o DENY Predefinito: ALLOW (aggiunta: v3.1.7)
enableAnalytics:: (default: true) imposta l'attributo su enableAnalytics: su impedire il plug-in di Analytics dei carichi di lavoro. In questo caso, non verranno effettuate chiamate alle analisi di Apigee Edge. Se impostato su true oppure quando questo attributo non è fornito, il plug-in di Analytics funzionerà come di consueto. Consulta attributi edgemicro per i dettagli. (Aggiunta la versione 3.1.8).
Esempio:
```
edgemicro
  enableAnalytics=false|true
```
Se enableAnalytics è impostato su false, ma Edge Microgateway inizia a utilizzare il plug-in delle metriche, quindi il plug-in di Analytics funzionerà come di consueto. perché il plug-in delle metriche richiede il plug-in di analisi per funzionare. Per informazioni su il plug-in delle metriche, consulta Edge Microgateway v1.3.6 note di rilascio.

on_target_response_abort: questo attributo consente di controllare come si comporta Edge Microgateway se la connessione tra il client (Edge Microgateway) e il il server di destinazione si chiude prematuramente.

Valore	Descrizione
Predefinito	Se `on_target_response_abort` non è specificato, il comportamento predefinito è troncare la risposta senza mostrare un errore. Nei file di log, viene visualizzato viene mostrato con `targetResponse aborted` e un codice di risposta 502.
`appendErrorToClientResponseBody`	L'errore personalizzato `TargetResponseAborted` viene restituito di alto profilo. Nei file di log, viene visualizzato viene mostrato con `targetResponse aborted` e un codice di risposta 502. Nella Inoltre, l'errore `TargetResponseAborted` viene registrato insieme al messaggio `Target response ended prematurely.`
`abortClientRequest`	Edge Microgateway interrompe la richiesta e viene scritto un avviso nei file di log: `TargetResponseAborted` con il codice di stato della richiesta 502.

Esempio:

edgemicro:
 on_target_response_abort: appendErrorToClientResponseBody | abortClientRequest

attributi header

Queste impostazioni configurano il modo in cui vengono trattate determinate intestazioni HTTP.

x-forwarded-for: (impostazione predefinita: true). Imposta su false per evitare x-forwarded-for da passare alla destinazione. Tieni presente che se un'intestazione x-forwarded-for nella richiesta, il suo valore verrà impostato sul valore client-ip in Edge Analytics.
x-forwarded-host: (predefinito: true). Imposta su false per evitare intestazioni x-forwarded-host da passare alla destinazione.
x-request-id: (default: true) impostato su false per evitare intestazioni x-request-id da passare alla destinazione.
x-response-time: (default: true) su false per evitare intestazioni x-response-time da passare alla destinazione.
via: (default: true) Imposta su false per impedire che tramite le intestazioni venga passati al target.

attributi OAuth

Queste impostazioni configurano il modo in cui l'autenticazione client viene applicata da Edge Microgateway.

allowNoAuthorization: (impostazione predefinita: false) Se viene impostato su true, le chiamate API vengono autorizzati a passare attraverso Edge Microgateway senza alcuna intestazione di autorizzazione. Impostalo su false per richiedere un'intestazione Autorizzazione (impostazione predefinita).
allowInvalidAuthorization (predefinito: false) Se impostato su true, le chiamate API vengono possono essere trasmessi se il token passato nell'intestazione Autorizzazione non è valido o è scaduto. Imposta questo su false per richiedere token validi (impostazione predefinita).
Authorization-header (impostazione predefinita: Authorization: Bearer) L'intestazione utilizzata per per inviare il token di accesso a Edge Microgateway. Ti consigliamo di modificare l'impostazione predefinita nei casi in cui la destinazione deve utilizzare l'intestazione Autorizzazione per altri scopi.
api-key-header: (predefinito: x-api-key) il nome dell'intestazione o della query utilizzato per passare una chiave API a Edge Microgateway. Vedi anche Utilizzo dell'opzione una chiave API.
keep-authorization-header: (default: false): se il valore è impostato su true, l'intestazione Authorization inviate nella richiesta vengono passate alla destinazione (vengono mantenute).
allowOAuthOnly: se impostato su true, ogni API deve avere un'autorizzazione con un token di accesso a connessione. Ti permette di autorizzare solo il modello di sicurezza OAuth (mentre mantenendo la compatibilità con le versioni precedenti). (Aggiunta la versione 2.4.x)
allowAPIKeyOnly: se impostato su true, ogni API deve includere un parametro x-api-key (o una posizione personalizzata) con una chiave API.Ti permette di autorizzare solo il modello di sicurezza della chiave API (pur mantenendo la compatibilità con le versioni precedenti). (Aggiunta la versione 2.4.x)
Non impostare sia allowOAuthOnly sia allowAPIKeyOnly su true. L'impostazione predefinita è che entrambi i flag sono impostati su false (per la compatibilità con le versioni precedenti).
gracePeriod: questo parametro consente di evitare errori causati da lievi discrepanze tra l'orologio di sistema e gli orari Non prima (nbf) o Emesso alle (iat) specificato nel token di autorizzazione JWT. Imposta questo parametro sul numero di secondi per consentire per individuare tali discrepanze. (Aggiunta la sezione 2.5.7)

Specifico per i plug-in attributi

Per informazioni dettagliate sugli attributi configurabili di ciascun plug-in, consulta la sezione Utilizzo dei plug-in.

Proxy di filtro

Puoi filtrare i proxy sensibili al microgateway che verranno elaborati da un'istanza Edge Microgateway. All'avvio di Edge Microgateway, scarica tutti i proxy sensibili al microgateway all'interno dell'organizzazione a cui è associato. Utilizza la seguente configurazione per limitare i proxy che verrà elaborato dal microgateway. Ad esempio, questa configurazione limita i proxy del microgateway verranno elaborati in tre: edgemicro_proxy-1, edgemicro_proxy-2, e edgemicro_proxy-3:

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

Filtro dei prodotti per nome

Utilizza la seguente configurazione per limitare il numero di prodotti API che Edge Microgateway per i download e i processi. Per filtrare i prodotti scaricati, aggiungi productnamefilter parametro di query all'API /products elencata nel gateway in Edge Microgateway *.config.yaml . Ad esempio:

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'

Tieni presente che il valore del parametro di query deve essere specificato nel formato di espressione regolare e essere codificato nell'URL. Ad esempio, l'espressione regolare ^[Ee]dgemicro.*$ rileva nomi come: "edgemicro-test-1" , "edgemicro_demo" e "Edgemicro_New_Demo". Il valore codificato nell'URL, adatto a nel parametro di query è: %5E%5BEe%5Ddgemicro.%2A%24.

Il seguente output di debug mostra che sono stati scaricati solo i prodotti filtrati:

...
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":[

         ]
      }
   ]
}

Filtrare i prodotti in base ad attributi personalizzati

Per filtrare i prodotti in base ad attributi personalizzati:

Nella UI di Edge, seleziona il proxy edgemicro_auth nell'organizzazione/nell'ambiente in cui hai configurato Edge Microgateway.
Nel tocco Sviluppo, apri il criterio Callout Java nell'editor.
Aggiungi un attributo personalizzato con la chiave products.filter.attributes separata da virgole dei nomi degli attributi. Solo i prodotti che contengono uno dei nomi di attributi personalizzati verrà restituito a Edge Microgateway.
Se vuoi, puoi disattivare il controllo per vedere se il prodotto è abilitato per l'ambiente attuale impostando attributo personalizzato products.filter.env.enable a false. Il valore predefinito è true.
(Solo Private Cloud) Se ti trovi su Edge per Private Cloud, imposta la proprietà Da org.noncps a true per eseguire il pull dei prodotti per ambienti non CPS.

Ad esempio:

<?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>

Configurazione della frequenza di push di Analytics

Utilizza questi parametri di configurazione per controllare la frequenza di invio di Edge Microgateway di dati di analisi in Apigee:

(Facoltativo) bufferSize: il numero massimo di record di analisi che il buffer può rimanere in attesa prima di iniziare a eliminare i record meno recenti. Valore predefinito: 10000
(Facoltativo) batchSize: la dimensione massima di un batch di record di analisi inviate ad Apigee. Valore predefinito: 500
flushInterval (facoltativo): il numero di millisecondi tra ogni svuotamento di un batch di record di analisi inviati ad Apigee. Valore predefinito: 5000

Ad esempio:

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

Mascheramento dei dati di analisi

La seguente configurazione impedisce la visualizzazione delle informazioni sul percorso di richiesta in Edge Analytics. Aggiungi quanto segue alla configurazione del microgateway per mascherare l'URI della richiesta e/o del percorso di richiesta. Tieni presente che l'URI è costituito dalle parti del nome host e del percorso della richiesta.

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

Separazione delle chiamate API in Edge Analytics

Puoi configurare il plug-in di Analytics in modo da separare un percorso API specifico in modo che venga visualizzato un proxy separato nelle dashboard di analisi perimetrale. Ad esempio, puoi isolare un'API per il controllo di integrità nella dashboard per evitare di confonderla con le effettive chiamate proxy API. Nella La dashboard di Analytics e i proxy separati seguono questo schema di denominazione:

edgemicro_proxyname-health

La seguente immagine mostra due proxy separati nella dashboard di Analytics: edgemicro_hello-health e edgemicro_mock-health:

Utilizza questi per separare i percorsi relativi e assoluti nella dashboard di Analytics come proxy separati:

(Facoltativo) relativePath: specifica un percorso relativo da separare nel campo la dashboard di Analytics. Ad esempio, se specifichi /healthcheck, tutte le chiamate API contenenti il percorso /healthcheck verrà visualizzato nella dashboard come edgemicro_proxyname-health. Tieni presente che questo flag ignora il percorso base del proxy. Per separare in base a un percorso completo, incluso il percorso di base, utilizza il flag proxyPath.
proxyPath (facoltativo): specifica un percorso proxy API completo, incluso il proxy basepath, da separare nella dashboard di Analytics. Ad esempio, se specifichi /mocktarget/healthcheck, dove /mocktarget è il percorso di base del proxy, tutte le chiamate API con il percorso /mocktarget/healthcheck sono visualizzati nella dashboard come edgemicro_proxyname-health.

Ad esempio, nella configurazione seguente, qualsiasi percorso API contenente /healthcheck essere separate dal plug-in di Analytics. Ciò significa che /foo/healthcheck e /foo/bar/healthcheck verrà separato come proxy separato denominato edgemicro_proxyname-health nella dashboard di Analytics.

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

Nella configurazione seguente, qualsiasi API con il percorso proxy /mocktarget/healthcheck verranno segregate come proxy separato con nome edgemicro_proxyname-health in la dashboard di Analytics.

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

Configurazione di Edge Microgateway dietro un firewall aziendale

Utilizza un proxy HTTP per la comunicazione con Apigee Edge

Aggiunta nella versione 3.1.2.

Per utilizzare un proxy HTTP per la comunicazione tra Edge Microgateway e Apigee Edge, esegui la seguenti:

Impostare le variabili di ambiente HTTP_PROXY, HTTPS_PROXY e NO_PROXY. Questi controllano gli host per ogni proxy HTTP che vuoi utilizzare per la comunicazione Apigee Edge, o gli host che non dovrebbero gestire la comunicazione con Apigee Edge. Ad esempio:
```
export HTTP_PROXY='http://localhost:3786'
export HTTPS_PROXY='https://localhost:3786'
export NO_PROXY='localhost,localhost:8080'
```
Tieni presente che NO_PROXY può essere un elenco di domini delimitato da virgole di cui Edge Microgateway che non deve inviare tramite proxy.

Per ulteriori informazioni su queste variabili, consulta https://www.npmjs.com/package/request#controlling-proxy-behaviour-using-environment-variables
Riavvia Edge Microgateway.

Utilizza un proxy HTTP per la comunicazione di destinazione

Aggiunta nella versione 3.1.2.

Per utilizzare un proxy HTTP per la comunicazione tra Edge Microgateway e le destinazioni del backend, segui questi passaggi:

Aggiungi la seguente configurazione al file di configurazione del microgateway:
```
edgemicro:
  proxy:
    tunnel: true | false
    url: proxy_url
    bypass: target_host # target hosts to bypass the proxy.
    enabled: true | false
```
Dove:
- tunnel (facoltativo): se impostato su true, Edge Microgateway utilizza il metodo HTTP CONNECT per eseguire il tunneling HTTP richieste su una singola connessione TCP. Lo stesso vale se le variabili di ambiente, come indicate di seguito, per la configurazione del proxy sono abilitati per TLS). Predefinita: false
- url: l'URL del proxy HTTP.
- bypass: (facoltativo) specifica uno o più URL host di destinazione separati da virgole che deve ignorare il proxy HTTP. Se questa proprietà non è impostata, utilizza la proprietà NO_PROXY per specificare gli URL di destinazione da ignorare.
- enabled: se true e proxy.url è impostato, utilizza il valore proxy.url per il proxy HTTP. Se il valore è true e proxy.url non è impostato, utilizza i proxy specificati nel proxy HTTP le variabili di ambiente HTTP_PROXY e HTTPS_PROXY, come descritto in Utilizza un proxy HTTP per la comunicazione con Apigee Edge.
Ad esempio:
```
edgemicro:
  proxy:
    tunnel: true
    url: 'http://localhost:3786'
    bypass: 'localhost','localhost:8080' # target hosts to bypass the proxy.
    enabled: true
```
NOTA: Nota: se edgemicro.proxy viene omesso dalla di configurazione o se edgemicro.proxy.enabled è falso, Edge Microgateway non utilizzerà un proxy HTTP per la comunicazione di destinazione.
Riavvia Edge Microgateway.

Utilizzo di caratteri jolly in Microgateway-aware proxy

Puoi utilizzare uno o più "*" caratteri jolly nel percorso di base di un Proxy edgemicro_* (con conoscenza del Microgateway). Ad esempio, un percorso di base /team/*/members permette ai clienti di chiamare https://[host]/team/blue/members e https://[host]/team/green/members senza dover creare nuovi proxy API per supportare nuovi team. Tieni presente che /**/ non è supportato.

Importante: Apigee NON supporta l'utilizzo di un carattere jolly "*" come il il primo elemento di un percorso di base. Ad esempio, NON è supportato: ricerca /*/.

Rotazione delle chiavi JWT

In che modo Edge Microgateway utilizza i JWT

Il token JWT (JSON Web Token) è uno standard token descritto in RFC7519. Il JWT offre un modo per firmare una serie di rivendicazioni, che possono essere verificati in modo affidabile dal destinatario del JWT.

Puoi generare un JWT utilizzando l'interfaccia a riga di comando e utilizzarlo Intestazione di autorizzazione delle chiamate API anziché una chiave API. Ad esempio:

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

Per informazioni sulla generazione di JWT con l'interfaccia a riga di comando, consulta Generare un token.

Che cos'è la rotazione delle chiavi?

Dopo la generazione iniziale di un JWT, potrebbe essere necessario modificare una coppia di chiavi pubblica/privata archiviata nella KVM con crittografia perimetrale. Questo processo di generazione di una nuova chiave di parole chiave è detta rotazione della chiave. Quando ruoti le chiavi, viene generata una nuova coppia di chiavi privata/pubblica archiviati nel "microgateway" KVM nella tua organizzazione o nel tuo ambiente Apigee Edge. Inoltre, la chiave pubblica precedente viene conservata insieme al valore ID della chiave originale.

Per generare un JWT, Edge utilizza le informazioni archiviate nella KVM criptata. R La KVM denominata microgateway è stata creata e compilata con chiavi durante la configurazione iniziale Microgateway Edge. Le chiavi nella KVM vengono utilizzate per firmare e criptare un JWT.

Le chiavi KVM includono:

private_key: la chiave privata RSA più recente (creata più di recente) utilizzata per firmare JWT.
public_key: il certificato più recente (creato più di recente) utilizzato per verificare i JWT è firmato con private_key.
private_key_kid: l'ID della chiave privata più recente (creato più di recente). Questo ID chiave è associato al valore private_key e viene utilizzato per supportare la rotazione della chiave.
public_key1_kid: l'ID della chiave pubblica più recente (creato più di recente). Questa chiave è è associata al valore public_key1 e viene utilizzata per supportare la rotazione della chiave. Questo valore è uguale all'elemento figlio della chiave privata.
public_key1 - La chiave pubblica più recente (creata più di recente).

Quando esegui la rotazione delle chiavi, le coppie chiave-valore esistenti vengono sostituite nella mappa e nuove vengono aggiunte le chiavi pubbliche precedenti. Ad esempio:

public_key2_kid: l'ID della chiave pubblica precedente. Questa chiave è associata al parametro valore public_key2 e viene utilizzato per supportare la rotazione della chiave.
public_key2 - La chiave pubblica precedente.

I JWT presentati per la verifica verranno verificati utilizzando la nuova chiave pubblica. Se non va a buon fine, verrà utilizzata la vecchia chiave pubblica fino alla scadenza del JWT (dopo l'intervallo token_expiry*, il valore predefinito è 30 minuti). Nella in questo modo, puoi "ruotare" senza interrompere immediatamente il traffico delle API.

Come eseguire la rotazione della chiave

Questa sezione spiega come eseguire una rotazione della chiave.

Per eseguire l'upgrade della KVM, utilizza il comando edgemicro upgradekvm. Per maggiori dettagli sull'esecuzione di questo comando, consulta la sezione Upgrade il KVM. Dovrai eseguire questo passaggio una sola volta.
Per eseguire l'upgrade del proxy edgemicro-oauth, utilizza il comando edgemicro upgradeauth. Per maggiori dettagli sull'esecuzione di questo comando, consulta Eseguire l'upgrade del proxy edgemicro-auth. Dovrai eseguire questo passaggio una sola volta.
Aggiungi la seguente riga al file ~/.edgemicro/org-env-config.yaml, dove devi specificare la stessa organizzazione e lo stesso ambiente in cui hai configurato il microgateway per l'utilizzo:
```
jwk_public_keys: 'https://$ORG-$ENV.apigee.net/edgemicro-auth/jwkPublicKeys'
```

Esegui il comando di rotazione della chiave per ruotare le chiavi. Per maggiori dettagli su questo comando, vedi Tasti che ruotano.

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

Ad esempio:

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

Dopo la rotazione della chiave, Edge restituisce più chiavi in Edge Microgateway. Nota nella nell'esempio seguente, ogni chiave ha un ID "bambino" univoco (ID chiave). Il microgateway poi utilizza questi per convalidare i token di autorizzazione. Se la convalida del token non va a buon fine, il microgateway cerca di controlla se nel set di chiavi è presente una chiave meno recente e prova a provarla. Il formato del le chiavi restituite sono chiavi web JSON (JWK). Per ulteriori informazioni su questo formato, consulta il documento 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"
    }
  ]
}

Configurare un "non prima" ritardo

Per le versioni 3.1.5 e precedenti, la nuova chiave privata generata dal comando rotatekey ha utilizzato ha effetto immediato e i nuovi token generati sono stati firmati con la nuova chiave privata. Tuttavia, la nuova chiave pubblica è stata resa disponibile alle istanze Edge Microgateway solo ogni 10 minuti (per impostazione predefinita) quando la configurazione del microgateway è stata aggiornata. A causa di questo ritardo tra le firme del token e l'aggiornamento dell'istanza microgateway, i token firmati con la chiave più recente verranno rifiutati fino a quando tutte le istanze hanno ricevuto la chiave pubblica più recente.

Nei casi in cui esistono più istanze di microgateway, a volte il ritardo della chiave pubblica risulta in errori di runtime intermittenti con stato 403, perché la convalida del token verrebbe passato ma l'operazione non riesce su un'altra istanza finché non sono state aggiornate tutte le istanze.

A partire dalla versione 3.1.6, un nuovo flag sul comando rotatekey consente di specificare un ritardo per il nuovo la chiave privata di diventare effettiva, lasciando il tempo per aggiornare tutte le istanze del microgateway e ricevere la nuova chiave pubblica. Il nuovo flag è --nbf, che significa "non prima". Questo flag accetta un valore intero, ovvero il numero di minuti di ritardo.

Nell'esempio seguente, il ritardo è impostato su 15 minuti:

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

Tieni presente che è buona norma impostare un ritardo superiore all'impostazione di configurazione di config_change_poll_internal. che è di 10 minuti per impostazione predefinita. Vedi anche attributi edgemicro.

Filtro dei proxy scaricati

Per impostazione predefinita, Edge Microgateway scarica tutti i proxy nell'organizzazione Edge che iniziano con il prefisso di denominazione "edgemicro_". Puoi modificare questa impostazione predefinita per scaricare proxy i cui nomi corrispondono a uno schema.

Apri il file di configurazione di Edge Micro: ~/.edgemicro/org-env-config.yaml
Aggiungi l'elemento proxyPattern in edge_config. Ad esempio, il seguente pattern di download di proxy come edgemicro_foo, edgemicro_fast e edgemicro_first.
```
edge_config:
…
proxyPattern: edgemicro_f*
```

Specificare i prodotti senza proxy API

In Apigee Edge, puoi creare un prodotto API che non contiene proxy API. Questa configurazione del prodotto consente il funzionamento di una chiave API associata a quel prodotto con qualsiasi di cui è stato eseguito il deployment nella tua organizzazione. A partire dalla versione 2.5.4, Edge Microgateway supporta questo prodotto configurazione.

Debug e risoluzione dei problemi

Connessione a un debugger

Puoi eseguire Edge Microgateway con un debugger, come node-inspector. Questo è utile per risoluzione dei problemi e debug dei plug-in personalizzati.

Riavvia Edge Microgateway in modalità di debug. Per farlo, aggiungi DEBUG=* al all'inizio del comando start:
```
DEBUG=* edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET
```
NOTA: su Windows, usa SET DEBUG=*

Per indirizzare l'output di debug a un file, puoi utilizzare questo comando:
```
export DEBUG=* nohup edgemicro start \
-o $ORG -e $ENV -k $KEY -s $SECRET 2>&1 | tee /tmp/file.log
```
Avvia il debugger e impostalo in modo che ascolti il numero di porta per il processo di debug.
Ora puoi esplorare il codice Edge Microgateway, impostare punti di interruzione, controllare le espressioni e così via.

Puoi specificare flag Node.js standard relativi alla modalità di debug. Ad esempio: --nolazy consente di eseguire il debug del codice asincrono.

Controllo dei file di log

Se riscontri problemi, assicurati di esaminare i file di log per trovare dettagli di esecuzione ed errori informazioni. Per maggiori dettagli, vedi Gestione dei file di log.

Utilizzo della sicurezza delle chiavi API

Le chiavi API forniscono un semplice meccanismo per autenticare i client che effettuano richieste a Edge Microgateway. Puoi ottenere una chiave API copiando il valore della chiave utente (detto anche ID client). da un prodotto Apigee Edge che include il proxy di autenticazione Edge Microgateway.

Memorizzazione nella cache delle chiavi

Le chiavi API vengono scambiate con token di connessione, che vengono memorizzati nella cache. Puoi disattivare la memorizzazione nella cache impostando l'intestazione Cache-Control: no-cache sulle richieste in entrata a Edge Microgateway.

Utilizzo di una chiave API

Puoi passare la chiave API in una richiesta API come parametro di query o come intestazione. Per impostazione predefinita, il nome dell'intestazione e del parametro di query sono entrambi x-api-key.

Esempio di parametro di ricerca:

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

Esempio di titoli:

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

Configurazione del nome della chiave API

Per impostazione predefinita, x-api-key è il nome utilizzato sia per l'intestazione della chiave API sia per il parametro di query. Puoi modificare questa impostazione predefinita nel file di configurazione, come spiegato nella sezione Apportare modifiche alla configurazione. Ad esempio, per modificare in apiKey:

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

In questo esempio, il parametro di query e il nome dell'intestazione sono stati modificati in apiKey. La il nome x-api-key non funzionerà più in nessun caso. Vedi anche Apportare modifiche alla configurazione.

Ad esempio:

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

Per ulteriori informazioni sull'utilizzo delle chiavi API con le richieste proxy, consulta Secure Edge Microgateway.

Attiva i codici di risposta upstream

Per impostazione predefinita, il plug-in oauth restituisce solo codici di stato di errore 4xx se la risposta non è uno stato 200. Puoi modificare questo comportamento in modo che restituisce il codice 4xx o 5xx esatto, a seconda dell'errore.

Per attivare questa funzionalità, aggiungi oauth.useUpstreamResponse: true alla configurazione di Edge Microgateway. Ad esempio:

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

Utilizzo della sicurezza del token OAuth2

Questa sezione spiega come ottenere i token di accesso e i token di aggiornamento OAuth2. I token di accesso vengono usati per chiamate API sicure attraverso il microgateway. I token di aggiornamento vengono utilizzati per ottenere nuovi token di accesso.

Come ottenere un token di accesso

Questa sezione spiega come utilizzare il proxy edgemicro-auth per ottenere un token di accesso.

Puoi anche ottenere un token di accesso utilizzando il comando dell'interfaccia a riga di comando edgemicro token. Per maggiori dettagli sull'interfaccia a riga di comando, vedi Gestione dei token.

API 1: inviare le credenziali come parametri del corpo

Sostituisci i nomi dell'organizzazione e dell'ambiente nell'URL e sostituire i valori ID consumatore e secret del consumatore ottenuti da un'app sviluppatore su Apigee Edge per i parametri corpo client_id e 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: invia le credenziali in un'intestazione Autorizzazione di base

Invia le credenziali del client come intestazione per l'autenticazione di base e il grant_type come parametro del modulo. Questo modulo di comando viene discusso anche RFC 6749: framework di autorizzazione OAuth 2.0.

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"

Esempio di output

L'API restituisce una risposta in formato JSON. Tieni presente che non c'è differenza tra token e access_token proprietà. Puoi utilizzare uno dei due. Tieni presente che expires_in è un valore intero specificato in secondi.

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

Come ottenere un token di aggiornamento

Per ricevere un token di aggiornamento, effettua una chiamata API all'endpoint /token della Proxy edgemicro-auth. DEVI effettuare questa chiamata API con il password il tipo di autorizzazione. La procedura è descritta di seguito.

Ricevi un token di accesso e di aggiornamento con l'API /token. Tieni presente che il tipo di autorizzazione è 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"
}'

L'API restituisce un token di accesso e un token di aggiornamento. La risposta è simile a: questo. Tieni presente che expires_in assegna un valore intero ai numeri interi e viene specificato in secondi.

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

Ora puoi utilizzare il token di aggiornamento per ottenere un nuovo token di accesso chiamando l'endpoint /refresh della stessa API. Ad esempio:

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"
}'

L'API restituisce un nuovo token di accesso. La risposta è simile alla seguente:

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

Monitoraggio costante

Rimossa: questa funzionalità dell'interfaccia a riga di comando è stata rimossa nella versione Edge Microgateway 3.3.3. Tu può sostituire forever-monitor con PM2. Per maggiori dettagli, vedi Post della community: Edgemicro + PM2: Avvio di edgemicro as a Service. Vedi anche le note di rilascio di Edge Microgateway 3.3.3.

Specifica di un endpoint del file di configurazione

Se esegui più istanze Edge Microgateway, potrebbe essere opportuno gestirne le configurazioni da un'unica posizione. Puoi farlo specificando un endpoint HTTP in cui Edge Micro può scaricarne il file di configurazione. Puoi specificare questo endpoint quando avvii Edge Micro utilizzando il flag -u.

Ad esempio:

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

in cui l'endpoint mgconfig restituisce i contenuti del file di configurazione. Questo è il file che, per impostazione predefinita, si trova in ~/.edgemicro e ha la convenzione di denominazione: org-env-config.yaml.

Disattivazione del buffering dei dati della connessione TCP

Puoi utilizzare l'attributo di configurazione nodelay per disattivare il buffering dei dati per Connessioni TCP utilizzate da Edge Microgateway.

Per impostazione predefinita, le connessioni TCP utilizzano Nagle algoritmo per eseguire il buffering dei dati prima di inviarli. Impostazione di nodelay su true, disattiva questo comportamento (i dati verranno attivati immediatamente ogni volta socket.write() è stata chiamata). Vedi anche il file Node.js documentazione per ulteriori dettagli.

Per attivare nodelay, modifica il file di configurazione Edge Micro come segue:

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

Esecuzione di Microgateway Edge in modalità autonoma

Puoi eseguire Edge Microgateway disconnesso completamente da Dipendenza da Apigee Edge. Questo scenario, chiamato modalità autonoma, ti consente di eseguire e testare Edge Microgateway senza una connessione a internet.

In modalità autonoma, le seguenti funzionalità non funzionano perché richiedono la connessione su Apigee Edge:

OAuth e chiave API
Quota
Analytics

D'altra parte, i plug-in personalizzati e l'arresto dei picchi funzionano normalmente, perché non richiedono una connessione ad Apigee Edge. Inoltre, un nuovo plug-in chiamato extauth ti consente autorizzare le chiamate API al microgateway con un JWT in modalità autonoma.

Configurazione e avvio del gateway

Per eseguire Edge Microgateway in modalità autonoma:

Crea un file di configurazione denominato $HOME/.edgemicro/$ORG-$ENV-config.yaml
Puoi utilizzare qualsiasi valore per $ORG e $ENV nel nome file. La combinazione org/env è semplicemente una convenzione che permette a Edge Microgateway di trovare il file quando si avvia.

Ad esempio:
```
vi $HOME/.edgemicro/foo-bar-config.yaml
```
Incolla il codice seguente nel file:
```
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
```
Il file di configurazione contiene un plug-in speciale facoltativo chiamato extauth. Questo plug-in verifica un token JWT valido passato al microgateway. In un passaggio successivo, imparerai a per ottenere e utilizzare il token. Inoltre, tieni presente che il plug-in spikearrest è incluso perché non si basa sulla connettività con Edge. quota, I plug-in oauth e analytics sono esclusi perché si basano sulla connettività con Edge e non funzioneranno in modalità disconnessa. I plug-in personalizzati sono consentiti e funzioneranno come previsto.
Esporta la seguente variabile di ambiente con il valore "1":
```
export EDGEMICRO_LOCAL=1
```
Esegui questo comando start, in cui fornisci valori per creare un'istanza del proxy locale:
```
edgemicro start -o $ORG -e $ENV -a $LOCAL_PROXY_NAME \
  -v $LOCAL_PROXY_VERSION -t $TARGET_URL -b $BASE_PATH
```
Dove:
- $ORG è l'"organizzazione" utilizzato nel nome del file di configurazione.
- $ENV è "env" nome utilizzato nel file di configurazione nome.
- $LOCAL_PROXY_NAME è il nome del proxy locale che verrà creato. Puoi utilizzare il nome che desideri.
- $LOCAL_PROXY_VERSION è il numero di versione del proxy.
- $TARGET_URL è l'URL del target del proxy. (Il target è il chiamato dal proxy).
- $BASE_PATH è il percorso di base del proxy. Questo valore deve iniziare con un . Per un percorso di base principale, specifica solo una barra; ad esempio "/".
Ad esempio:
```
edgemicro start -o local -e test -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
```
Testa la configurazione.
```
curl http://localhost:8000/echo  { "error" : "missing_authorization" }
```
Poiché il plug-in extauth è nel file foo-bar-config.yaml, ricevi un'autorizzazione "mancante_autorizzazione" . Questo plug-in convalida un JWT che deve essere presente nel modulo di autorizzazione dell'intestazione della chiamata API. Nella sezione successiva, otterrai un JWT che consentirà le chiamate API devono essere elaborati senza l'errore.

Esempio: ottenere un token di autorizzazione

L'esempio seguente mostra come ottenere un JWT dall'endpoint JWT di Edge Microgateway su Apigee Edge (edgemicro-auth/jwkPublicKeys). Il deployment di questo endpoint viene eseguito quando esegui l'impostazione e la configurazione standard di Edge Microgateway. Per ottenere il JWT dall'endpoint Apigee, devi prima eseguire la configurazione standard di Edge Microgateway e essere connessi a internet. Qui viene usato l'endpoint Apigee per scopi di esempio e non è obbligatorio. Se vuoi, puoi utilizzare un altro endpoint del token JWT. In questo caso, dovrai ottenere il JWT utilizzando l'API fornita per quell'endpoint.

L'inclusione del plug-in extauth nella configurazione del microgateway è facoltativa, ma se lo includi, ti verrà richiesto per fornire un token JWT valido nell'intestazione Autorizzazione per le chiamate API.

I passaggi seguenti spiegano come ottenere un token utilizzando l'endpoint edgemicro-auth/jwkPublicKeys:

Devi eseguire un'operazione standard configurazione e configurazione di Edge Microgateway per il deployment del proxy edgemicro-auth alla tua organizzazione o al tuo ambiente su Apigee Edge. Se hai eseguito questo passaggio in precedenza, non è necessario ripeterlo.
Se hai eseguito il deployment di Edge Microgateway su Apigee Cloud, devi essere connesso a internet per poter ottenere un JWT da questo endpoint.
Arresta il microgateway Edge:
```
edgemicro stop
```
Nel file di configurazione creato in precedenza ($HOME/.edgemicro/org-env-config.yaml), punta extauth:publickey_url all'endpoint edgemicro-auth/jwkPublicKeys nella tua organizzazione o ambiente Apigee Edge. Ad esempio:
```
extauth:
  publickey_url: 'https://your_org-your_env.apigee.net/edgemicro-auth/jwkPublicKeys'
```
Riavvia Edge Microgateway come facevi in precedenza, utilizzando i nomi org/env utilizzati nel nome del file di configurazione. Ad esempio:
```
edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
```
Recupera un token JWT dall'endpoint di autorizzazione. Perché stai utilizzando edgemicro-auth/jwkPublicKeys endpoint, puoi utilizzare questo comando dell'interfaccia a riga di comando:
Per questo passaggio è necessaria una connessione a Internet. Il seguente comando recupera un token da Apigee Edge. Per eseguire questo passaggio, devi avere un'organizzazione Apigee in cui hai eseguito l'impostazione e la configurazione di Edge Microgateway standard. Dopo aver eseguito questo passaggio, non è necessario essere connessi al su internet. Il token continuerà a funzionare in modalità autonoma fino alla scadenza.

Puoi generare un JWT per Edge Microgateway utilizzando il comando edgemicro token oppure tramite un'API. Ad esempio:

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

Dove:

your_org è il nome della tua organizzazione Apigee per la quale hai precedentemente configurato Edge Microgateway.
your_env è un ambiente dell'organizzazione.
L'opzione i specifica la chiave utente di un'app sviluppatore con un prodotto che include il proxy edgemicro-auth.
L'opzione s specifica il segreto utente di un'app sviluppatore con un prodotto che include il proxy edgemicro-auth.

Questo comando chiede ad Apigee Edge di generare un JWT che possa essere utilizzato per verificare l'API chiamate.

Vedi anche Generare un token.

Testa la configurazione autonoma

Per testare la configurazione, chiama l'API con il token aggiunto nell'intestazione Autorizzazione come segue:

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

Esempio:

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

Output di esempio:

{
   "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":""
}

Utilizzo della modalità proxy locale

In modalità proxy locale, Edge Microgateway non richiede un Proxy microgateway-aware il deployment su Apigee Edge. Devi, invece, configurare un "proxy locale". fornendo un nome proxy locale, basepath e URL di destinazione quando avviare il microgateway. Le chiamate API al microgateway vengono quindi inviate al target URL del proxy locale. Sotto tutti gli altri aspetti, la modalità proxy locale funziona esattamente come l'esecuzione Microgateway Edge in modalità normale. L’autenticazione funziona allo stesso modo, arresto anomalo e applicazione della quota, plug-in personalizzati e così via.

Le due differenze importanti tra la modalità locale e Edge Microgateway normale sono: (1) in modalità locale, non è necessario creare un gateway VPN proxy su Apigee Edge e (2) quando crei un prodotto API su Edge, devi aggiungere un solo proxy, il proxy edgemicro-auth. Non è necessario aggiungere altri proxy al prodotto.

Caso d'uso ed esempio

La modalità proxy locale è utile quando devi associare un solo proxy a un gateway Microgateway in esecuzione in un'istanza Compute Engine. Ad esempio, puoi inserire Edge Microgateway in Kubernetes come proxy sidecar, dove un il microgateway e un servizio vengono eseguiti in un unico pod e dove il microgateway gestisce il traffico verso e dal suo servizio associato. La figura seguente illustra questa architettura in cui Edge Il microgateway funziona come proxy sidecar in un cluster Kubernetes. Ogni istanza di microgateway comunica a un solo endpoint sul suo servizio complementare:

Edgemicro come Sidecar

Un vantaggio di questo stile di architettura è che Edge Microgateway fornisce API per i singoli servizi di cui è stato eseguito il deployment in un ambiente container, come per un cluster Kubernetes.

Configurazione della modalità proxy locale

Per configurare Edge Microgateway per l'esecuzione in modalità proxy locale, segui questi passaggi:

Esegui edgemicro init per impostare esattamente l'ambiente di configurazione locale come in una tipica configurazione di Edge Microgateway. Vedi anche Configurare Edge Microgateway.
Esegui edgemicro configure, come in una tipica configurazione di Edge Microgateway . Ad esempio:
```
edgemicro configure -o your_org -e your_env -u your_apigee_username
```
Questo comando esegue il deployment del criterio edgemicro-auth su Edge e restituisce una chiave e segreto che dovrai avviare il microgateway. Se hai bisogno di aiuto, consulta Configurare Edge Microgateway.
Su Apigee Edge, crea un prodotto API con la seguente configurazione obbligatoria requisiti (puoi gestire tutte le altre configurazioni come preferisci):
- Devi aggiungere il proxy edgemicro-auth al prodotto. Questo proxy il deployment è stato eseguito automaticamente durante l'esecuzione di edgemicro configure.
- Devi fornire un percorso della risorsa. Apigee consiglia di aggiungere questo percorso il prodotto: /**. Per saperne di più, consulta Configurare il comportamento del percorso della risorsa. Vedi anche Creare API nella documentazione di Edge.
Su Apigee Edge, crea uno sviluppatore oppure puoi avvalerti di uno sviluppatore esistente desiderio. Per informazioni, vedi Aggiungere sviluppatori utilizzando l'interfaccia utente di gestione perimetrale.
Su Apigee Edge, crea un'app sviluppatore. Devi aggiungere il prodotto API appena creato nell'app. Per ulteriori informazioni, vedi Registrazione di un'app in Edge. interfaccia utente di gestione.
Sulla macchina in cui è installato Edge Microgateway, esporta quanto segue di ambiente con il valore "1".
```
export EDGEMICRO_LOCAL_PROXY=1
```
Esegui questo comando start:
```
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
```
Dove:
- your_org è la tua organizzazione Apigee.
- your_environment è un ambiente della tua organizzazione.
- your_key è la chiave restituita durante l'esecuzione edgemicro configure.
- your_secret è il segreto che è stato restituito durante la corsa edgemicro configure.
- local_proxy_name è il nome del proxy locale che verrà creato.
- local_proxy_version è il numero di versione del proxy.
- target_url è l'URL del target del proxy (il servizio che il proxy chiamata).
- base_path è il percorso di base del proxy. Questo valore deve iniziare con un . Per un percorso di base principale, specifica solo una barra; ad esempio "/".
Ad esempio:
```
edgemicro start -o your_org -e test -k 7eb6aae644cbc09035a...d2eae46a6c095f \
  -s e16e7b1f5d5e24df...ec29d409a2df853163a -a proxy1 -v 1 \
  -t http://mocktarget.apigee.net -b /echo
```

Test della configurazione

Puoi testare la configurazione del proxy locale chiamando l'endpoint del proxy. Ad esempio: Se hai specificato un percorso base /echo, puoi chiamare il proxy nel seguente modo:

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

Questa chiamata API iniziale ha generato un errore perché non hai fornito una chiave API valida. Puoi trovare la chiave nell'app sviluppatore creata in precedenza. Apri l'app nella UI di Edge, copia la chiave utente e utilizzala nel seguente modo:

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

Ad esempio:

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

Output di esempio:

{
  "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":""
}

Utilizzo del sincronizzatore

Questa sezione spiega come utilizzare il sincronizzatore, una funzionalità opzionale migliora la resilienza di Edge Microgteway consentendo per recuperare i dati di configurazione da Apigee Edge e scriverli in un database Redis locale. Con un'istanza di sincronizzazione in esecuzione, altre istanze Edge Microgateway in esecuzione su nodi diversi può recuperare la configurazione direttamente da questo database.

La funzionalità di sincronizzazione è attualmente supportata per Redis 5.0.x.

Che cos'è il sincronizzatore?

Il sincronizzatore fornisce un livello di resilienza per Edge Microgateway. Contribuisce a garantire che ogni istanza di Edge Microgateway utilizza la stessa configurazione in caso di interruzione di internet, le istanze Edge Microgateway possono avviarsi ed eseguire correttamente.

Per impostazione predefinita, le istanze Edge Microgateway devono poter comunicare con Apigee Edge recuperare e aggiornare i relativi dati di configurazione, ad esempio il proxy API e le configurazioni dei prodotti API. Se la connessione a internet con Edge viene interrotta, le istanze microgateway possono continuare perché i dati di configurazione più recenti sono memorizzati nella cache. Tuttavia, le nuove istanze microgateway non può avviarsi senza una connessione chiara. Inoltre, è possibile che per internet un'interruzione per determinare l'esecuzione di una o più istanze microgateway con la configurazione informazioni non sincronizzate con le altre istanze.

La sincronizzazione di Edge Microgateway fornisce un meccanismo alternativo per Edge Microgateway per recuperare i dati di configurazione necessari per avviare ed elaborare il traffico del proxy API. I dati di configurazione recuperati dalle chiamate ad Apigee Edge includono: la chiamata jwk_public_keys, la chiamata jwt_public_key, la chiamata di bootstrap e la chiamata dei prodotti API. Il sincronizzatore rende possibile tutto il di istanze in esecuzione su nodi diversi per avviarsi correttamente e rimanere sincronizzate anche la connessione a internet tra Edge Microgateway e Apigee Edge viene interrotta.

Il sincronizzatore è un'istanza di Edge Microgateway appositamente configurata. Il suo unico scopo è eseguire il polling di Apigee Edge (i tempi sono configurabili), recuperare i dati di configurazione e e lo scrivi in un database Redis locale. L'istanza del sincronizzatore stesso non può elaborare il proxy API per via del traffico. Altre istanze di Edge Microgateway in esecuzione su nodi diversi possono Essere configurata in modo da recuperare i dati di configurazione dal database Redis anziché da Apigee perimetrali. Poiché tutte le istanze microgateway estraggono i propri dati di configurazione dall'ambiente possono avviare ed elaborare le richieste API anche nel caso di una connessione e un'interruzione del servizio.

Configurazione di un'istanza di sincronizzazione

Aggiungi la seguente configurazione al file org-env/config.yaml per l'installazione di Edge Microgateway che vuoi utilizzare come sincronizzatore:

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

Ad esempio:

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

Opzione	Descrizione
`redisHost`	L'host su cui è in esecuzione l'istanza Redis. Impostazione predefinita: 127.0.0.1
`redisPort`	La porta dell'istanza Redis. Valore predefinito: 6379
`redisDb`	Il database Redis da utilizzare. Valore predefinito: 0
`redisPassword`	La password del database.

Puoi utilizzare la variabile di ambiente EDGEMICRO_REDIS_PASSWORD per eseguire l'override il parametro edgemicro.redisPassword. Consulta anche Impostare gli attributi di configurazione con valori delle variabili di ambiente.

Infine, salva il file di configurazione e avvia l'istanza Edge Microgateway. Inizierà eseguendo il polling di Apigee Edge e memorizzando i dati di configurazione scaricati nel database Redis.

Configurazione di istanze Edge Microgateway normali

Con il sincronizzatore in esecuzione, puoi configurare nodi Edge Microgateway aggiuntivi per eseguire normali istanze di microgateway che elaborano il traffico del proxy API. Tuttavia, configuri a queste istanze per ottenere i relativi dati di configurazione dal database Redis anziché Apigee Edge

Aggiungi la configurazione seguente a ogni nodo aggiuntivo del Microgateway Edge org-env/config.yaml. Tieni presente che synchronizerMode è impostata su 0. Questa proprietà imposta l'istanza in modo che funzioni come L'istanza Edge Microgateway che elabora il traffico del proxy API e l'istanza otterrà i suoi dati di configurazione dal database Redis.

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

Ad esempio:

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

Proprietà di configurazione

Per supportare l'utilizzo del sincronizzatore, sono state aggiunte le seguenti proprietà di configurazione:

Attributo Valori Descrizione

Attributo	Valori	Descrizione
`edge_config.synchronizerMode`	0 o 1	Se il valore è 0 (valore predefinito), Edge Microgateway funziona nella modalità standard. Se 1, avvia l'istanza Edge Microgateway in modo che operi come sincronizzatore. In questo , l'istanza estrae i dati di configurazione da Apigee Edge e li archivia in un database Redis locale. Questa istanza non è in grado di elaborare le richieste proxy API. le sue l'unico scopo è eseguire il polling di Apigee Edge per i dati di configurazione e scriverli nel per configurare un database. Devi quindi configurare altre istanze del microgateway per la lettura dal database.
`edge_config.redisBasedConfigCache`	true o false	Se true, l'istanza Edge Microgateway recupera i dati di configurazione Redis invece che da Apigee Edge. Il database Redis deve essere lo stesso su cui è configurato il sincronizzatore. Se il database Redis non è disponibile o Se il database è vuoto, il microgateway cerca un `cache-config.yaml` esistente per la sua configurazione. Se il valore è false (valore predefinito), l'istanza Edge Microgateway recupera i dati di configurazione da Apigee Edge come di consueto.
`edgemicro.config_change_poll_interval`	Intervallo di tempo, in secondi	Specifica l'intervallo di polling affinché il sincronizzatore possa eseguire il pull dei dati da Apigee Edge.

edge_config.synchronizerMode

0 o 1

Se il valore è 0 (valore predefinito), Edge Microgateway funziona nella modalità standard.

Se 1, avvia l'istanza Edge Microgateway in modo che operi come sincronizzatore. In questo , l'istanza estrae i dati di configurazione da Apigee Edge e li archivia in un database Redis locale. Questa istanza non è in grado di elaborare le richieste proxy API. le sue l'unico scopo è eseguire il polling di Apigee Edge per i dati di configurazione e scriverli nel per configurare un database. Devi quindi configurare altre istanze del microgateway per la lettura dal database.

edge_config.redisBasedConfigCache

true o false

Se true, l'istanza Edge Microgateway recupera i dati di configurazione Redis invece che da Apigee Edge. Il database Redis deve essere lo stesso su cui è configurato il sincronizzatore. Se il database Redis non è disponibile o Se il database è vuoto, il microgateway cerca un cache-config.yaml esistente per la sua configurazione.

Se il valore è false (valore predefinito), l'istanza Edge Microgateway recupera i dati di configurazione da Apigee Edge come di consueto.

edgemicro.config_change_poll_interval Intervallo di tempo, in secondi Specifica l'intervallo di polling affinché il sincronizzatore possa eseguire il pull dei dati da Apigee Edge.

Configurazione di URL di esclusione per i plug-in

Puoi configurare il microgateway per saltare l'elaborazione dei plug-in per URL specificati. Puoi configurare queste esclusioni URL globali (per tutti i plug-in) o per plug-in specifici.

Ad esempio:

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

In questo esempio, i plug-in non elaborano le chiamate proxy API in arrivo con percorsi /hello o /proxy_one. Inoltre, json2xml verrà ignorato per le API che hanno /hello/xml nel percorso.

Non puoi escludere il plug-in analytics.

Impostare gli attributi di configurazione con i valori delle variabili di ambiente

Puoi specificare le variabili di ambiente utilizzando i tag nella . I tag delle variabili di ambiente specificate sono sostituiti dall'ambiente effettivo i valori delle variabili. Le sostituzioni vengono memorizzate solo in memoria e non nell'originale di configurazione o di memorizzazione nella cache.

Nota: per impostazione predefinita, il tag <E> analizza i valori delle variabili come stringhe. Per specificare valori interi positivi e booleani, utilizza il <n> e <b> come illustrato negli esempi di seguito.

In questo esempio, l'attributo key viene sostituito dal valore dell'attributo TARGETS_SSL_CLIENT_KEY e così via.

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 questo esempio, il tag <n> viene utilizzato per indicare un valore intero. Solo positiva sono supportati i numeri interi.

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

In questo esempio, il tag <b> viene utilizzato per indicare un valore booleano ( cioè vero false).

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