Se usó la API de Cloud Translation para traducir esta página.

Cambios en Edge para la nube privada 4.53.01

Descripción general de los cambios

Edge para nube privada 4.53.01 introduce varios cambios que mejoran la postura de seguridad de la plataforma y que incorporan versiones actualizadas del software y las bibliotecas requeridos. Estos cambios afectan a los siguientes tipos de políticas:

Política de validación de OAS (especificación de OpenAPI)
Políticas que admiten consultas de JSONPath
Políticas de JavaCallout que dependen de bibliotecas obsoletas
OpenLDAP
Cambios en el proveedor de criptografía

También puedes usar la herramienta de detección de cambios para identificar los cambios en los proxies, los flujos compartidos o cualquier otro artefacto de tu clúster que pueda causar interrupciones como resultado de esta actualización.

Descripción detallada de los cambios

En esta sección, se describen los cambios que se introdujeron en la versión 4.53.01 y que pueden interrumpir tus flujos de trabajo durante o después de la actualización. También se abordan los métodos para identificar posibles áreas problemáticas y las metodologías de mitigación o soluciones alternativas.

Política de validación de OAS (especificación de OpenAPI)

Contexto

La política de validación de OAS valida las solicitudes o respuestas entrantes según las reglas definidas en la especificación de OpenAPI 3.0 (JSON o YAML). Edge para Private Cloud 4.53.01 ofrece mejoras en la política de OAS (especificación de OpenAPI), que se centra en una validación más estricta y precisa de los cuerpos de respuesta de la API.

Cambios

Edge para la Nube Privada 4.53.01 introduce dos cambios importantes en la forma en que la política de OAS valida las respuestas de la API, lo que garantiza una mayor alineación con tu especificación de OpenAPI:

Situación 1:
- Comportamiento anterior: Si tu especificación de OpenAPI requería un cuerpo de respuesta, pero la respuesta real de la política de destino o upstream no incluía uno, la política no marcaría esto como un error de validación.
- Comportamiento actual: Ahora, la política devolverá correctamente un error de validación (por ejemplo, defines a response schema but no response body found) en esta situación, lo que indica una falta de coincidencia entre la respuesta esperada y la real.
Situación 2:
- Comportamiento anterior: Si tu especificación de OpenAPI indicaba de forma explícita que no se esperaba un cuerpo de respuesta, pero la respuesta real de la política de destino o upstream incluía un cuerpo, la política no generaría una falla.
- Comportamiento actual: En esta situación, la política ahora generará un error (por ejemplo, No response body is expected but one was found), lo que garantiza que las respuestas se ajusten estrictamente al esquema especificado.

Mitigación

Identifica los proxies o flujos compartidos que puedan verse afectados por la actualización con la herramienta de detección de cambios o a través de una revisión manual. Busca proxies en los que se cumpla alguna de las siguientes condiciones:

La política de OAS Validation está configurada con una etiqueta Source establecida en response.
La política de OAS Validation valida una respuesta de cualquier otra política que genere una respuesta.

Si usas la herramienta, se generará un resultado con el siguiente formato:

Organización	Entorno	Nombre del artefacto	Tipo de artefacto	Revisión	Nombre de la política	Tipo de política	Tipo de impacto	Campo específico del impacto	Certeza del impacto	Documentación
org2	dev	proxy2	proxy	4	oas-validateresponse	OASValidation	oas_content_type_handling	Source=calloutresponse	Medio	Política de validación de OAS
org1	prod	proxy3	sharedflow	1	oas-spec-validation	OASValidation	oas_content_type_handling	Source=response	Medio	Política de validación de OAS

Para obtener una explicación detallada de las columnas de la tabla de resultados, consulta la sección Comprende el resultado de la herramienta.

Una vez que se identifica un proxy o un flujo compartido, asegúrate de que la respuesta y tu especificación de OAS estén alineadas con respecto a la presencia o ausencia de un cuerpo de respuesta. Puedes usar el registro de seguimiento estándar de Apigee para revisar tus patrones de tráfico. Si el destino devuelve una respuesta de forma intermitente, usa otras políticas para validar la respuesta antes de que se pase a la política de validación de OAS.

Si tu archivo de especificación de OAS define un cuerpo de respuesta, la respuesta de la política de destino o upstream siempre debe proporcionar uno.
Si tu archivo de especificación de OAS no define un cuerpo de respuesta, la política de destino o upstream no debe enviar uno.

Actualiza la política de validación de la OAE o tu comportamiento objetivo según sea necesario antes de intentar actualizar a Private Cloud 4.53.01. Primero debes validar los flujos de trabajo identificados en tus entornos que no son de producción para minimizar el riesgo de interrupciones durante la actualización del clúster de producción.

Ruta de JSON

Contexto

Edge para Private Cloud 4.53.01 introdujo cambios en la forma en que se usan las expresiones de ruta de acceso JSON en varias políticas. Las expresiones JSONPath se pueden usar en políticas como ExtractVariable, RegularExpressionProtection y Data masking para analizar contenido JSON o almacenar valores en variables. Las expresiones JSONPath también se pueden usar en plantillas de mensajes generales para reemplazar variables por valores de forma dinámica durante la ejecución del proxy. Los nuevos formatos y expresiones JSONPath siguen los estándares más recientes de expresiones JSON.

Cambios

Es importante revisar los proxies de API o los flujos compartidos existentes para detectar políticas que utilicen expresiones JSONPath. Esto incluye, sin limitaciones, la política de Extract Variables, la política de Regular Expression Protection o cualquier política con Message Template que use JSONPath.

El siguiente input en formato JSON se usa para explicar los cambios:

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

Cambio en el comportamiento del comodín [*] de JSONPath para los valores de objetos
Se modificó el comportamiento del comodín [*] cuando se usa para acceder a todos los valores inmediatos de un objeto JSON. Anteriormente, $.object[*] devolvía los valores inmediatos incluidos en un solo objeto JSON. Con las bibliotecas actualizadas, el resultado ahora es un array que contiene estos valores.

Por ejemplo, $.store[*]:
Comportamiento anterior:
```
{
  "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"}
  ]
}
```
Comportamiento actual:
```
[
  [
    {"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"}]
  }
]
```
Acción:
Cambia la expresión JSONPath para segmentar simplemente el objeto principal (ejemplo: $.store) y segmentar directamente los elementos que se recuperaron anteriormente.
El punto final (.) de JSONPath en las rutas genera un error
Hay una validación más estricta para las expresiones JSONPath. Anteriormente, las rutas que terminaban con un punto final no válido (por ejemplo, $.path.to.element.) se ignoraban de forma silenciosa, y la búsqueda seguía devolviendo un resultado si coincidía el segmento de ruta válido anterior. Con la nueva versión, estas rutas con formato incorrecto ahora se identifican correctamente como no válidas y generarán un error.

Por ejemplo, $.store.book.
Comportamiento anterior:
```
[
  {"price":8.95,"category":"reference","author":"Nigel Rees"},
  {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
  {"price":8.99,"category":"fiction","author":"Herman Melville"}
]
```
Comportamiento actual:
```
ERROR: com.jayway.jsonpath.InvalidPathException - Path must not end with a '.' or '..'
```
Las políticas existentes que usen expresiones JSONPath con un punto final no intencional ahora fallarán con un InvalidPathException.
Acción:
Quita el punto final de cualquier expresión JSONPath que termine con uno. Por ejemplo, cambia $.store.book. a $.store.book.
Cambio en la estructura de salida del descenso recursivo de JSONPath (..)
Se modificó la forma en que se devuelven los resultados cuando se usa el operador (..) (descenso recursivo) para ubicar todas las ocurrencias de un elemento con nombre. Anteriormente, todos los elementos encontrados se aplanaban en una sola lista. Las bibliotecas actualizadas ahora devuelven una lista de listas, lo que preserva la estructura de agrupación original en la que se encontraron los elementos, en lugar de una sola lista plana.

Por ejemplo, $..book
Comportamiento anterior:
```
[
  {"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"}
]
```
Comportamiento actual:
```
[
  [
    {"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"}
  ]
]
```
Acción:
Actualiza la lógica de procesamiento posterior para tener en cuenta la nueva estructura de array anidado. Es probable que debas iterar el JSONArray externo y, luego, cada JSONArray interno para acceder a los elementos individuales.
La indexación de JSONPath después de la selección de varios elementos o el filtro devuelve un array vacío
Se produce un cambio en el comportamiento cuando se aplica un índice (por ejemplo, [0]) inmediatamente después de un selector de varios elementos (como [*]) o un filtro ([?(condition)]). Anteriormente, tales expresiones intentaban seleccionar el elemento en el índice especificado de los resultados combinados. Con la nueva versión, estas expresiones ahora devolverán un array vacío ([]).

Por ejemplo, $.store.book[*][0]
Comportamiento anterior:
```
{"category": "reference", "price": 8.95, "author": "Nigel Rees"}
```
Comportamiento actual:
```
[]
```
Acción:
Si es necesario filtrar y, luego, obtener un elemento específico del conjunto filtrado, procesa el array filtrado que devuelve JSONPath, por ejemplo, $..book[?(@.category == 'fiction')] y, luego, toma [0] del resultado anterior.
Cambio en el resultado del segmentado negativo de arrays de JSONPath
La nueva versión modificó el comportamiento del segmentado de arrays negativo (por ejemplo, [-2:], [-1:]). Anteriormente, cuando se aplicaba un segmento negativo a un array (que indicaba elementos desde el final del array), la versión anterior mostraba incorrectamente solo un elemento de ese segmento. La nueva versión ahora muestra correctamente una lista (array) que contiene todos los elementos que se encuentran dentro del rango negativo especificado.

Por ejemplo $.store.book[-2:]
Comportamiento anterior:
```
{"price":12.99,"category":"fiction","author":"Evelyn Waugh"}
```
Comportamiento actual:
```
[
  {"category":"fiction","author":"Evelyn Waugh","price":12.99},
  {"category":"fiction","author":"Herman Melville","price":8.99}
]
```
Acción:
Ahora se debe actualizar la lógica de procesamiento descendente para iterar el array JSON devuelto y obtener el resultado deseado.
Punto precedente más estricto de JSONPath
Se aplica una sintaxis más estricta para los elementos a los que se accede directamente desde la raíz. Cuando se accede a los elementos directamente desde la raíz sin un punto anterior (por ejemplo, $propertyelement), esa sintaxis ahora se considera un error y evitará la implementación del proxy.

Por ejemplo, $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"}
  ]
}
```
Comportamiento actual:
Proxy will fail to deploy.
Acción:

Cambia tu JSONPath para incluir el punto: $.propertyName (por ejemplo, $.store). Esto permitirá segmentar y recuperar el valor correctamente.
Expresiones JSONPath dinámicas
Presta especial atención a las políticas en las que la expresión JSONPath se proporciona a través de una variable (por ejemplo, {myJsonPathVariable} o {dynamicPath}). El valor de estas variables también se debe verificar en relación con los posibles cambios de comportamiento que se describieron anteriormente.

Mitigación

Identifica los proxies o flujos compartidos que podrían verse afectados por la actualización con la herramienta de detección de cambios o revisa manualmente tus proxies de API para buscar los patrones descritos. Si usas la herramienta, el resultado identificará el proxy o el flujo compartido afectados, la política pertinente y cualquier ruta de acceso JSON problemática, como se muestra en el siguiente ejemplo de resultado:

Organización	Entorno	Nombre del artefacto	Tipo de artefacto	Revisión	Nombre de la política	Tipo de política	Tipo de impacto	Campo específico del impacto	Certeza del impacto	Documentación
org1	dev	proxy1	proxy	4	EV-ExtractRequestParams	ExtractVariables	Cambio de comportamiento del comodín [*] de JSONPath para los valores de objeto	$.store[*]	Alta	Cambio en el comportamiento del comodín [*] de JSONPath para los valores de objetos
org2	prod	proxy2	sharedflow	1	EV-ExtractResponseParams	ExtractVariables	El punto final (.) de JSONPath en las rutas ahora causa un error	$.store.book.	Alta	El punto final (.) de JSONPath en las rutas de acceso provoca un error
org3	dev	proxy3	proxy	3	SC-FetchUserProfile	ServiceCallout	Cambio en la estructura de salida del descenso recursivo de JSONPath (..)	$..book	Alta	Cambio en la estructura de salida del descenso recursivo (..) de JSONPath
org4	prod	proxy4	sharedflow	2	RF-InvalidAuthToken	RaiseFault	La indexación de JSONPath después de la selección o el filtro de varios elementos ahora devuelve un array vacío	$.store.book[*][0]	Alta	La indexación de JSONPath después de la selección o el filtro de varios elementos devuelve un array vacío
org5	prueba	proxy5	proxy	6	SC-FetchProfileDetails	ServiceCallout	Cambio en el resultado del segmentado de arreglos negativo de JSONPath	$.store.book[-2:]	Alta	Cambio en el resultado del segmentado de arrays negativo de JSONPath
org6	prod	proxy6	proxy	2	ML-LogRequestDetails	MessageLogging	JSONPath Stricter Preceding Dot	$store	Alta	Punto anterior más estricto de JSONPath
org7	prueba	proxy7	proxy	5	RF-InvalidTokenDetails	RaiseFault	Expresiones JSONPath dinámicas	myJsonPathVariable	Medio	Expresiones JSONPath dinámicas

Para obtener una explicación detallada de las columnas en la tabla de resultados anterior, consulta la sección Comprende el resultado de la herramienta.

Para mitigar este problema, se necesita una estrategia integral. Este proceso implica decidir la ruta de actualización adecuada y aplicar la corrección necesaria para las expresiones JSONPath detectadas.

Elige el método de ruta de actualización que mejor se adapte a tus necesidades:

Migración sin tiempo de inactividad
Esta estrategia implica adquirir uno o más entornos nuevos para que puedas conectar nodos de procesadores de mensajes separados a ellos. Estos nodos del procesador de mensajes se pueden configurar para instalar la versión 4.53.01 y tener proxies con expresiones JSONPath modernas. Se pueden usar durante la actualización y se pueden retirar después de que se complete. Esta estrategia es fluida, pero implica adquirir temporalmente nodos de procesadores de mensajes adicionales para admitir una actualización sin problemas. A continuación, se indican los detalles:
- Crea un entorno nuevo y agrega nodos nuevos del procesador de mensajes de la versión 4.53.01 a este entorno nuevo.
- Sube el paquete del proxy de los proxies afectados al entorno nuevo y aplica las correcciones necesarias que se explican en la sección de corrección, e implementa el paquete del proxy actualizado en el entorno nuevo.
- Redirecciona el tráfico al entorno nuevo y anula la implementación de los proxies afectados del entorno anterior.
- Actualiza los nodos originales del procesador de mensajes a la versión 4.53.01. Implementa proxies que tengan correcciones para JSONPath en el entorno original.
- Vuelve a cambiar el tráfico al entorno anterior, que ahora tiene procesadores de mensajes en la versión 4.53.01 y un proxy modernizado para las nuevas expresiones jsonpath.
- Borra y retira el entorno nuevo y los nodos asociados.
Tiempo de inactividad y actualización
Esta estrategia implica obtener tiempo de inactividad para los proxies de API que usan expresiones de ruta JSON defectuosas. No es necesario adquirir nodos de procesadores de mensajes adicionales, pero causa interrupciones en el tráfico de la API para los proxies afectados.
- Identifica los proxies afectados con políticas afectadas y genera una revisión nueva para todos los proxies afectados.
- Aplica las correcciones necesarias implementando las correcciones que se explican en la sección de corrección en una nueva revisión del proxy. No implementes esto todavía.
- Adquiere tiempo de inactividad para los proxies afectados.
- Actualiza todos los procesadores de mensajes a la versión 4.53.01 de Edge para la nube privada. Ten en cuenta que es posible que los proxies existentes fallen en los procesadores de mensajes recién actualizados.
- Una vez que todos los procesadores de mensajes se hayan actualizado a la versión 4.53.01 de Edge para la nube privada , implementa la revisión del proxy recién creada con la expresión JSONPath corregida.
- Reanudar el tráfico en esos proxies
Rediseño del proxy antes de la actualización
Puedes rediseñar el proxy antes de actualizar a Edge para Private Cloud 4.53.01. En lugar de depender de expresiones específicas de rutas de acceso JSON, puedes obtener el mismo resultado con un método diferente.

Por ejemplo, si usas una política Extract Variable con una ruta de acceso JSON, podrías reemplazar la política por una política de JavaScript que extraiga datos similares antes de actualizar a la versión más reciente. Una vez que se complete la actualización, puedes volver a usar JSON Paths con formatos más nuevos en tu proxy.

Cambios en JavaCallout

Contexto

Edge para Private Cloud 4.53.00 y versiones anteriores solía contener un directorio llamado deprecated ($APIGEE_ROOT/edge-message-processor/lib/deprecated) que contenía un conjunto de bibliotecas JAR. Estas bibliotecas estaban disponibles para usarse en código Java en la política de JavaCallout y tu código Java personalizado las podía usar de forma directa o indirecta.

Cambios

El directorio deprecated se quitó en la versión 4.53.01 de Edge para la nube privada. En caso de que tu código Java dependa de esas bibliotecas, los proxies que usen esas llamadas externas de Java fallarán cuando los procesadores de mensajes se actualicen a la versión 4.53.01. Para evitar este tipo de fallas, sigue los pasos de mitigación que se indican a continuación antes de actualizar los procesadores de mensajes a la versión 4.53.01.

Mitigación

Revisa tus políticas de Java Callout y los archivos JAR asociados con la herramienta de detección de cambios o de forma manual. Comprueba si alguna de las políticas hace referencia a bibliotecas presentes en el directorio “obsoleto” de los procesadores de mensajes actuales.

Si usas la herramienta que proporciona Apigee para las detecciones anteriores, esta generará un informe como el que se muestra en la siguiente tabla . Específicamente, se dirige a las políticas que hacen referencia a archivos JAR que se encuentran en el directorio $APIGEE_ROOT/edge-message-processor/lib/deprecated de versiones anteriores de Edge para la nube privada.

La herramienta generará informes en el siguiente formato:

Organización	Entorno	Nombre del artefacto	Tipo de artefacto	Revisión	Nombre de la política	Tipo de política	Tipo de impacto	Campo específico del impacto	Certeza del impacto	Documentación
org1	Ninguno	Ninguno	org-level-jar	Ninguno	Ninguno	java-callout	Se detectó una biblioteca obsoleta para `simple-javacallout-o1-jar-1.jar`	["Se detectó el uso de la clase `org.apache.commons.io.FileUtils` de `commons-io-2.5.jar`", "Se detectó el uso de la clase `org.apache.commons.io.input.XmlStreamReaderException` de `commons-io-2.5.jar`"]	Alta	Cambios en JavaCallout
org3	env3	Ninguno	env-level-jar	Ninguno	Ninguno	java-callout	Se detectó una biblioteca obsoleta para `fat-javacallout-e3-jar-1.jar`	["Se detectó el uso de la clase `org.apache.http.impl.auth.NTLMSchemeFactory` de `httpclient-4.5.2.jar`"]	Alta	Cambios en JavaCallout
org1	env1	p1	proxy-level-jar	1	Ninguno	java-callout	Se detectó una biblioteca obsoleta para `simple-javacallout-p1-jar-1.jar`	["Se detectó el uso de la clase `org.apache.commons.lang3.builder.ToStringBuilder` de `commons-lang3-3.4.jar`", "Se detectó el uso de la clase `org.apache.commons.lang3.Validate` de `commons-lang3-3.4.jar`"]	Alta	Cambios en JavaCallout

Para obtener una explicación detallada de las columnas en la tabla de resultados anterior, consulta la sección Comprende el resultado de la herramienta.

Una vez que hayas identificado las bibliotecas obsoletas , puedes seguir uno de los métodos que se indican a continuación para mitigar el problema.
- Colocación de recursos (recomendado si tienes una pequeña cantidad de archivos .jar o bibliotecas del directorio en desuso a los que hacen referencia los archivos .jar de Java-Callout)
  - Sube los archivos .jar identificados como recursos obsoletos al nivel deseado: revisión del proxy de API, entorno u organización.
  - Continúa con la actualización del software de Apigee como de costumbre.
- Colocación manual (recomendada si tienes una gran cantidad de archivos .jar o bibliotecas a los que hacen referencia los archivos .jar de Java-Callout)
  - En cada nodo del procesador de mensajes, crea un directorio nuevo llamado external-lib en la ruta de acceso $APIGEE_ROOT/data/edge-message-processor/.
  - Copia los archivos JAR identificados en este directorio external-lib desde el directorio en desuso: cp $APIGEE_ROOT/edge-message-processor/lib/deprecated/some.jar $APIGEE_ROOT/data/edge-message-processor/external-lib/some.jar
  - Asegúrate de que el directorio y los archivos JAR subyacentes sean legibles para el usuario de Apigee: chown -R apigee:apigee $APIGEE_ROOT/data/edge-message-processor/external-lib
  - Continúa con la actualización del software de Apigee como de costumbre.

Cambio en OpenLDAP

Contexto

OpenLDAP se puede usar en Edge Private Cloud para la autenticación y la autorización. En Edge para la nube privada 4.53.01, el software OpenLDAP que se incluye en Apigee se actualizó de la versión 2.4 a la 2.6.

Cambios

En OpenLDAP 2.6, el nombre distintivo relativo (RDN) se limita a aproximadamente 241 bytes o caracteres. Esta limitación es un límite máximo obligatorio y no se puede modificar.

Impacto

Se producen errores de replicación o importación para las entradas con RDN demasiado grandes.
Si intentas crear entidades como organizaciones, entornos, roles personalizados, permisos, etcétera, es posible que se muestre el mensaje de error: "message": "[LDAP: error code 80 - Other]".
Se ve afectado cualquier DN que supere los 241 bytes en el LDAP de Apigee. Estos DN impedirán la actualización correcta del software de Apigee OpenLDAP, por lo que deberás seguir estrategias de mitigación para estos elementos antes de poder continuar con la actualización.

En general, en el LDAP de Apigee, los DN largos se relacionan con los permisos, ya que se crean concatenando varias entidades. Estas entradas de permisos son especialmente propensas a problemas de actualización.

Por ejemplo:

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

Por lo general, los nombres de la organización, el entorno y el rol tienen longitudes tales que los RDN en LDAP terminan siendo más pequeños que 241 bytes.

Mitigación

Antes de actualizar a la versión 4.53.01:

Los siguientes pasos te ayudarán a verificar la presencia de RDN largos en tu clúster LDAP 2.4 existente.

#1: Extrae datos de LDAP

Usa el comando ldapsearch para encontrar el nombre distinguido (dn) y redireccionar el resultado a un archivo:

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

Asegúrate de que el archivo DN.ldif anterior tenga entradas LDAP.

#2: Identifica los RDN largos

La herramienta de detección de cambios usa un archivo LDIF generado para identificar los RDN de LDAP que superan los 241 bytes o caracteres.

La herramienta generará informes en el siguiente formato:

Organización	Entorno	Nombre del artefacto	Tipo de artefacto	Revisión	Nombre de la política	Tipo de política	Tipo de impacto	Campo específico del impacto	Certeza del impacto	Documentación
Ninguno	Ninguno	cn=`really-long-name`,ou=userroles,o=edge-platform,ou=organizations,dc=apigee,dc=com	archivo ldif	Ninguno	None	Ninguno	El RDN de LDAP supera los 241 caracteres	cn=`really-long-name`	Alta	Cambio en OpenLDAP

Para obtener una explicación detallada de las columnas en la tabla de resultados anterior, consulta la sección sobre cómo comprender el resultado de la herramienta.

Si el comando anterior no produce ningún resultado, significa que ningún RDN de la configuración existente de LDAP supera los 241 bytes o caracteres. Puedes continuar con la actualización como de costumbre.

Si el comando anterior genera un resultado, indica la presencia de RDN que superan los 241 bytes o caracteres. En el caso de estos elementos, sigue los pasos de mitigación que se describen en el paso 3 antes de continuar con la actualización de Edge para la nube privada 4.53.01.

Nº 3: Controla los RDN largos

Si se recibe un resultado del paso 2, significa que hay RDN que superan los 241 bytes o caracteres. Sigue los pasos de mitigación que se indican a continuación:

Revisa las entradas de LDAP que superen los 241 bytes.

Si se trata del nombre del rol personalizado, la app, el producto de API o cualquier otra entidad que sea el factor principal que causa que el RDN sea largo, migra a usar una entidad alternativa con un nombre más corto.
Si el nombre de la organización o del entorno es el principal factor que contribuye a que el RDN sea largo, deberás migrar a una organización o un entorno diferente con un nombre más corto.

Sigue repitiendo los pasos anteriores hasta que tu LDAP no tenga ningún RDN con una longitud superior a 241 bytes. Una vez que alcances este estado, continúa con la actualización de la versión de la nube privada como de costumbre.

Cambios en el proveedor de criptografía

Contexto

Este cambio se trasladó de Edge para la nube privada 4.53.00. En Edge para Private Cloud 4.53.00, el proveedor de criptografía interno se actualizó de Bouncy Castle (BC) a Bouncy Castle FIPS (BCFIPS) para habilitar la compatibilidad con FIPS.

Cambios

Si las políticas JavaCallout dependen del uso del proveedor de BC original, en especial cuando se usa una funcionalidad de seguridad que se reforzó en el proveedor de BCFIPS (por ejemplo, usar un par de claves común para el cifrado y la firma), esas políticas JavaCallout deberán modernizarse. Es posible que las políticas de JavaCallout que intentan cargar el proveedor de criptografía de Bouncy Castle con el nombre BC fallen porque el proveedor predeterminado cambió. Es posible que, posteriormente, se interrumpan las políticas que usan el proveedor de BC. Ya no se podrá acceder a las implementaciones personalizadas que dependan del proveedor de BC anterior, por lo que se deberán revisar y volver a implementar.

Mitigación

La solución alternativa recomendada es usar el proveedor de BCFIPS. Las implementaciones personalizadas de JavaCallout que se basaban en el proveedor anterior deberán revisarse y volver a implementarse con el proveedor Bouncy Castle FIPS, al que se puede acceder con la cadena "BCFIPS".

Herramienta de detección de cambios

Se creó una herramienta de detección de cambios para identificar los proxies, las políticas y los flujos compartidos de Apigee que podrían verse afectados durante la transición a Edge para Private Cloud 4.53.01 y después de ella. Esta herramienta genera un informe en el que se detallan los proxies, los flujos compartidos y OpenLDAP implementados que se ven afectados por los cambios, y proporciona orientación a guías y estrategias específicas pertinentes para los proxies o flujos compartidos identificados.

Requisitos previos

Se requiere una máquina basada en RHEL para ejecutar esta herramienta.
JRE 8 debe estar instalado y configurado correctamente en la máquina virtual host para permitir que se ejecuten las secuencias de comandos de la herramienta.
La herramienta requiere el extremo (URL) correcto del servidor de administración y credenciales administrativas válidas para la autenticación y la recuperación de datos.
La herramienta requiere acceso a un directorio de trabajo designado (p.ej.,/tmp) para extraer paquetes, generar registros y almacenar la salida. Asegúrate de que este directorio tenga suficiente espacio en el disco y los permisos de lectura y escritura adecuados.
La herramienta requiere el archivo LDIF con el comando ldapsearch en la sección OpenLDAP change - Extract LDAP data para detectar los RDN largos de más de 241 caracteres o bytes.

Cómo ejecutar la herramienta

Después de cumplir con todos los requisitos previos mencionados anteriormente, descarga la herramienta y proporciona el nombre de usuario y la contraseña de Apigee que usas para acceder al repositorio de Apigee. Una vez que se descargue, extrae el archivo descargado.

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

Una vez que se complete la descarga, puedes ejecutar el siguiente comando para ver todas las opciones disponibles de la herramienta:

./change-detector --help

Para ejecutar la herramienta, usa el siguiente comando y reemplaza los marcadores de posición por tu información:

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

Para detectar las entradas LDAP de RDN grandes, ejecuta el siguiente comando:

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

La herramienta genera resultados en formato JSON o CSV que se pueden consumir directamente o importar a una herramienta legible, como Hojas de cálculo de Google.

Comprende el resultado de la herramienta

Organización

Apunta al nombre de la organización en la que se encuentra el artefacto. Para el cambio de OpenLDAP, será None.

Entorno

Es el entorno específico (p.ej., desarrollo, prueba y producción) dentro de la organización. Para el cambio de OpenLDAP, será None.

En el caso de los cambios en los textos destacados de Java, si el tipo de artefacto es env-level-jar, este campo será None.

Nombre del artefacto

Este campo indica el nombre del proxy o del flujo compartido. En el caso de un cambio de OpenLDAP, este campo muestra la entidad LDAP del RDN.

En el caso de los cambios en los textos destacados de Java, si el tipo de artefacto es env-level-jar o org-level-jar, este campo será None.

Tipo de artefacto

Para los cambios en OAS y JSON, esta columna especifica el tipo de artefacto, proxy o flujo compartido.
En el caso del cambio de Java Callout, esta columna proporciona detalles sobre el lugar o el nivel en el que se subió el archivo .jar afectado. Los recursos (JAR) se pueden almacenar en uno de los tres niveles: org-level, env-level y proxy-level.
En el caso del cambio de OpenLDAP, este campo indica el archivo LDIF que se usa en la herramienta.

Revisión

Apunta a la revisión implementada del proxy o flujo compartido afectado. En el caso del cambio de OpenLDAP, será None.

Nombre de la política

Es el nombre de la política específica que se identificó como un posible problema. En el caso del cambio de OpenLDAP, será None.

Tipo de política

Apunta al tipo de política. En el caso del cambio de OpenLDAP, será None.

Tipo de impacto

En este campo, se describe el tipo específico de cambio detectado en un flujo compartido o de proxy.
En el caso del cambio de Java Callout, las detecciones de cambios relacionados con java-callouts, la herramienta apunta al java-callout afectado que tiene referencias a los archivos JAR presentes en el directorio $APIGEE_ROOT/edge-message-processor/lib/deprecated de versiones anteriores de Edge para Private Cloud de la siguiente manera en esta columna en particular.

deprecated library detected for NAME_OF_THE_AFFECTED_JAVA_CALLOUT_JAR

En el caso del cambio de OpenLDAP, este campo muestra si el RDN de alguna entidad de LDAP superó los 241 bytes o caracteres.

Campo de impacto específico

En el caso de un cambio en la OAS, este campo es el nombre de la variable que se usa en la etiqueta Fuente de la política.
En el caso de los cambios en JSON, este campo muestra la expresión o el elemento JSONPath exactos que se marcaron como un posible problema.
En el caso del cambio de Java Callout, este campo contiene los detalles de las clases exactas y el nombre del archivo JAR correspondiente (presente en el directorio $APIGEE_ROOT/edge-message-processor/lib/deprecated de versiones anteriores de la nube privada) que usa o al que hace referencia el archivo JAR de JavaCallout afectado, lo que generará errores al actualizar a la versión 4.53.01 si no se mitiga.

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

En el caso de los cambios de OpenLDAP, este campo muestra el RDN de la entidad de LDAP que supera los 241 bytes o caracteres.

Certidumbre del impacto

Este campo indica el grado de certeza con el que la herramienta detectó un elemento en particular. Los valores de esta columna pueden ser Alto o Medio (es posible que se agreguen más valores más adelante).

Un valor Alto significa que la herramienta determinó que existe una probabilidad muy alta de que el elemento provoque que la aplicación deje de funcionar después de actualizarla a la versión 4.53.01. Un valor Medio indica que la herramienta no tiene claridad sobre la detección y se necesitarían más estrategias para tomar una determinación (por ejemplo, capturar el registro para observar las variables resueltas durante la ejecución del proxy).
Las detecciones relacionadas con los cambios de JavaCallout y OpenLDAP siempre tendrán el valor Alto en las columnas de certeza del impacto.

Documentación

En esta columna, se proporciona un hipervínculo a la documentación de Apigee (secciones pertinentes de este artículo) que explica el problema y los pasos para mitigarlo.