You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
And finally set the decryption secret in the Flux Kustomization to sops-hcvault
but it doesn't tell you how to create the token.
but having such token would mean: create a static vault token in a secret and let flux use this to contact the transit engine in vault to decrypt data.
However, there is no such thing as a static token with an infinite ttl in vault. Only the root tokens have this, which should be discarded after provisioning of vault.
The solution provided is a bit vague as it will mean that after a certain while (max ttl i assume ( 768h/24h=32days )) before the kustomizations will start failing since the token will be discarded.
I tried this solution which in principle works great. but either the token has to be renewed or another form of authentication has to implemented for it to stay operational.
so flux kustomizations which such token will die in ~25 days
I assume flux has to be prepared to be working with JWK authentication and the flux cluster contacting has to be configued in vault using the kubernetes authentication endpoint.
The text was updated successfully, but these errors were encountered:
squaricdot
changed the title
SOPS + Hashicorp vault solution is incomplete.
SOPS + Hashicorp Vault: token expiration issue
Nov 1, 2022
The documentation tells you:
"
Create a secret the vault token, the key name must be sops.vault-token to be detected as a vault token:
echo $VAULT_TOKEN | kubectl create secret generic sops-hcvault \ --namespace=flux-system \ --from-file=sops.vault-token=/dev/stdin
"
And finally set the decryption secret in the Flux Kustomization to sops-hcvault
but it doesn't tell you how to create the token.
but having such token would mean: create a static vault token in a secret and let flux use this to contact the transit engine in vault to decrypt data.
However, there is no such thing as a static token with an infinite ttl in vault. Only the root tokens have this, which should be discarded after provisioning of vault.
The solution provided is a bit vague as it will mean that after a certain while (max ttl i assume ( 768h/24h=32days )) before the kustomizations will start failing since the token will be discarded.
I tried this solution which in principle works great. but either the token has to be renewed or another form of authentication has to implemented for it to stay operational.
Token example
`$ vault token lookup -accessor 1234
Key Value
accessor 1234
creation_time 1666649823
creation_ttl 768h
display_name token
entity_id n/a
expire_time 2022-11-25T22:17:03.662337175Z
explicit_max_ttl 0s
id n/a
issue_time 2022-10-24T22:17:03.662345724Z
meta
num_uses 0
orphan true
path auth/token/create
policies [default read_transit_prod]
renewable true
ttl 609h57m45s
type service`
so flux kustomizations which such token will die in ~25 days
I assume flux has to be prepared to be working with JWK authentication and the flux cluster contacting has to be configued in vault using the kubernetes authentication endpoint.
The text was updated successfully, but these errors were encountered: