11 commentaires
hello. tu as configuré le champ refreshInterval dans ton ExternalSecret ? par défaut c'est 1h je crois. si tu le mets à une valeur plus basse genre 5m ça devrait forcer ESO à aller chercher la nouvelle version plus souvent.
# exemple de config ExternalSecret
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: my-db-secret
spec:
refreshInterval: "5m" # ou même "1m" si besoin
secretStoreRef:
name: vault-secret-store
kind: ClusterSecretStore
target:
name: my-app-db-secret
creationPolicy: Owner
data:
- secretKey: username
remoteRef:
key: database/creds/my-app
property: username
- secretKey: password
remoteRef:
key: database/creds/my-app
property: password
ouais j'ai déjà essayé refreshInterval à 1m mais ça ne suffit pas. les pods n'ont toujours pas la nouvelle valeur de password tant que je ne relance pas le déploiement. on dirait que le secret kubernetes est mis à jour mais que le pod ne s'en rend pas compte
c'est normal en fait. quand un Secret Kubernetes est mis à jour les pods qui le montent via un volume ou qui l'utilisent via des variables d'env ne le voient pas instantanément. le kubelet met un certain temps à rafraîchir les volumes (jusqu'à 60s par défaut) et les variables d'env ne sont pas dynamiques
la solution propre pour gérer la rotation des secrets d'appli c'est d'utiliser l'annotation kubernetes.io/change-cause ou un hash du secret en tant que label sur le déploiement. ça force un redéploiement des pods quand le secret change. y a des outils comme reloader de stakater qui font ça très bien
ah reloader ! j'en ai déjà entendu parler. donc l'idée c'est de laisser eso mettre à jour le secret k8s et ensuite reloader détecte la modif et force un rollout des déploiements concernés c'est ça ?
exactement. reloader monitorise les secrets et les configmaps. quand il détecte un changement sur un secret ou une configmap qui est référencé par un déploiement il relance les pods. c'est la façon la plus courante de gérer la rotation de secrets et configmaps sans downtime si ton app est stateless
ouais et pour les apps stateful attention quand même aux rotations de creds DB faut que l'app soit capable de se reconnecter à la DB avec les nouvelles creds sans perdre d'état. sinon faut gérer ça au niveau de l'appli directement ou avec un init container qui fetch les creds
d'acc. nos apps sont majoritairement stateless donc reloader devrait faire le taf. pour les stateful on verra plus tard. je vais l'installer et le tester. ça me semble être une bonne piste. merci à tous pour les infos super utiles !
pense aussi à bien configurer les politiques de rotation dans Vault lui-même pour t'assurer que les baux sont correctement gérés et que Vault renouvelle bien les secrets avant l'expiration pour qu'ESO ait toujours un secret frais à récupérer
oui la config Vault est déjà prête pour ça. le problème venait vraiment de la propagation du nouveau secret au pod. je teste reloader demain et je vous dis. thx encore !
Hello la team ! Bon j'ai installé reloader et configuré les annotations sur mes déploiements. Ça marche nickel ! Dès que Vault renouvelle un secret et qu'ESO le met à jour dans Kubernetes, reloader détecte le changement et force un rolling update. Les pods ont les nouvelles creds en quelques minutes. C'est parfait ! Merci beaucoup pour l'aide !
Laisser une réponse
Vous devez être connecté pour poster un message !
Salut tout le monde. on utilise Vault pour nos secrets sur EKS et External Secrets Operator pour injecter les secrets dans les pods. la rotation manuelle marche bien mais j'ai un souci avec la rotation automatique des secrets d'applis (type db credentials) qui sont des leased secrets de Vault. quand le secret expire et que Vault le renouvelle ESO ne semble pas le récupérer directement. les pods continuent d'utiliser l'ancien secret jusqu'à un redémarrage manuel ou un re-déploiement. y a moyen de forcer ESO à rafraîchir plus vite sans redémarrer le pod ?