Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE REQUEST] Allow to set per-lease defaults of lifecycle parameters #47

Closed
lkubb opened this issue Apr 24, 2024 · 0 comments · Fixed by #44
Closed

[FEATURE REQUEST] Allow to set per-lease defaults of lifecycle parameters #47

lkubb opened this issue Apr 24, 2024 · 0 comments · Fixed by #44
Assignees

Comments

@lkubb
Copy link
Collaborator

lkubb commented Apr 24, 2024

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.

@lkubb lkubb mentioned this issue Apr 24, 2024
3 tasks
@lkubb lkubb self-assigned this Apr 24, 2024
@lkubb lkubb closed this as completed in #44 Apr 24, 2024
@lkubb lkubb closed this as completed in 5430e54 Apr 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant