Support credential rotation for database backends when max_ttl is reached

Aperta
  • Qualcosa non va?
#929 0 commenti 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
java, spring, spring-boot
Ambito
backend, cloud, databases

Direzione di ricerca

Inizia dal modulo spring-cloud-vault-config-databases e traccia il modo in cui le risposte di database/creds/ selezionano RENEW o ROTATE in LeaseAwareVaultPropertySource e SecretLeaseContainer. Esamina gli eventi di lease esistenti e la configurazione del ciclo di vita, quindi determina quale comportamento proposto sia quello previsto e come le nuove credenziali debbano raggiungere i client del database dopo max_ttl; il completamento deve coprire il comportamento del ciclo di vita selezionato e i relativi test.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Context

The documentation for spring.cloud.vault.config.lifecycle.enabled states:

"enabled controls whether leases associated with secrets are considered to be renewed and expired secrets are rotated."

However, the database backends documentation explicitly states the opposite:

"Spring Cloud Vault does not support getting new credentials and configuring your DataSource with them when the maximum lease time has been reached. That is, if max_ttl of the Database
role in Vault is set to 24h that means that 24 hours after your application has started it can no longer authenticate with the database."

This creates confusion and a significant operational limitation for long-running applications using dynamic database credentials.

Problem

When spring-cloud-vault-config-databases fetches credentials from database/creds/<role>, the Vault response includes renewable: true. Spring Cloud Vault then selects RENEW mode
for the lease lifecycle:

DEBUG LeaseAwareVaultPropertySource : Requesting secrets from Vault at database/creds/my-role using RENEW

In RENEW mode:

  • The lease TTL is periodically extended (same credentials)
  • When max_ttl is reached, renewal fails
  • The credentials are revoked by Vault
  • No new credentials are fetched — the application loses database connectivity

The rotation mechanism ("expired secrets are rotated") exists in SecretLeaseContainer for non-renewable secrets (ROTATE mode), but database credentials are excluded because the
renewable flag in the Vault response drives the mode selection.

Prior issues

This has been reported multiple times and closed as "invalid" or redirected to StackOverflow:

  • #256 — "Cannot renew a MongoDB lease due to lease expired"
  • #152 — "Token expiry for PostgreSQL database tokens not supported?"
  • #557 — "VaultException Cannot renew lease during rotation of credentials"

In #152, the response was:

"Credentials obtained via Spring Cloud Vault are renewed until their terminal TTL expires but they are not rotated."

Why this matters

The renewable: true flag in Vault's response means the lease TTL can be extended, not that renewal is the only appropriate strategy. For database dynamic credentials, max_ttl is an
absolute ceiling. After it's reached:

  • The credentials are revoked regardless of renewal attempts
  • The application must read database/creds/<role> again to get new credentials
  • This is exactly what ROTATE mode does — but it's not used because renewable: true

Proposed solution

One or more of:

  1. Allow configuring the lifecycle mode per backend, e.g.: 
    spring.cloud.vault:
  mongodb:
    lifecycle-mode: rotate
  2. Default to ROTATE for database backends — the spring-cloud-vault-config-databases module knows it's a database backend, so it could override the mode regardless of the renewable flag.
  3. Fall back to ROTATE when RENEW fails — when a renewable lease reaches max_ttl and renewal fails, automatically re-read the secret (effectively switching from RENEW to ROTATE) instead of
    giving up.
  4. Fire SecretLeaseCreatedEvent with new credentials on rotation so applications can react (e.g., recreate MongoClient/DataSource).

Current workaround

Applications must implement custom credential rotation: manually read new credentials from Vault via VaultOperations, create a new database client, and schedule the next rotation based on
the lease duration. This bypasses Spring Cloud Vault's lifecycle management entirely.

Versions

  • Spring Cloud Vault: 5.0.1
  • Spring Boot: 4.0.3
  • Vault server: OpenBao 2.5.1
Lingua principale
Java
Stelle
292
Fork
152
Merge medio
8h 43m
PR unite (30g)
15

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di spring-cloud/spring-cloud-vault

Tutte le issue di spring-cloud/spring-cloud-vault

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.