You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When requesting a cached lease from the lease store, there are several parameters that determine revocation and renewals:
valid_for: If the cached lease is not valid for at least this amount of time, try to renew it before returning or revoke it and remove it from the cache.
renew_increment: When renewing a lease, request a new validity period of this amount of time from the current point of time. If unset, the Vault server defaults to the lease's default TTL.
revoke_delay: Revocations are implemented by reducing the validity period of the lease to a short amount of time and removing them from the cache. Immediate revocations would a) require another policy and b) cause outages because the credentials would become invalid before new ones are available. This value sets the amount of time before the lease is revoked by the Vault server.
Depending on the importance and default attributes of the lease, one might want to apply different defaults to these lifecycle parameters.
Describe the solution you'd like
When creating a lease, allow to specify defaults for these parameters and cache them together with the lease. When requesting/renewing/revoking it, ensure they are followed.
Of special importance is valid_for. If one manages credentials using these leases and the highstate periodicity is higher than this value, the lease might expire before a new one is issued.
The corresponding lifecycle default (min_ttl) should thus always be followed at a minimum, regardless of the valid_for parameter passed to the store.
Describe alternatives you've considered
Always pass the values when requesting the lease.
The latter point can be worked around using an engine module or a beacon + reactors, but that's brittle.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
When requesting a cached lease from the lease store, there are several parameters that determine revocation and renewals:
valid_for
: If the cached lease is not valid for at least this amount of time, try to renew it before returning or revoke it and remove it from the cache.renew_increment
: When renewing a lease, request a new validity period of this amount of time from the current point of time. If unset, the Vault server defaults to the lease's default TTL.revoke_delay
: Revocations are implemented by reducing the validity period of the lease to a short amount of time and removing them from the cache. Immediate revocations would a) require another policy and b) cause outages because the credentials would become invalid before new ones are available. This value sets the amount of time before the lease is revoked by the Vault server.Depending on the importance and default attributes of the lease, one might want to apply different defaults to these lifecycle parameters.
Describe the solution you'd like
When creating a lease, allow to specify defaults for these parameters and cache them together with the lease. When requesting/renewing/revoking it, ensure they are followed.
Of special importance is
valid_for
. If one manages credentials using these leases and the highstate periodicity is higher than this value, the lease might expire before a new one is issued.The corresponding lifecycle default (
min_ttl
) should thus always be followed at a minimum, regardless of thevalid_for
parameter passed to the store.Describe alternatives you've considered
Always pass the values when requesting the lease.
The latter point can be worked around using an engine module or a beacon + reactors, but that's brittle.
The text was updated successfully, but these errors were encountered: