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

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

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

Optimisations d'importation/de mise à jour des bundles de proxy

Edge effectuera une validation plus stricte sur les bundles de proxys d'API au moment du déploiement. Cette mise à jour permet de déployer plus rapidement les applications tout en réduisant les échecs de déploiement et les corruptions de bundles lorsque plusieurs utilisateurs importent le même bundle en même temps. Voici les modifications et comportements importants:

• Chaque bundle doit avoir une racine de système de fichiers de /apiproxy.
• Edge n'essaie 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.

Validations de déploiement

Jusqu'à cette version, Edge vérifiait passivement les déploiements de proxy d'API pour détecter des erreurs de validation spécifiques et avertir les organisations des correctifs requis via l'outil Advisory. Ces avis, décrits dans la section Avis sur les erreurs de déploiement, permettaient aux utilisateurs de résoudre les problèmes qui entraîneraient plus tard des erreurs de déploiement lorsque la validation était 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 de Spike Arrest entre les processeurs de messages. Lorsque cette valeur est définie sur "true", chaque processeur de messages divise sa limite de débit de pic 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élioration de 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éfinir le délai avant expiration de l'API par défaut pour tous les proxys sur 55 secondes pour éviter que le routeur expire plus tôt

Ajout d'un événement de journalisation pour les déploiements Canary

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

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 d'API lors de la validation 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 de gestion exige que l'application soit associée à un produit d'API. (L'UI de gestion applique déjà cette règle.)

Configuration du produit 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 ni 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 effectuant 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 d'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é.

Communication sécurisée par défaut entre le routeur et le processeur de messages

Correction de la mauvaise classification des erreurs de script Node.js

Adresse IP approuvée par la règle AccessControl

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