Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
vault: limit token delay to not exceed token TTL
This commit fixes a bug in the Vault token renewal. When KES renews its current token `T1` and receives a new token `T2`, KES waits a certain amount of time before using `T2` to account for replication lag between Vault nodes. Vault tokens are not signed but static secrets. Each Vault node in a dist. cluster needs to know the token before being able to verify it. Without the usage delay described above, KES might send a request to a Vault node that has not received the new token `T2`, yet. Now, KES must also not wait longer then the remaining TTL of the current token `T1`. Otherwise, `T1` expires BEFORE KES starts using `T2`. This results in auth errors like the following: ``` Error making API request.\n\nURL: GET http://127.0.0.1:8200/v1/kv/data/my-key3\nCode: 403. Errors:\n\n* 2 errors occurred:\n\t* permission denied\n\t* invalid token\n\n" req.method=POST req.path=/v1/key/create/my-key3 req.ip=127.0.0.1 req.identity=a49fea12c5d1c69f1eba1e4697e62ccdbe389a80f317191892711b47d83c3e85 ``` This commit limits the max. time KES waits before using the new token `T2` to either half the remaining TTL of `T1` or 30s - whatever is shorter. This ensures that `T1` is still valid once KES switches to `T2`. Signed-off-by: Andreas Auernhammer <[email protected]>
- Loading branch information