Closed allanrogerr closed 6 months ago
How this works as of today is: We check how long the token is valid. We wait 1/3 of the token lifetime before we request a new one. On success the previous token is replaced and no longer used.
So each KES pod creates at most 3 tokens before the first one expires (due to 1/3 timer). When KES requests a 4th token the first must have been expired. Similarly, when it requests the 5th, the 2nd must have been expired and so on.
Bug description
See issue reproduced here using Hashicorp vault: https://github.com/allanrogerr/public/wiki/kes-create-tokens
1.- After the kes server or pods have started, and before the expected expiration of the vault token as configured in the vault role, kes sends new token requests prematurely to vault, inflating the number of tokens beyond the strictly necessary.
2.- Upon a kes or kes pod restart or kes pod replica increase, kes also sends new token requests immediately.
Expected behavior
Consider the below vault role configuration:
1.- New tokens should only be requested just before 10m (in this case) have elapsed. This however may be too proactive and inefficient. Or new tokens could be requested only when a new token is required and no valid tokens are available.
2.- Sending new token requests should not be necessary if valid tokens already exist and are usable by kes.
Additional context
What version of Go are you using (
go version
)? n/a - usingminio operator 5.0.11
withWhat operating system and processor architecture are you using (
go env
)?Anything else that is important?