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

Les hôtes virtuels et TLS en libre-service sont désormais disponibles pour tous

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

Optimisations de l'importation/mise à jour des 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 les corruptions de bundle lorsque plusieurs utilisateurs importent le même bundle en même temps. Voici les principaux changements et comportements à noter :

• Chaque bundle doit avoir une racine de système de fichiers /apiproxy.
• Edge ne tente plus d'ignorer les chemins d'accès 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'à présent, Edge vérifiait passivement les déploiements de proxys d'API pour détecter des erreurs de validation spécifiques et informait les organisations des corrections requises à l'aide de l'outil Conseils. Ces conseils, décrits dans Conseils sur les erreurs de déploiement, étaient destinés à donner 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 SpikeArrest compatible avec l'autoscaling

Un nouvel élément <UseEffectiveCount> dans la règle Spike Arrest vous permet de distribuer automatiquement les nombres Spike Arrest entre les processeurs de messages. Lorsque la valeur 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 Règle Spike Arrest.

Améliorer la journalisation du processeur de messages en cas d'échec de la connectivité

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

Définissez le délai d'inactivité de l'API par défaut sur 55 secondes pour tous les proxys 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 du processeur 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 API lors de la vérification des appels d'API. Lorsque la propriété est définie sur "true" (valeur par défaut pour les organisations créées après cette version), les fonctionnalités suivantes sont appliquées.

Création d'applications

Lorsque vous créez une application de développeur ou d'entreprise, l'API Management 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é de l'exécution

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

• Un produit API n'inclut pas au moins un proxy d'API ou un chemin de ressource.
• Si la variable flow.resource.name du 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 Public Cloud doivent contacter l'assistance Apigee pour modifier la valeur de la propriété.

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

Corriger la classification incorrecte des erreurs de script Node.js

Règle AccessControl : adresse IP de confiance

Règle MessageLogging pour 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.