180202 - Notes de version d'Apigee Edge pour le cloud public

Les hôtes virtuels en libre-service et TLS sont désormais en disponibilité générale

Pour en savoir plus sur leur utilisation, consultez À propos des hôtes virtuels et de TLS/SSL.

Optimisations de l'importation/mise à jour de bundles de proxy

Edge effectuera une validation plus poussée des bundles de proxy d'API au moment du déploiement. Cette mise à jour permet d'accélérer les déploiements tout en réduisant les échecs de déploiement et la corruption des bundles lorsque plusieurs utilisateurs importent le même bundle en même temps. Voici les principaux changements et comportements :

• Chaque bundle doit avoir une racine de système de fichiers de /apiproxy.
• Edge ne tente plus d'ignorer les chemins dans le dossier de ressources d'un bundle de proxy d'API. (Par exemple, Edge n'ignore plus les répertoires .git ou .svn.)
• Si un bundle contient une configuration non valide de plusieurs fichiers de configuration XML de proxy d'API (par exemple, apiproxy/proxy1.xml et apiproxy/proxy2.xml), il n'est pas garanti que la configuration utilisée pour le proxy d'API soit la bonne.

Validations de déploiement

Jusqu'à cette version, Edge vérifiait passivement les déploiements de proxy d'API pour des erreurs de validation spécifiques et informait les organisations des correctifs requis à l'aide de l'outil Advisory. Ces avis, décrits dans Avis d'erreur de déploiement, étaient destinés à laisser aux utilisateurs le temps de résoudre les problèmes qui entraîneraient ultérieurement des erreurs de déploiement lorsque la validation serait activée dans le produit. Avec cette version, Edge effectue désormais ces validations et génère des erreurs de déploiement en conséquence.

Règle Spike Arrest compatible avec l'autoscaling

Un nouvel élément <UseEffectiveCount> dans la règle Spike Arrest vous permet de répartir automatiquement les nombres Spike Arrest entre les processeurs de messages. Lorsque cette option est définie sur true, chaque processeur de messages divise sa limite de débit de pointe autorisée par le nombre de processeurs de messages actuellement actifs, en ajustant la limite de débit à mesure que des processeurs de messages sont ajoutés ou supprimés. La valeur par défaut est "false" lorsque l'élément est omis de la règle.

Pour en savoir plus, consultez la section Spike Arrest policy.

Améliorer la journalisation des processeurs de messages en cas d'échec de connexion

Mettre à niveau Rhino vers la version 1.7.8 et Trireme vers la version 0.9.1

Définir le délai d'inactivité par défaut de l'API pour tous les proxys sur 55 secondes afin d'éviter que le routeur n'expire plus tôt

Ajouter un événement de journalisation pour les déploiements Canary

Autoriser les vérifications d'état HTTPS autosignées

La résolution DNS des processeurs de messages doit utiliser un pool de threads asynchrone

Améliorations de la sécurité des produits d'API

Une nouvelle propriété au niveau de l'organisation, features.keymanagement.disable.unbounded.permissions, renforce la sécurité des produits d'API lors de la vérification des appels d'API. Lorsque la propriété est définie sur "true" (la valeur par défaut pour les organisations créées après cette version), les fonctionnalités suivantes sont appliquées.

Création d'applications

Lors de la création d'une application de développeur ou d'entreprise, l'API de gestion exige que l'application soit associée à un produit d'API. (L'interface utilisateur de gestion l'applique déjà.)

Configuration des produits d'API

Pour créer ou mettre à jour un produit d'API, celui-ci doit inclure au moins un proxy d'API ou un chemin de ressource dans sa définition.

Sécurité d'exécution

Les appels d'API sont rejetés par un produit d'API dans les situations suivantes :

• Un produit d'API n'inclut pas au moins un proxy d'API ou un chemin de ressource.
• Si la variable flow.resource.name dans le message n'inclut pas de chemin de ressource que le produit d'API peut évaluer.
• Si l'application qui effectue l'appel d'API n'est pas associée à un produit d'API.

Pour les organisations existantes, la valeur de la propriété est "false" et doit être modifiée explicitement par un utilisateur disposant des autorisations d'administrateur système. Cela signifie que les clients du cloud public doivent contacter l'assistance Apigee pour modifier la valeur de la propriété.

Sécuriser par défaut la communication entre le routeur et le processeur de messages

Corriger la mauvaise classification des erreurs de script Node.js

Adresse IP approuvée par la règle AccessControl

La règle MessageLogging doit résoudre à nouveau le DNS à intervalles réguliers

Validation de la chaîne de certificats TLS

Lorsque vous créez un alias de keystore à l'aide d'une chaîne de certificats, vous devez séparer les certificats de la chaîne par un saut de ligne. Edge génère désormais une erreur 400 Bad Request lors de la création d'un alias si votre chaîne de certificats ne répond pas à cette exigence.