Questa pagina è stata tradotta dall'API Cloud Translation.

Modifiche in Edge for Private Cloud 4.53.01

Panoramica delle modifiche

Edge for Private Cloud 4.53.01 introduce diverse modifiche che migliorano il livello di sicurezza della piattaforma e incorpora versioni aggiornate di software e librerie richiesti. Queste modifiche interessano i seguenti tipi di norme:

Norme di convalida OAS (specifica OpenAPI)
Policy che supportano le query JSONPath
Policy di callout Java che si basano su librerie ritirate.
OpenLDAP
Modifiche al fornitore di servizi di crittografia

Puoi anche utilizzare lo strumento di rilevamento delle modifiche per identificare le modifiche ai proxy, ai flussi condivisi o ad altri artefatti nel cluster che potrebbero causare interruzioni a seguito di questo upgrade.

Descrizione dettagliata delle modifiche

Questa sezione descrive le modifiche introdotte nella versione 4.53.01 che possono interrompere i tuoi workflow durante o dopo l'upgrade. Vengono trattati anche i metodi per identificare le potenziali aree problematiche e le metodologie di mitigazione o soluzioni alternative.

Norme di convalida OAS (specifica OpenAPI)

Contesto

La policy di convalida OAS convalida le richieste o le risposte in entrata in base alle regole definite nella specifica OpenAPI 3.0 (JSON o YAML). Edge for Private Cloud 4.53.01 offre miglioramenti al criterio OAS (OpenAPI specification), concentrandosi su una convalida più rigorosa e accurata dei corpi delle risposte API.

Modifiche

Edge for Private Cloud 4.53.01 introduce due importanti modifiche al modo in cui il criterio OAS convalida le risposte API, garantendo un maggiore allineamento alla specifica OpenAPI:

Scenario 1:
- Comportamento precedente:se la tua specifica OpenAPI richiedeva un corpo della risposta, ma la risposta effettiva della norma di destinazione o upstream non lo includeva, la norma non lo segnalava come errore di convalida.
- Comportamento attuale: in questo scenario, la norma restituirà ora correttamente un errore di convalida (ad esempio defines a response schema but no response body found), indicando una mancata corrispondenza tra la risposta prevista e quella effettiva.
Scenario 2:
- Comportamento precedente:se la specifica OpenAPI indicava esplicitamente che non era previsto alcun corpo della risposta, ma la risposta effettiva della norma di destinazione o upstream includeva un corpo, la norma non avrebbe generato un errore.
- Comportamento attuale: in questo scenario, le norme ora comporteranno un errore (ad esempio, No response body is expected but one was found), garantendo che le risposte rispettino rigorosamente lo schema specificato.

Attenuazione

Identifica eventuali proxy o flussi condivisi che potrebbero essere interessati dall'upgrade utilizzando lo strumento di rilevamento delle modifiche o tramite revisione manuale. Cerca eventuali proxy in cui è presente una delle seguenti condizioni:

Il criterio di convalida OAS è configurato con un tag Source impostato su response.
Il criterio di convalida OAS convalida una risposta da qualsiasi altro criterio che genera una risposta.

Se utilizzi lo strumento, l'output verrà generato nel seguente formato:

Organizzazione	Ambiente	Nome artefatto	Tipo di artefatto	Revisione	Nome norma	Tipo di norma	Tipo di impatto	Campo specifico dell'impatto	Certezza dell'impatto	Documentazione
org2	dev	proxy2	proxy	4	oas-validateresponse	OASValidation	oas_content_type_handling	Source=calloutresponse	Media	Norme di convalida OAS
org1	produzione	proxy3	sharedflow	1	oas-spec-validation	OASValidation	oas_content_type_handling	Source=response	Media	Norme di convalida OAS

Per una spiegazione dettagliata delle colonne nella tabella di output, consulta la sezione Comprendere l'output dello strumento.

Una volta identificato un proxy o un flusso condiviso, assicurati che la risposta e la specifica OAS siano allineate in merito alla presenza o all'assenza di un corpo della risposta. Puoi utilizzare la traccia Apigee standard per esaminare i pattern di traffico. Se la destinazione restituisce una risposta in modo intermittente, utilizza altre norme per convalidare la risposta prima che venga trasmessa alla norma di convalida OAS.

Se il file di specifica OAS definisce un corpo della risposta, la risposta della policy di destinazione o upstream deve sempre fornirne uno.
Se il file di specifica OAS non definisce un corpo della risposta, la policy di destinazione o upstream non deve inviarne uno.

Aggiorna le norme di convalida OAS o il comportamento target in base alle necessità prima di tentare l'upgrade a Private Cloud 4.53.01. Devi convalidare i flussi di lavoro identificati negli ambienti non di produzione per ridurre al minimo il rischio di interruzioni durante l'upgrade del cluster di produzione.

Percorso JSON

Contesto

Edge for Private Cloud 4.53.01 ha introdotto modifiche al modo in cui vengono utilizzate le espressioni del percorso JSON in varie policy. Le espressioni JSONPath possono essere utilizzate in criteri come ExtractVariable, RegularExpressionProtection e Data masking per analizzare i contenuti JSON o archiviare i valori nelle variabili. Le espressioni JSONPath possono essere utilizzate anche nei modelli di messaggi generali per sostituire le variabili con valori in modo dinamico durante l'esecuzione del proxy. I nuovi formati e le nuove espressioni JSONPath seguono gli standard più recenti per le espressioni JSON.

Modifiche

È importante esaminare i proxy API/flussi condivisi esistenti per verificare la presenza di norme che utilizzano espressioni JSONPath. Ciò include, a titolo esemplificativo, la policy Estrai variabili, la policy Protezione espressioni regolari o qualsiasi policy con un modello di messaggio che utilizza JSONPath.

Il seguente input JSON viene utilizzato per spiegare le modifiche:

{
  "store": {
    "book": [
      {"category": "reference", "author": "Nigel Rees", "price": 8.95},
      {"category": "fiction", "author": "Evelyn Waugh", "price": 12.99},
      {"category": "fiction", "author": "Herman Melville", "price": 8.99}
    ],
    "bicycle": {
      "color": "red",
      "book": [
        {"author": "Abc"}
      ]
    }
  }
}

Modifica del comportamento del carattere jolly JSONPath [*] per i valori degli oggetti
Il comportamento del carattere jolly [*] è stato modificato quando viene utilizzato per accedere a tutti i valori immediati di un oggetto JSON. In precedenza, $.object[*] restituiva i valori immediati racchiusi in un singolo oggetto JSON. Con le librerie aggiornate, l'output è ora un array contenente questi valori.

Ad esempio, $.store[*]:
Comportamento precedente:
```
{
  "bicycle": {
    "color": "red",
    "book": [{"author": "Abc"}]
  },
  "book": [
    {"price": 8.95, "category": "reference", "author": "Nigel Rees"},
    {"price": 12.99, "category": "fiction", "author": "Evelyn Waugh"},
    {"price": 8.99, "category": "fiction", "author": "Herman Melville"}
  ]
}
```
Comportamento attuale:
```
[
  [
    {"category": "reference", "author": "Nigel Rees", "price": 8.95},
    {"category": "fiction", "author": "Evelyn Waugh", "price": 12.99},
    {"category": "fiction", "author": "Herman Melville", "price": 8.99}
  ],
  {
    "color": "red",
    "book": [{"author": "Abc"}]
  }
]
```
Azione:
Modifica l'espressione JSONPath in modo da scegliere come target semplicemente l'oggetto principale (ad esempio $.store) per scegliere come target direttamente gli elementi recuperati in precedenza.
Il punto finale JSONPath (.) nei percorsi causa un errore
Esiste una convalida più rigorosa per le espressioni JSONPath. In precedenza, i percorsi che terminavano con un punto finale non valido (ad esempio $.path.to.element.) venivano ignorati automaticamente e la query restituiva comunque un risultato se il segmento di percorso valido precedente corrispondeva. Con la nuova versione, questi percorsi non validi vengono ora identificati correttamente come non validi e generano un errore.

Ad esempio, $.store.book.
Comportamento precedente:
```
[
  {"price":8.95,"category":"reference","author":"Nigel Rees"},
  {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
  {"price":8.99,"category":"fiction","author":"Herman Melville"}
]
```
Comportamento attuale:
```
ERROR: com.jayway.jsonpath.InvalidPathException - Path must not end with a '.' or '..'
```
Tutti i criteri esistenti che utilizzano espressioni JSONPath con un punto finale non intenzionale ora non funzioneranno e verrà visualizzato un InvalidPathException.
Azione:
Rimuovi il punto finale da qualsiasi espressione JSONPath che termina con un punto. Ad esempio, modifica $.store.book. in $.store.book.
Modifica della struttura dell'output (..) di JSONPath recursive descent
Sono state apportate modifiche al modo in cui vengono restituiti i risultati quando si utilizza l'operatore (..) (discesa ricorsiva) per individuare tutte le occorrenze di un elemento denominato. In precedenza, tutti gli elementi trovati venivano appiattiti in un unico elenco. Le librerie aggiornate ora restituiscono un elenco di elenchi, conservando la struttura di raggruppamento originale in cui sono stati trovati gli elementi, anziché un singolo elenco piatto.

Ad esempio, $..book
Comportamento precedente:
```
[
  {"price":8.95,"category":"reference","author":"Nigel Rees"},
  {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
  {"price":8.99,"category":"fiction","author":"Herman Melville"},
  {"author":"Abc"}
]
```
Comportamento attuale:
```
[
  [
    {"category":"reference","author":"Nigel Rees","price":8.95},
    {"category":"fiction","author":"Evelyn Waugh","price":12.99},
    {"category":"fiction","author":"Herman Melville","price":8.99}
  ],
  [
    {"author":"Abc"}
  ]
]
```
Azione:
Aggiorna la logica di elaborazione downstream per tenere conto della nuova struttura dell'array nidificato. Probabilmente dovrai scorrere l'JSONArray esterno e poi ogni JSONArray interno per accedere ai singoli elementi.
L'indicizzazione JSONPath dopo la selezione o il filtro di più elementi restituisce un array vuoto
Si verifica una modifica nel comportamento quando un indice (ad esempio [0]) viene applicato immediatamente dopo un selettore di più elementi (come [*]) o un filtro ([?(condition)]). In precedenza, queste espressioni tentavano di selezionare l'elemento all'indice specificato dai risultati combinati. Con la nuova versione, queste espressioni restituiranno un array vuoto ([]).

Ad esempio, $.store.book[*][0]
Comportamento precedente:
```
{"category": "reference", "price": 8.95, "author": "Nigel Rees"}
```
Comportamento attuale:
```
[]
```
Azione:
Se è necessario filtrare e poi ottenere un elemento specifico dal set filtrato, elabora l'array filtrato restituito da JSONPath, ad esempio $..book[?(@.category == 'fiction')], e poi prendi [0] dal risultato precedente.
Modifica dell'output dello slicing negativo degli array JSONPath
La nuova versione ha modificato il comportamento del sezionamento di array negativi (ad esempio: [-2:], [-1:]). In precedenza, quando si applicava una sezione negativa a un array (indicando gli elementi dalla fine dell'array), la vecchia versione restituiva erroneamente un solo elemento da quella sezione. La nuova versione ora restituisce correttamente un elenco (array) contenente tutti gli elementi che rientrano nell'intervallo negativo specificato.

Ad esempio, $.store.book[-2:]
Comportamento precedente:
```
{"price":12.99,"category":"fiction","author":"Evelyn Waugh"}
```
Comportamento attuale:
```
[
  {"category":"fiction","author":"Evelyn Waugh","price":12.99},
  {"category":"fiction","author":"Herman Melville","price":8.99}
]
```
Azione:
La logica di elaborazione downstream deve ora essere aggiornata per scorrere l'array JSON restituito e ottenere l'output desiderato.
Punto precedente più rigoroso di JSONPath
L'applicazione della sintassi per gli elementi a cui si accede direttamente dalla radice è più rigorosa. Quando si accede direttamente agli elementi dalla radice senza un punto precedente (ad esempio: $propertyelement), questa sintassi viene ora considerata un errore e impedirà il deployment del proxy.

Ad esempio, $store.
```
{
  "bicycle": {
    "color": "red",
    "book": [{"author": "Abc"}]
  },
  "book": [
    {"price": 8.95, "category": "reference", "author": "Nigel Rees"},
    {"price": 12.99, "category": "fiction", "author": "Evelyn Waugh"},
    {"price": 8.99, "category": "fiction", "author": "Herman Melville"}
  ]
}
```
Comportamento attuale:
Proxy will fail to deploy.
Azione:

Modifica JSONPath in modo da includere il punto: $.propertyName (esempio: $.store). In questo modo, il valore verrà selezionato e recuperato correttamente.
Espressioni JSONPath dinamiche
Presta particolare attenzione alle norme in cui l'espressione JSONPath è fornita da una variabile (ad esempio {myJsonPathVariable} o {dynamicPath}). Il valore di queste variabili deve essere verificato anche in base ai potenziali cambiamenti di comportamento descritti in precedenza.

Attenuazione

Identifica eventuali proxy o flussi condivisi che potrebbero essere interessati dall'upgrade utilizzando lo strumento di rilevamento delle modifiche o esaminando manualmente i proxy API per cercare i pattern descritti. Se utilizzi lo strumento, l'output identificherà il proxy o il flusso condiviso interessato, le norme pertinenti e gli eventuali percorsi JSON problematici, come mostrato nell'output di esempio riportato di seguito:

Organizzazione	Ambiente	Nome artefatto	Tipo di artefatto	Revisione	Nome norma	Tipo di norma	Tipo di impatto	Campo specifico dell'impatto	Certezza dell'impatto	Documentazione
org1	dev	proxy1	proxy	4	EV-ExtractRequestParams	ExtractVariables	Modifica del comportamento del carattere jolly [*] di JSONPath per i valori degli oggetti	$.store[*]	Alta	Modifica del comportamento del carattere jolly [*] di JSONPath per i valori degli oggetti
org2	produzione	proxy2	sharedflow	1	EV-ExtractResponseParams	ExtractVariables	Il punto finale (.) nei percorsi JSONPath ora causa un errore	$.store.book.	Alta	Il punto (.) finale in JSONPath nei percorsi causa un errore
org3	dev	proxy3	proxy	3	SC-FetchUserProfile	ServiceCallout	Modifica della struttura dell'output della discesa ricorsiva JSONPath (..)	$..book	Alta	Modifica della struttura dell'output della discesa ricorsiva JSONPath (..)
org4	produzione	proxy4	sharedflow	2	RF-InvalidAuthToken	RaiseFault	L'indicizzazione JSONPath dopo la selezione di più elementi o il filtro ora restituisce un array vuoto	$.store.book[*][0]	Alta	Indicizzazione JSONPath dopo la selezione di più elementi o il filtro restituisce un array vuoto
org5	test	proxy5	proxy	6	SC-FetchProfileDetails	ServiceCallout	Modifica dell'output di suddivisione negativa di array JSONPath	$.store.book[-2:]	Alta	Modifica dell'output dello slicing negativo degli array JSONPath
org6	produzione	proxy6	proxy	2	ML-LogRequestDetails	MessageLogging	JSONPath Stricter Preceding Dot	$store	Alta	Punto precedente più rigoroso di JSONPath
org7	test	proxy7	proxy	5	RF-InvalidTokenDetails	RaiseFault	Espressioni JSONPath dinamiche	myJsonPathVariable	Media	Espressioni JSONPath dinamiche

Per una spiegazione dettagliata delle colonne nella tabella di output precedente, consulta la sezione Comprendere l'output dello strumento.

Per mitigarli, è necessaria una strategia completa. Questo processo prevede la scelta del percorso di aggiornamento appropriato e l'applicazione della correzione necessaria per le espressioni JSONPath rilevate.

Scegli il metodo di percorso di upgrade più adatto a te:

Migrazione senza tempi di inattività
Questa strategia prevede l'acquisizione di uno o più nuovi ambienti a cui collegare nodi di elaborazione dei messaggi separati. Questi nodi del processore di messaggi possono essere impostati per installare la versione 4.53.01 e avere proxy con espressioni JSONPath moderne. Questi possono essere utilizzati durante l'upgrade e possono essere ritirati al termine dell'upgrade. Questa strategia è semplice, ma prevede l'approvvigionamento temporaneo di nodi di elaborazione dei messaggi aggiuntivi per supportare un upgrade senza problemi. Dettagli di seguito:
- Crea un nuovo ambiente e aggiungi nuovi nodi di elaborazione dei messaggi della versione 4.53.01 a questo nuovo ambiente.
- Carica il bundle del proxy per i proxy interessati nel nuovo ambiente e applica le correzioni necessarie spiegate nella sezione di correzione e implementa il bundle del proxy aggiornato nel nuovo ambiente.
- Reindirizza il traffico al nuovo ambiente e annulla il deployment dei proxy interessati dal vecchio ambiente.
- Esegui l'upgrade dei nodi del processore di messaggi originale alla versione 4.53.01. Esegui il deployment dei proxy che hanno correzioni per JSONPath nell'ambiente originale.
- Sposta di nuovo il traffico nel vecchio ambiente, che ora ha processori di messaggi sulla versione 4.53.01 e un proxy modernizzato per le nuove espressioni jsonpath.
- Elimina e ritira il nuovo ambiente e i nodi associati.
Tempi di inattività e upgrade
Questa strategia prevede l'acquisizione di tempi di inattività per i proxy API utilizzando espressioni di percorso JSON errate. Non è necessario procurarsi nodi di elaborazione dei messaggi aggiuntivi, ma causa un'interruzione del traffico API per i proxy interessati.
- Identifica i proxy interessati con le norme interessate e genera una nuova revisione per tutti i proxy interessati.
- Applica le correzioni necessarie implementando quelle spiegate nella sezione di correzione in una nuova revisione del proxy. Non eseguire ancora il deployment.
- Procurati tempi di inattività per il proxy o i proxy interessati.
- Esegui l'upgrade di tutti i processori di messaggi a Edge per la versione 4.53.01 del cloud privato. Tieni presente che i proxy esistenti potrebbero non funzionare sui processori di messaggi appena aggiornati.
- Una volta eseguito l'upgrade di tutti i processori di messaggi alla versione 4.53.01 di Edge per il cloud privato , esegui il deployment della revisione del proxy appena creata con l'espressione JSONPath corretta.
- Riprendi il traffico su questi proxy.
Riprogettazione del proxy prima dell'upgrade
Puoi riprogettare il proxy prima di eseguire l'upgrade a Edge per il cloud privato 4.53.01. Anziché fare affidamento su espressioni di percorso JSON specifiche, puoi ottenere lo stesso risultato utilizzando un metodo diverso.

Ad esempio, se utilizzi una policy Estrai variabile con un percorso JSON, puoi sostituirla con una policy JavaScript che estrae dati simili prima di eseguire l'upgrade alla versione più recente. Al termine dell'upgrade, puoi ripristinare l'utilizzo dei percorsi JSON con i formati più recenti per il proxy.

Modifiche a JavaCallout

Contesto

Edge for Private Cloud 4.53.00 e versioni precedenti conteneva una directory denominata deprecated ($APIGEE_ROOT/edge-message-processor/lib/deprecated) che conteneva una serie di librerie JAR. Queste librerie erano disponibili per l'utilizzo nel codice Java nel criterio JavaCallout e potevano essere utilizzate direttamente o indirettamente dal tuo codice Java personalizzato.

Modifiche

La directory deprecata è stata rimossa in Edge per la versione 4.53.01 del cloud privato. Se il tuo codice Java si basa su queste librerie, i proxy che utilizzano questi callout Java non funzioneranno quando i processori di messaggi verranno aggiornati alla versione 4.53.01. Per evitare questi errori, segui i passaggi di mitigazione riportati di seguito prima di eseguire l'upgrade dei message processor alla versione 4.53.01.

Attenuazione

Esamina i criteri di callout Java e i file JAR associati utilizzando lo strumento di rilevamento delle modifiche o manualmente. Controlla se una delle norme fa riferimento a librerie presenti nella directory "deprecated" dei tuoi attuali elaboratori di messaggi.

Se utilizzi lo strumento fornito da Apigee per i rilevamenti precedenti, lo strumento genererà un report come mostrato nella tabella seguente . Nello specifico, ha come target le policy che fanno riferimento ai file JAR trovati nella directory $APIGEE_ROOT/edge-message-processor/lib/deprecated delle versioni precedenti di Edge for Private Cloud.

Lo strumento genererà report nel seguente formato:

Organizzazione	Ambiente	Nome artefatto	Tipo di artefatto	Revisione	Nome norma	Tipo di norma	Tipo di impatto	Campo specifico dell'impatto	Certezza dell'impatto	Documentazione
org1	Nessuno	Nessuno	org-level-jar	Nessuno	Nessuno	java-callout	libreria deprecata rilevata per `simple-javacallout-o1-jar-1.jar`	["Detected use of class `org.apache.commons.io.FileUtils` from `commons-io-2.5.jar`, 'Detected use of class `org.apache.commons.io.input.XmlStreamReaderException` from `commons-io-2.5.jar`"]	Alta	Modifiche a JavaCallout
org3	env3	Nessuno	env-level-jar	Nessuno	Nessuno	java-callout	libreria deprecata rilevata per `fat-javacallout-e3-jar-1.jar`	["Detected use of class `org.apache.http.impl.auth.NTLMSchemeFactory` from `httpclient-4.5.2.jar`"]	Alta	Modifiche a JavaCallout
org1	env1	p1	proxy-level-jar	1	Nessuno	java-callout	libreria deprecata rilevata per `simple-javacallout-p1-jar-1.jar`	["Detected use of class `org.apache.commons.lang3.builder.ToStringBuilder` from `commons-lang3-3.4.jar`", "Detected use of class `org.apache.commons.lang3.Validate` from `commons-lang3-3.4.jar`"]	Alta	Modifiche a JavaCallout

Per una spiegazione dettagliata delle colonne nella tabella di output riportata sopra, consulta la sezione Comprendere l'output dello strumento.

Una volta identificate le librerie obsolete , puoi seguire uno dei metodi riportati di seguito per risolvere il problema.
- Posizionamento delle risorse (opzione consigliata se hai un numero ridotto di file JAR / librerie della directory ritirata a cui fanno riferimento i file JAR Java-Callout)
  - Carica i file JAR ritirati identificati come risorsa al livello desiderato: revisione del proxy API, ambiente o organizzazione.
  - Procedi con l'upgrade del software Apigee come di consueto.
- Posizionamento manuale (consigliato se hai un numero elevato di file JAR / librerie a cui fanno riferimento i file JAR Java-Callout)
  - Su ogni nodo del processore di messaggi, crea una nuova directory denominata external-lib nel percorso $APIGEE_ROOT/data/edge-message-processor/.
  - Copia i file JAR identificati in questa directory external-lib dalla directory deprecata: cp $APIGEE_ROOT/edge-message-processor/lib/deprecated/some.jar $APIGEE_ROOT/data/edge-message-processor/external-lib/some.jar
  - Assicurati che la directory e i file JAR sottostanti siano leggibili dall'utente Apigee: chown -R apigee:apigee $APIGEE_ROOT/data/edge-message-processor/external-lib
  - Procedi con l'upgrade del software Apigee come di consueto.

Modifica OpenLDAP

Contesto

OpenLDAP può essere utilizzato in Edge Private Cloud sia per l'autenticazione che per l'autorizzazione. In Edge for Private Cloud 4.53.01, il software OpenLDAP fornito da Apigee è stato aggiornato dalla versione 2.4 alla 2.6.

Modifiche

In OpenLDAP 2.6, il nome distinto relativo (RDN) è limitato a circa 241 byte/caratteri. Questo limite è un tetto massimo applicato e non può essere modificato.

Impatto

Si verificano errori di replica o importazione per le voci con RDN eccessivamente grandi.
Il tentativo di creare entità come organizzazioni,ambienti, ruoli personalizzati, autorizzazioni e così via potrebbe generare il messaggio di errore: "message": "[LDAP: error code 80 - Other]".
Sono interessati tutti i DN più lunghi di 241 byte nel LDAP di Apigee. Questi DN impediranno l'upgrade riuscito del software Apigee OpenLDAP e dovrai seguire le strategie di mitigazione per questi elementi prima di poter procedere con l'upgrade.

In genere, in LDAP di Apigee, i nomi distinti lunghi sono correlati alle autorizzazioni, in quanto vengono creati concatenando più entità. Queste voci di autorizzazione sono particolarmente soggette a problemi di upgrade.

Ad esempio,

dn: cn=@@@environments@@@*@@@applications@@@*@@@revisions@@@*@@@debugsessions,ou=resources,cn=businessuser,ou=userroles,o=orgname,ou=organizations,dc=apigee,dc=com

In genere, i nomi dell'organizzazione, dell'ambiente e del ruolo hanno una lunghezza tale che gli RDN in LDAP risultino inferiori a 241 byte.

Attenuazione

Prima dell'upgrade alla versione 4.53.01:

I passaggi seguenti ti aiuteranno a verificare la presenza di nomi distinti relativi lunghi nel cluster LDAP 2.4 esistente.

#1 - Estrai i dati LDAP

Utilizza il comando ldapsearch per trovare il nome distinto (dn) e reindirizzare l'output a un file:

ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w LDAP_PASSWORD dn > /tmp/DN.ldif

Assicurati che il file DN.ldif sopra contenga voci LDAP.

N. 2 - Identifica gli RDN lunghi

Lo strumento di rilevamento delle modifiche utilizza un file LDIF generato per identificare i nomi distinti relativi LDAP che superano i 241 byte/caratteri.

Lo strumento genererà report nel seguente formato:

Organizzazione	Ambiente	Nome artefatto	Tipo di artefatto	Revisione	Nome norma	Tipo di norma	Tipo di impatto	Campo specifico dell'impatto	Certezza dell'impatto	Documentazione
Nessuno	Nessuno	cn=`really-long-name`,ou=userroles,o=edge-platform,ou=organizations,dc=apigee,dc=com	file ldif	Nessuno	Nessuno	Nessuno	Ldap RDN exceeds 241 chars	cn=`really-long-name`	Alta	Modifica di OpenLDAP

Per una spiegazione dettagliata delle colonne nella tabella di output precedente, consulta la sezione Comprendere l'output dello strumento.

Se il comando precedente non produce alcun output, significa che nessun RDN nella configurazione LDAP esistente supera i 241 byte/caratteri. Puoi procedere con l'upgrade come di consueto.

Se il comando precedente genera un output, indica la presenza di RDN che superano i 241 byte/caratteri. Per questi elementi, segui i passaggi di mitigazione descritti nel passaggio 3 prima di procedere con l'upgrade di Edge for Private Cloud 4.53.01.

N. 3: gestione di RDN lunghi

Se ricevi l'output dal passaggio 2, significa che sono presenti RDN che superano i 241 byte/caratteri. Segui i passaggi di mitigazione riportati di seguito:

Controlla le voci LDAP che superano i 241 byte.

Se il nome del ruolo personalizzato, dell'app, del prodotto API o di altre entità è il fattore principale che causa la lunghezza del nome distinto relativo, esegui la migrazione a un'entità alternativa con un nome più breve.
Se il nome dell'organizzazione o dell'ambiente è il principale responsabile del nome distinto relativo lungo, dovrai eseguire la migrazione a un'altra organizzazione o a un altro ambiente con un nome più breve.

Continua a ripetere i passaggi precedenti finché il tuo LDAP non ha RDN più lunghi di 241 byte. Una volta raggiunto questo stato, procedi con l'upgrade della versione del cloud privato come di consueto.

Modifiche al fornitore di crittografia

Contesto

Questa modifica è un riporto di Edge for Private Cloud 4.53.00. In Edge for Private Cloud 4.53.00, il fornitore di crittografia interno è stato aggiornato da Bouncy Castle (BC) a Bouncy Castle FIPS (BCFIPS) per abilitare il supporto FIPS.

Modifiche

Se le norme JavaCallout si basano sull'utilizzo del provider BC originale, soprattutto quando si utilizza la funzionalità di sicurezza rafforzata nel provider BCFIPS (ad esempio, l'utilizzo di una coppia di chiavi comune sia per la crittografia che per la firma), queste norme JavaCallout dovranno essere modernizzate. I criteri JavaCallout che tentano di caricare il provider di crittografia Bouncy Castle utilizzando il nome BC potrebbero non riuscire perché il provider predefinito è cambiato. Questi criteri che utilizzano il provider BC potrebbero non funzionare più. Le implementazioni personalizzate che si basano sul vecchio fornitore di BC non saranno più accessibili e dovranno essere riviste e implementate di nuovo.

Attenuazione

La soluzione alternativa consigliata è utilizzare il provider BCFIPS. Le implementazioni di JavaCallout personalizzate che si basavano sul vecchio provider dovranno essere esaminate e implementate nuovamente utilizzando il provider Bouncy Castle FIPS, a cui è possibile accedere utilizzando la stringa "BCFIPS".

Strumento di rilevamento delle modifiche

È stato creato uno strumento di rilevamento delle modifiche per identificare proxy Apigee, criteri e flussi condivisi che potrebbero essere interessati durante e dopo la transizione a Edge for Private Cloud 4.53.01. Questo strumento genera un report che descrive in dettaglio i proxy, i flussi condivisi e OpenLDAP interessati dalle modifiche e fornisce indicazioni su guide e strategie specifiche pertinenti ai proxy o ai flussi condivisi identificati.

Prerequisiti

Per eseguire questo strumento è necessario un computer basato su RHEL.
JRE 8 deve essere installato e configurato correttamente sulla macchina virtuale host per consentire l'esecuzione degli script dello strumento.
Lo strumento richiede l'endpoint (URL) corretto del server di gestione e credenziali amministrative valide per l'autenticazione e il recupero dei dati.
Lo strumento richiede l'accesso a una directory di lavoro designata (ad es./tmp) per estrarre i bundle, generare i log e archiviare l'output. Assicurati che questa directory disponga di spazio su disco sufficiente e delle autorizzazioni di lettura/scrittura appropriate.
Lo strumento richiede il file LDIF che utilizza il comando ldapsearch nella sezione Modifica OpenLDAP - Estrai dati LDAP per rilevare gli RDN lunghi più di 241 caratteri / byte.

Esecuzione dello strumento

Dopo aver soddisfatto tutti i prerequisiti elencati sopra, scarica lo strumento fornendo il nome utente e la password di Apigee che utilizzi per accedere al repository Apigee. Una volta scaricato, estrai l'archivio.

curl -u uName:pWord https://software.apigee.com/apigee/change-detector/change-detector-for-4.53.01_1.0.0.zip -o /tmp/change-detector-for-4.53.01_1.0.0.zip

unzip /tmp/change-detector-for-4.53.01_1.0.0.zip

Al termine del download, puoi eseguire il seguente comando per visualizzare tutte le opzioni disponibili per lo strumento:

./change-detector --help

Per eseguire lo strumento, utilizza il comando seguente e sostituisci i segnaposto con le tue informazioni:

export APIGEE_PASSWORD=[your_password]
./change-detector --username [your_username] --mgmt-url [MGMT url]

Per rilevare le voci LDAP RDN di grandi dimensioni, esegui questo comando:

./change-detector --username [your_username] --mgmt-url [MGMT url] --ldif-file [LDIF_file]

Lo strumento genera output in formato JSON o CSV che possono essere utilizzati direttamente o importati in uno strumento leggibile, come Fogli Google.

Comprendere l'output dello strumento

Organizzazione

Indica il nome dell'organizzazione in cui si trova l'artefatto. Per la modifica OpenLDAP, questo valore sarà None.

Ambiente

L'ambiente specifico (ad es. sviluppo, test, produzione) all'interno dell'organizzazione. Per la modifica OpenLDAP, questo valore sarà None.

Per le modifiche ai callout Java, se Artifact Type=env-level-jar, questo campo sarà None.

Nome artefatto

Questo campo indica il nome del proxy/flusso condiviso. Per la modifica di OpenLDAP, questo campo mostra l'entità LDAP dell'RDN.

Per le modifiche al richiamo Java, se Tipo di artefatto=env-level-jar o org-level-jar, questo campo sarà None.

Tipo di elemento

Per le modifiche a OAS e JSON, questa colonna specifica il tipo di artefatto, proxy o flusso condiviso.
Per la modifica del callout Java, questa colonna fornisce dettagli sul luogo o sul livello in cui viene caricato il file JAR interessato. Le risorse (JAR) possono essere memorizzate a uno dei tre livelli: org-level, env-level, proxy-level.
Per la modifica OpenLDAP, questo campo indica il file LDIF utilizzato nello strumento.

Revisione

Indica la revisione di cui è stato eseguito il deployment del proxy/flusso condiviso interessato. Per la modifica di OpenLDAP, sarà None.

Nome del criterio

Il nome della norma specifica che è stata identificata come potenziale problema. Per la modifica di OpenLDAP, sarà None.

Tipo di criterio

Indica il tipo di policy. Per la modifica di OpenLDAP, sarà None.

Tipo di impatto

Questo campo descrive il tipo specifico di modifica rilevata in un flusso proxy/condiviso.
Per la modifica di Callout Java, i rilevamenti delle modifiche relative a java-callout, lo strumento indica il callout Java interessato che fa riferimento ai file JAR presenti nella directory $APIGEE_ROOT/edge-message-processor/lib/deprecated delle versioni precedenti di Edge for Private Cloud nel seguente modo in questa colonna specifica.

deprecated library detected for NAME_OF_THE_AFFECTED_JAVA_CALLOUT_JAR

Per la modifica di OpenLDAP, questo campo mostra se l'RDN di un'entità LDAP ha superato i 241 byte o caratteri.

Campo specifico dell'impatto

Per la modifica di OAS, questo campo è il nome della variabile utilizzata nel tag Origine della policy.
Per la modifica JSON, questo campo mostra l'espressione o l'elemento JSONPath esatto che è stato segnalato come potenziale problema.
Per la modifica di Java Callout, questo campo contiene i dettagli delle classi esatte e il nome del JAR corrispondente (presente nella directory $APIGEE_ROOT/edge-message-processor/lib/deprecated delle versioni precedenti di Private Cloud) utilizzato/a cui viene fatto riferimento dal JAR JavaCallout interessato, il che comporterà errori durante l'upgrade alla versione 4.53.01 se non viene mitigato.

 ['Detected use of class CLASS_NAME_1 from JAR_NAME_1',
    Detected use of class CLASS_NAME_2 from JAR_NAME_2', 
  .. , .. , ]

Per la modifica di OpenLDAP, questo campo mostra l'RDN dell'entità LDAP che supera i 241 byte o caratteri.

Certezza dell'impatto

Questo campo indica il grado di certezza con cui lo strumento ha rilevato un determinato elemento. I valori per questa colonna possono essere Alto o Medio (in un secondo momento potrebbero essere aggiunti altri valori).

Un valore Alto indica che lo strumento ha stabilito che esiste un'altissima probabilità che l'elemento causi l'interruzione dell'applicazione dopo l'upgrade alla versione 4.53.01. Un valore Medio indica che lo strumento non ha informazioni chiare sul rilevamento e che sarebbero necessarie ulteriori strategie per prendere una decisione (ad esempio, acquisire la traccia per osservare le variabili risolte durante l'esecuzione del proxy).
I rilevamenti correlati alle modifiche di JavaCallout e OpenLDAP avranno sempre il valore Alto per le colonne di certezza dell'impatto.

Documentazione

Questa colonna fornisce un link ipertestuale alla documentazione di Apigee (sezioni pertinenti di questo articolo) che spiega il problema e i passaggi di mitigazione.