Azure-sdk-for-java: [BUG] Die Methode KeyVaultPropertySource Class / getPropertyNames lädt alle Geheimnisse (einschließlich der Deaktivierung von Geheimnissen) in den Schlüsseldepot

Erstellt am 13. Aug. 2020  ·  10Kommentare  ·  Quelle: Azure/azure-sdk-for-java

Beschreibe den Fehler
Derzeit aktiviert der Schlüsseldepot standardmäßig die Soft-Delete-Funktion. Wenn das Zertifikat erstellt / gelöscht wird, stürzt die Jave-App ab, da das deaktivierte Geheimnis geladen wird.
Die KeyVaultPropertySource-Klasse lädt alle Geheimnisse in den KeyVault. Es sollten keine deaktivierten Geheimnisse in die Methode getPropertyNames geladen werden
Übrigens wird die Problemumgehung das Zertifikat gelöscht. Es kann jedoch im SDK-Teil noch besser verbessert werden, da keine Anforderung zum Laden des weich gelöschten Geheimnisses besteht

Ausnahme oder Stapelverfolgung
Fügen Sie das Ausnahmeprotokoll und die Stapelverfolgung hinzu, falls verfügbar

Fortpflanzen
Schritte zum Reproduzieren des Verhaltens:
A. Erstellt KeyVault-Zertifikate (nicht geheim) und löscht die Zertifikate, nachdem die Java-Anwendung abgestürzt ist.
C. Die Zertifikate erstellen automatisch eine geheime Kennung, wenn neue Zertifikate erstellt werden
D. Nach dem Löschen des Zertifikats deaktiviert das Azure-System die geheime Kennung
E. In diesem Fall versuchen Java-Anwendungen, das DISABLED-Geheimnis zur Laufzeit zu lesen
ich. Und dann stürzte die Java-App ab.
Die Bibliothek ist com.microsoft. azure :
Code-Auszug
Fügen Sie das Code-Snippet hinzu, das das Problem verursacht.

@Value ("$ {cluster-app-sb-connection-string}")
String connectionString;
@Value ("$ {cluster-app.sb.topic-name}")
String topicName;
Erwartetes Verhalten
Eine klare und präzise Beschreibung dessen, was Sie erwartet hatten.

Screenshots
Fügen Sie gegebenenfalls Screenshots hinzu, um Ihr Problem zu erklären.

Setup (bitte vervollständigen Sie die folgenden Informationen):

  • Betriebssystem: [zB iOS]
  • IDE: [zB IntelliJ]
  • Version der verwendeten Bibliothek

Zusätzlicher Kontext
Fügen Sie hier einen anderen Kontext zum Problem hinzu.

Informationscheckliste
Bitte stellen Sie sicher, dass Sie alle oben genannten Informationen hinzugefügt haben, und aktivieren Sie die erforderlichen Felder. Andernfalls wird der Emittent als unvollständiger Bericht behandelt

  • [x] Fehlerbeschreibung hinzugefügt
  • [] Repro-Schritte hinzugefügt
  • [] Setup-Informationen hinzugefügt
Client azure-spring azure-spring-keyvault customer-reported question

Hilfreichster Kommentar

Das Problem wird dadurch verursacht, wie der Spring Boot-Starter für Key Vault Secrets funktioniert. Wir haben keine behinderten Geheimnisse gefiltert. Jetzt erstelle ich eine PR, um das Problem zu beheben

Alle 10 Kommentare

@ TonySh127-ms Verwenden Sie den Key Vault Starter oder den SDK direkt?

Besprochen mit @ TonySh127-ms offline und der Kunde verwendete den Spring-Boot-Starter für Keyvault. Benötigen Sie eine Bestätigung von der SDK-Seite, ob das neue SDK diese Art von Problem löst.

@AlexGhiondea @ vcolin7 können Sie bitte

danke @joshfree und @saragluna. Warten auf Update von @AlexGhiondea und @ vcolin7 . Bitte lassen Sie mich wissen, wenn es kurzfristig nicht behoben werden kann. Ich kann es dem Kunden erklären. Vielen Dank nochmal für Ihre Zeit!

Hallo @ TonySh127-ms,

Ich habe mich einige Zeit mit diesem Problem befasst und Folgendes festgestellt: Das Verhalten des Kunden wird durch die Funktionsweise des Spring Boot-Starters für Key Vault Secrets verursacht. Grundsätzlich erhält die Anwendung jedes Mal, wenn eine Spring-Anwendung ausgeführt wird, die diesen Starter verwendet, die Namen aller vorhandenen Geheimnisse in einem bestimmten Tresor, indem sie den Endpunkt / Secrets aufruft, der alle aktivierten und deaktivierten Geheimnisse (nicht die gelöschten) lädt Rufen Sie bei Bedarf Details zu bestimmten Geheimnissen ab. Dies ist kein Problem mit dem Key Vault-Dienst oder dem SDK, sondern nur eine Folge der Codierung des Spring Boot-Starters.

Eine kurzfristige Lösung besteht darin, nicht den Spring Boot-Starter, sondern das Key Vault SDK selbst direkt zu verwenden. Auf diese Weise hat der Kunde mehr Kontrolle darüber, welche Geheimnisse wann während eines Anwendungslebenszyklus geladen werden.

Außerdem konnte ich keinen Fall reproduzieren, in dem meine Anwendung beim Laden zu vieler Geheimnisse abstürzte, indem ich nur ein Zertifikat in einem Tresor erstellte und löschte. Um so etwas zu tun, würde ich mehr Informationen vom Kunden benötigen: Welche Abhängigkeiten verwenden sie in ihrem Projekt, einschließlich Versionen und Beispielcode, wo dies reproduziert werden kann.

@ vcolin7 Haben wir eine Option, die an das SDK übergeben werden kann, das nur aktivierte Geheimnisse lädt? Scheint, als sollten wir die deaktivierten Geheimnisse in unserer Spring-Integration nicht laden.

@saragluna Leider gibt es keinen Parameter, an den wir den Dienst übergeben können, um uns nur aktivierte Geheimnisse zu geben: /

Das Problem wird dadurch verursacht, wie der Spring Boot-Starter für Key Vault Secrets funktioniert. Wir haben keine behinderten Geheimnisse gefiltert. Jetzt erstelle ich eine PR, um das Problem zu beheben

@ TonySh127-ms
Wir bauen ein Entwicklungspaket , Sie können es versuchen.
Folgen Sie dieser Seite , um das Entwicklungspaket herunterzuladen

Hallo Team, das Problem wurde behoben behoben. Wir können diesen Thread jetzt schließen. Vielen Dank an alle, große Mühe und Zeit !!!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen