Optional cache TTL for secrets

[aaguilartablada]

Description

Currently, the provider utilizes a non-expiring cache for secrets. This causes an issue where changes made in Vault (such as updated values or new keys added to an existing secret) are not propagated to the application.

This PR resolves this by introducing a new configuration parameter, cache-ttl, which allows users to define a Time-to-Live (TTL) for cached secrets, ensuring they are periodically refreshed.

Implementation

A new configuration parameter, cache-ttl, has been introduced. This value is an integer specifying the cache duration in seconds.

To simplify the implementation and avoid background garbage collection, secrets are not proactively evicted from the cache upon expiry. Instead, a "lazy-expiry" approach is used:

• When a secret is requested, its cache timestamp is checked.

• If the secret has expired (i.e., now > cachedtime + ttl), it is re-fetched from Vault.

• If the secret has not expired, the cached version is served.

To support this, the underlying data structure for the cache (previously a simple map) has been modified. It now stores a new struct that holds both the secret payload and its "cached-at" timestamp.

Usage

Command line

# 1 minute TTL
vault-csi-provider -cache-ttl=60

Kubernetes Deployment

args:
- -cache-ttl=60

[hashicorp-cla-app]

All committers have signed the CLA.

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}