Vault expiration revoked lease logs

Vault
1

Hello All,

We have installed vault with integrated storage(raft enabled) in kubernetes.
We are primarily using secret engine kv-2 to keep our secrets and have kubernetes auth enabled.
We have sidecar injector as vault agent to get secrets for the pod.

Config:

vault auth enable kubernetes

vault write auth/kubernetes/config \
    kubernetes_host=https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT

the only place we have add the ttl is the role

vault write auth/kubernetes/role/internal \
    bound_service_account_names=internal \
    bound_service_account_namespaces=default \
    policies=internal \
    ttl=96h

even though the whole setup is working fine, lately we are seeing a lot of logs of

[INFO] expiration: revoked lease: lease_id=auth/kubernetes/login/h56ceaa43f672e5a2e66ef55f705b751f94dfdc8084bc5ab5a001e5a45d426e48

and we are not sure how to make sense of this(we are very new to vault). should we be worried or this are common logs or shall we increase the ttl to higher numbers.

Any suggestion will be of great help to us.
Thanks

2

It’s not something to be concerned about. It’s normal part of the operation of Vault. The sidecar (vault agent in a pod) will renew it’s token, faster than the ttl to make sure it has access, and is available so you may get the messages faster than the 96h ttl you have set.

3

@aram Thanks for confirming. But is there any use of the 96h ttl?. even after 96 hours i don’t see any issue with getting the secrets from vault agent. what role does it play then? Thanks

4

Yes. The kube service take care of the renewals of the token behind the scene, it uses the service account and jwt token to authenticate so it always has a good token. If you ever redeploy/remove your service account then you would need to re-auth manually again once.

The 96 hours is the maximum amount of time a token can live for, it’s renewed before it gets to that late stage, if it can.