Azure-sdk-for-java: [BUG] KeyVaultPropertySource Class / méthode getPropertyNames chargera tous les secrets (y compris désactiver les secrets) dans le coffre de clés

Créé le 13 août 2020 · 10Commentaires · Source: Azure/azure-sdk-for-java

Décrivez le bogue
Actuellement, le coffre de clés active la fonction de suppression réversible par défaut. S'il est créé / supprimé, le certificat entraînera le plantage de l'application Jave car il chargera le secret désactivé.
La classe KeyVaultPropertySource charge tous les secrets dans KeyVault. Il ne doit pas charger les secrets désactivés dans la méthode getPropertyNames
À propos, la solution de contournement est purgée du certificat. Mais il peut être préférable de l'améliorer au niveau du SDK car il n'y a pas de demande de chargement du secret supprimé de manière réversible

Exception ou trace de pile
Ajoutez le journal des exceptions et la trace de la pile si disponible

Reproduire
Étapes pour reproduire le comportement:
A. Créé des certificats KeyVault (non secrets) et supprimé les certificats après que l'application java s'est plantée.
C. les certificats créent automatiquement un identifiant secret lors de la création de nouveaux certificats
D. Et après avoir supprimé le certificat, le système Azure DÉSACTIVE l'identifiant secret
E. Dans ce cas, l'application Java essaie de lire le secret DISABLED au moment de l'exécution
je. Et puis l'application java a planté.
La bibliothèque est com.microsoft. azur: azure-keyvault : 1.2.2
Extrait de code
Ajoutez l'extrait de code à l'origine du problème.

@Value ("$ {cluster-app-sb-connection-string}")
String connectionString;
@Value ("$ {cluster-app.sb.topic-name}")
String topicName;
Comportement prévisible
Une description claire et concise de ce à quoi vous vous attendiez.

Captures d'écran
Le cas échéant, ajoutez des captures d'écran pour expliquer votre problème.

Configuration (veuillez compléter les informations suivantes):

OS: [par exemple iOS]
IDE: [par exemple IntelliJ]
Version de la bibliothèque utilisée

Contexte supplémentaire
Ajoutez ici tout autre contexte sur le problème.

Liste de contrôle des informations
Veuillez vous assurer que vous avez ajouté toutes les informations suivantes ci-dessus et cocher les champs obligatoires, sinon nous traiterons l'émetteur comme un rapport incomplet

[x] Description du bogue ajoutée
[] Étapes de repro ajoutées
[] Informations de configuration ajoutées

Client azure-spring azure-spring-keyvault customer-reported question

Source

TonySh127-ms

Commentaire le plus utile

Le problème est dû au fonctionnement du démarreur Spring Boot pour Key Vault Secrets. nous n'avons pas filtré les secrets désactivés. maintenant je crée un PR pour résoudre le problème

zhoufenqin le 25 août 2020

👍2 👀1

Tous les 10 commentaires

@ TonySh127-ms utilisez-vous le démarreur Key Vault ou le SDK directement?

saragluna le 14 août 2020

Discuté avec @ TonySh127-ms hors ligne et le client a utilisé le démarreur à ressort pour keyvault. Besoin d'une confirmation du côté du SDK pour savoir si le nouveau SDK résout ce type de problème.

saragluna le 17 août 2020

@AlexGhiondea @ vcolin7 pouvez-vous s'il vous plaît faire un suivi?

joshfree le 17 août 2020

👍2

merci @joshfree et @saragluna. En attente de mise à jour de @AlexGhiondea et @ vcolin7 . S'il vous plaît laissez-moi savoir si cela ne peut pas être résolu à court terme. Je peux l'expliquer côté client. Merci beaucoup de votre temps encore!

TonySh127-ms le 18 août 2020

Salut @ TonySh127-ms,

J'ai passé du temps à examiner ce problème et j'ai trouvé ce qui suit: le comportement que le client voit est causé par le fonctionnement du démarreur Spring Boot pour Key Vault Secrets. Fondamentalement, chaque fois qu'une application Spring utilisant ce démarreur s'exécute, elle obtiendra les noms de tous les secrets existants dans un coffre-fort donné en appelant le point de terminaison / secrets, qui charge tous les secrets activés et désactivés (pas ceux supprimés), l'application sera alors récupérer les détails de secrets spécifiques si nécessaire. Ce n'est pas un problème avec le service Key Vault ou le SDK, mais simplement une conséquence du codage du démarreur Spring Boot.

Une solution à court terme n'est pas d'utiliser le démarreur Spring Boot mais le SDK Key Vault lui-même directement. De cette façon, le client aura plus de contrôle sur les secrets chargés et à quel moment au cours du cycle de vie des applications.

De plus, je ne pouvais pas reproduire un cas où mon application se bloquait en chargeant trop de secrets simplement en créant et en supprimant un certificat dans un coffre-fort. Pour faire quelque chose comme ça, j'aurais besoin de plus d'informations de la part du client: quelles dépendances ils utilisent dans leur projet, y compris les versions et les exemples de code où cela peut être reproduit.

vcolin7 le 19 août 2020

@ vcolin7 avons-nous une option qui pourrait passer au SDK qui ne charge que les secrets activés? Il semble que nous ne devrions pas charger les secrets désactivés dans notre intégration Spring.

saragluna le 20 août 2020

@saragluna Malheureusement, il n'y a aucun paramètre sur

vcolin7 le 20 août 2020

Le problème est dû au fonctionnement du démarreur Spring Boot pour Key Vault Secrets. nous n'avons pas filtré les secrets désactivés. maintenant je crée un PR pour résoudre le problème

zhoufenqin le 25 août 2020

👍2 👀1

@ TonySh127-ms
Nous construisons un package de développement , vous pouvez l'essayer.
Suivez cette page pour télécharger le package de développement

zhoufenqin le 28 août 2020

😄1

Salut l'équipe, le problème a été confirmé résolu. Nous pouvons fermer ce fil maintenant. Merci beaucoup à tous pour vos efforts et votre temps !!!

TonySh127-ms le 8 sept. 2020

🎉1

Cette page vous a été utile?

0 / 5 - 0 notes