Infrastructure
Azure Key Vault : diagnostiquer latence et throttling avant de tourner les secrets
Un runbook de production pour qualifier une dégradation Key Vault en séparant latence, throttling, identité, réseau, cache applicatif, journaux et rollback avant de lancer une rotation de secrets.
Une application qui échoue à lire un secret Key Vault déclenche vite le mauvais réflexe : tourner le secret, redéployer l’application, élargir un rôle ou basculer vers une valeur locale. En production, ces actions peuvent aggraver l’incident. Si la cause réelle est un throttling Key Vault, une latence réseau, une identité managée instable, un cache expiré ou une règle firewall, la rotation du secret ne corrige rien et ajoute une nouvelle variable.
Le cas d’usage est une application Azure qui lit des secrets au démarrage et pendant certains traitements. Après un déploiement, les erreurs augmentent : timeouts, 429, 403, SecretNotFound, dépendances plus lentes ou pods qui redémarrent. Le runbook doit aider à décider si l’on corrige l’accès, réduit la pression, restaure une configuration, active un cache de secours ou rollbacke le changement applicatif.
Figer le symptôme avant la rotation
Avant de modifier un secret, il faut décrire l’échec exact. Une latence de lecture, un refus d’autorisation, une absence de secret et un quota dépassé n’ont pas la même correction.
Symptome observe
Application: api-checkout-prod
Key Vault: kv-shared-prod
Secret concerne: payment-provider-token
Premiere detection: 2026-07-11 08:40 UTC
Erreurs visibles: timeout, 429, 403, SecretNotFound ou echec TLS
Dernier changement: release applicative, role assignment, firewall, private DNS, version de secret, SDK
Questions avant action
Le secret existe-t-il dans la version attendue ?
L'identite appelee est-elle celle de production ?
Les erreurs touchent-elles un secret, un vault ou plusieurs applications ?
Le probleme arrive-t-il au demarrage, a chaque requete ou par rafales ?
Existe-t-il une version precedente de configuration ou de secret utilisable ?Cette trace évite de transformer un incident d’accès en incident de rotation. Le secret peut être valide pendant que le chemin pour le lire est cassé.
Séparer existence, identité et permissions
La première vérification doit être read-only. Elle confirme que le secret, sa version et l’identité utilisée existent encore dans le périmètre attendu.
VAULT="kv-shared-prod"
SECRET="payment-provider-token"
APP_IDENTITY_CLIENT_ID="00000000-0000-0000-0000-000000000000"
az keyvault secret show --vault-name "$VAULT" --name "$SECRET" --query "{name:name, enabled:attributes.enabled, created:attributes.created, updated:attributes.updated, expires:attributes.expires, version:id}" --output json
az role assignment list --assignee "$APP_IDENTITY_CLIENT_ID" --scope "$(az keyvault show --name "$VAULT" --query id --output tsv)" --query "[].{role:roleDefinitionName, scope:scope}" --output table
az keyvault show --name "$VAULT" --query "{name:name, publicNetworkAccess:properties.publicNetworkAccess, enableRbacAuthorization:properties.enableRbacAuthorization, networkAcls:properties.networkAcls}" --output jsonUn 403 doit être traité comme un sujet d’identité ou de politique, pas comme une preuve que le secret est mauvais. Un SecretNotFound doit vérifier le nom, la casse, la version, le slot ou l’environnement avant toute création manuelle.
Mesurer latence et throttling
Key Vault peut répondre, mais trop lentement ou avec des 429. Dans ce cas, le bon diagnostic porte sur le volume d’appels, les retries, le cache, les démarrages simultanés et les quotas, pas sur la valeur du secret.
let Window = 2h;
AzureDiagnostics
| where TimeGenerated > ago(Window)
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where OperationName has_any ("SecretGet", "SecretList")
| summarize
Calls = count(),
Throttled = countif(httpStatusCode_d == 429),
Forbidden = countif(httpStatusCode_d == 403),
NotFound = countif(httpStatusCode_d == 404),
P95LatencyMs = percentile(DurationMs, 95)
by bin(TimeGenerated, 5m), identity_claim_appid_g, OperationName, requestUri_s
| order by TimeGenerated ascSi la table ou les colonnes diffèrent selon la configuration de diagnostic, garde la logique : grouper par créneau, opération, identité, statut HTTP et durée. Le signal recherché est une rafale ou une régression nette après un changement.
Vérifier le réseau sans en faire le seul sujet
Private Endpoint, firewall et DNS privé peuvent intervenir dans un accès Key Vault, mais ils ne sont qu’une partie du chemin. Il faut prouver si l’application atteint le bon FQDN, par le bon resolver, avec le bon certificat et le bon statut.
VAULT_FQDN="kv-shared-prod.vault.azure.net"
getent hosts "$VAULT_FQDN" || nslookup "$VAULT_FQDN"
timeout 5 bash -lc "cat </dev/null >/dev/tcp/$VAULT_FQDN/443" && echo "tcp_connect_ok=true" || echo "tcp_connect_ok=false"
openssl s_client -connect "$VAULT_FQDN:443" -servername "$VAULT_FQDN" </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer
curl -sS -o /dev/null -w "status=%{http_code} time=%{time_total}s
" "https://$VAULT_FQDN/secrets?api-version=7.4"Une réponse 401 peut être saine pour un test sans jeton : elle prouve que le service répond. Un timeout, une résolution inattendue ou une erreur TLS oriente vers DNS, firewall, proxy ou inspection. Le rôle de Private Endpoint est alors de clarifier le chemin, pas de masquer un problème d’identité.
Regarder le comportement applicatif
Beaucoup d’incidents Key Vault viennent d’un usage applicatif trop agressif : lecture à chaque requête, absence de cache, retry sans backoff, démarrage simultané de dizaines d’instances ou invalidation de cache après déploiement.
A verifier cote application
Lecture du secret au demarrage ou sur chaque requete
Cache local et duree de validite
Retry avec backoff et jitter
Nombre d'instances qui redemarrent en meme temps
Version de SDK et timeout configure
Fallback controle si Key Vault est temporairement lent
Logs avec request ID Key Vault et identite utilisee
Bloquer la rotation quand
Les 429 augmentent apres scale-out
Le meme secret est lu plusieurs fois par requete
Le cache a ete desactive par une release
Les erreurs disparaissent en reduisant la concurrenceTourner un secret sous charge peut forcer encore plus de lectures et amplifier le throttling. La correction peut être un cache, un warm-up progressif, un backoff ou un rollback de release.
Décider correction, réduction de charge ou rollback
La décision doit rester bornée. On ne corrige pas un 429 avec un rôle plus large, ni un 403 avec une rotation de secret.
Corriger identite ou permissions
Les erreurs sont des 403
L'identite observee ne correspond pas a l'identite attendue
Le role ou l'access policy a change recemment
La correction est limitee au vault ou au secret necessaire
Reduire la pression
Les erreurs sont des 429 ou des timeouts par rafales
Les lectures augmentent apres scale-out ou redeploiement
Le cache ou le backoff est absent
La validation passe apres limitation de concurrence
Corriger reseau ou DNS
Le test depuis le workload ne joint pas vault.azure.net
La resolution pointe vers un chemin inattendu
Les logs Key Vault ne voient pas les requetes applicatives
La correction est une route, une regle firewall ou une zone DNS documentee
Rollbacker
Une release a modifie cache, SDK, timeout ou nom de secret
La version precedente restaure les lectures sans changer le secret
La rotation ajouterait un risque inutile pendant l'incident
Tourner le secret
Le secret est compromis, expire ou invalide chez le fournisseur cible
L'acces Key Vault est sain
Le plan de propagation et de retour arriere est pretLa rotation devient une décision métier et sécurité, pas un geste de diagnostic. Si le problème est le chemin de lecture, il faut le stabiliser avant de changer la valeur.
Valider après correction
La validation doit prouver que l’application lit le secret sans bruit et que la prochaine rotation reste possible.
Validation minimale
Secret lu avec l'identite de production attendue
Taux de 429 revenu a zero ou au niveau normal
P95 de lecture redevenu acceptable pour le demarrage applicatif
Plus de 403 ou 404 sur le secret concerne
Cache et backoff confirmes dans la configuration active
Logs applicatifs relies aux request IDs Key Vault
Aucune valeur de secret copiee dans un fichier ou une variable durable
Rollback propre
Restaurer version applicative ou configuration precedente
Rejouer une lecture controlee du secret
Conserver la preuve des statuts Key Vault avant/apres
Ouvrir une action de fond si cache, retry ou diagnostic settings manquentSi une exception temporaire a été ajoutée au firewall, au rôle ou au code, elle doit avoir un propriétaire et une date de retrait. Sinon l’incident devient une dérive permanente.
Conclusion
Une panne de lecture Key Vault n’est pas automatiquement une panne de secret. Le diagnostic doit séparer existence, identité, permission, réseau, latence, throttling, cache applicatif et changement récent.
La bonne sortie du runbook est une décision vérifiable : corriger un droit, restaurer un chemin réseau, réduire la pression, rollbacker une release ou tourner le secret uniquement si la valeur est réellement en cause. C’est ce qui évite de transformer une dégradation observable en rotation risquée et difficile à expliquer.