search

minio / kes

Key Managament Server for Object Storage and more
https://min.io/docs/kes/concepts/
GNU Affero General Public License v3.0
456 stars 94 forks source link

kes creates unnecessary token creation requests #427

Closed allanrogerr closed 6 months ago

allanrogerr commented 7 months ago

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:

vault write auth/approle/role/kes-role \
...
token_ttl=10m \
...

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

  1. What version of Go are you using (go version)? n/a - using minio operator 5.0.11 with

    sh-5.1$ ./kes --version
Version    2023-11-10T10-44-28Z   commit=2e9975bcf79af1759b8733668560fbe2f7a4c951
Runtime    go1.21.4 linux/amd64   compiler=gc
License    AGPLv3                 https://www.gnu.org/licenses/agpl-3.0.html
Copyright  2015-2024 MinIO Inc.   https://min.io

  2. What operating system and processor architecture are you using (go env)?

    uname -a
Linux kes-operator 6.2.0-35-generic #35~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Oct  6 10:23:26 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
    k3s --version
k3s version v1.28.4+k3s2 (6ba6c1b6)
go version go1.20.11

  3. Anything else that is important?

allanrogerr commented 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.