Partager via

Configuration centralisée

  • Article

Conseil

Ce contenu est un extrait du livre électronique, Cloud Native .NET apps for Azure (Architecture d’applications .NET natives cloud pour Azure), disponible dans la documentation .NET ou au format PDF à télécharger gratuitement pour le lire hors connexion.

Télécharger le PDF

Cloud Native .NET apps for Azure eBook cover thumbnail.

Contrairement à une application monolithique où tout s’exécute dans une seule instance, une application native cloud se compose de services indépendants distribués sur des machines virtuelles, des conteneurs et des régions géographiques. La gestion des paramètres de configuration pour des dizaines de services interdépendants peut être compliquée. Les copies en double des paramètres de configuration entre différents emplacements sont sujettes aux erreurs et difficiles à gérer. Une configuration centralisée est indispensable pour les applications natives cloud distribuées.

Comme indiqué dans le chapitre 1, les recommandations selon la méthodologie de l’application douze facteurs exigent une séparation stricte entre le code et la configuration. La configuration doit être stockée à l’extérieur de l’application et lue à partir de là lorsque nécessaire. Le stockage des valeurs de configuration sous forme de constantes ou de valeurs littérales dans le code est une violation. Les mêmes valeurs de configuration sont souvent utilisées par de nombreux services de la même application. De plus, nous devons prendre en charge les mêmes valeurs dans plusieurs environnements : développement, test et production. La bonne pratique est de les stocker dans un magasin de configuration centralisé.

Le cloud Azure présente d’excellentes options.

Azure App Configuration

Azure App Configuration est un service Azure complètement managé qui stocke les paramètres de configuration non secrets dans un emplacement sécurisé et centralisé. Les valeurs stockées peuvent être partagées entre plusieurs services et applications.

Le service est simple à utiliser et offre plusieurs avantages :

  • Représentations et mappages de clés/valeurs flexibles
  • Étiquetage avec des étiquettes Azure
  • Interface utilisateur dédiée pour la gestion
  • Chiffrement des informations sensibles
  • Interrogation et récupération par lots

Azure App Configuration garde les modifications apportées aux paramètres clé-valeur pendant sept jours. La fonctionnalité d’instantané ponctuel vous permet de recréer l’historique d’un paramètre et même d’effectuer une restauration si un déploiement a échoué.

App Configuration met automatiquement en cache chaque paramètre pour éviter un nombre excessif d’appels au magasin de configuration. L’opération d’actualisation attend que la valeur mise en cache d’un paramètre ait expiré avant de mettre ce dernier à jour, même si sa valeur change dans le magasin de configuration. Le délai d’expiration du cache par défaut est de 30 secondes. Vous pouvez remplacer le délai d’expiration.

App Configuration chiffre toutes les valeurs de configuration en transit et au repos. Les noms de clés et les étiquettes servent d’index pour récupérer les données de configuration et ne sont pas chiffrés.

Même si App Configuration offre une sécurité renforcée, Azure Key Vault reste le meilleur emplacement de stockage pour les secrets d’application. Key Vault propose un chiffrement au niveau du matériel, des stratégies d’accès précises, ainsi que des opérations de gestion, comme la rotation des certificats. Vous pouvez créer des valeurs App Configuration qui font référence à des secrets stockés dans un coffre de clés.

Azure Key Vault

Key Vault est un service managé permettant de stocker les secrets et d’y accéder de façon sécurisée. Un secret est un élément pour lequel vous voulez contrôler étroitement l’accès. Il peut s’agir de clés d’API, de mots de passe ou de certificats. Un coffre est un groupe logique de secrets.

Key Vault réduit considérablement les risques de fuite accidentelle des secrets. Grâce à Key Vault, les développeurs d’applications n’ont plus besoin de stocker les informations de sécurité dans leur application. Avec cette pratique, vous n’avez plus besoin de stocker ces informations dans votre code. Considérons l’exemple d’une application ayant besoin de se connecter à une base de données. Dans ce cas, plutôt que d’inclure la chaîne de connexion dans le code de l’application, vous pouvez simplement la stocker en toute sécurité dans Key Vault.

Vos applications peuvent accéder en toute sécurité aux informations nécessaires en utilisant des URI. Ces URI permettent aux applications de récupérer des versions spécifiques d’un secret. Aucune écriture de code personnalisé n’est nécessaire pour protéger les informations secrètes stockées dans Key Vault.

L’accès à Key Vault nécessite une authentification et une autorisation appropriées de l’appelant. En règle générale, chaque microservice natif cloud utilise une combinaison ClientId/ClientSecret. Il est important de garder ces informations d’identification en dehors du contrôle de code source. Une bonne pratique consiste à les définir dans l’environnement de l’application. L’accès direct à Key Vault à partir d’AKS peut être obtenu avec Key Vault FlexVolume.

Configuration dans eShop

L’application eShopOnContainers contient des fichiers de paramètres d’application locaux avec chaque microservice. Ces fichiers sont archivés dans le contrôle de code source, mais n’incluent pas de secrets de production tels que des chaînes de connexion ou des clés API. En production, les paramètres individuels peuvent être remplacés par des variables d’environnement par service. L’injection de secrets dans les variables d’environnement est une pratique courante pour les applications hébergées, mais ne fournit pas de magasin de configuration central. Pour prendre en charge la gestion centralisée des paramètres de configuration, chaque microservice comprend un paramètre permettant de basculer entre son utilisation des paramètres locaux ou des paramètres Azure Key Vault.

References

PrécédentSuivant