Cambios en Edge para la nube privada 4.53.01

Descripción general de los cambios

Edge para Private Cloud 4.53.01 introdujo varios cambios que mejoran la postura de seguridad de la plataforma, ya que incorporan versiones actualizadas de software y bibliotecas. Estos cambios afectan lo siguiente:

  • Política de validación de OAS (especificación de OpenAPI)
  • Políticas que admiten consultas de JSONPath
  • Política de texto destacado de Java que se basa en bibliotecas obsoletas
  • OpenLDAP

En esta sección, se describen varios tipos de cambios introducidos en la versión 4.53.01 que pueden interrumpir tus flujos de trabajo durante la actualización o después de ella. 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 enfoca en una validación más estricta y precisa de los cuerpos de respuesta de la API.

Cambios

Edge para Private Cloud 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: Ahora, la política generará un error (por ejemplo, No response body is expected but one was found) en esta situación, lo que garantiza que las respuestas se ajusten estrictamente al esquema especificado.

Mitigación

Identifica los proxies o flujos compartidos en los que la política de validación de OAS está configurada con una etiqueta Source establecida en response o aquellos que validan la respuesta de cualquier otra política que genere una respuesta.

Una vez que se identifica un proxy o un flujo compartido, asegúrate de que haya alineación entre la respuesta y la especificación de OAS. La respuesta debe alinearse estrictamente con tu especificación de OpenAPI en cuanto 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 respuestas de forma intermitente, usa otras políticas para validarlo antes de la política de la 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"}
      ]
    }
  }
}
  1. 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.

  2. 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.

  3. 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.

  4. La indexación de JSONPath después de la selección o el filtro de varios elementos 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.

  5. Cambio en el resultado del segmentado de arrays negativo 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.

  6. Punto anterior 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.

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

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 que se interrumpen.

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 la actualización. 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 podría haberlas usado 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

  1. Revisa tus políticas de JavaCallout y los archivos JAR asociados, y determina si alguno de ellos hace referencia a alguna biblioteca presente en el directorio “deprecated” de tus procesadores de mensajes actuales o la usa. Ten en cuenta que los textos destacados de Java pueden usar archivos JAR subidos como recursos a nivel de la organización o del entorno. También puedes considerar estas bibliotecas.
  2. 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

Busca los RDN que superen los 241 bytes o caracteres en el archivo DN.ldif anterior:

cat /tmp/DN.ldif |  grep '^dn:' | gawk -F',|dn: ' '{ rdn = $2; char_count = length(rdn); cmd = "echo -n \"" rdn "\" | wc -c"; cmd | getline byte_count; close(cmd); if (char_count > 241 || byte_count > 241) { print rdn, "(chars: " char_count ") (bytes: " byte_count ")"; }}'
o=VeryLongOrgNameWithMoreThan241Chars.... (chars: 245) (bytes: 245)
cn=VeryLongCustomRoleNameWithMoreThan241Chars.... (chars: 258) (bytes: 258)

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 encriptado 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 automatizada de detección de cambios

Pronto se lanzará una herramienta de detección de cambios. Esta herramienta podrá analizar e identificar proxies de API, flujos compartidos, recursos y RDN de LDAP que podrían verse afectados por los diversos cambios que se describen en este artículo. Esta herramienta debería ayudar a identificar varias entidades propensas a fallar durante o después de la actualización a Edge para Private Cloud 4.53.01.