How does it handle credential rotation?

[estahn]

If credentials expire (either max_ttl or manual rotation) how is that handled and propagated to the workload, e.g. is a deployment being rotated?

[fcgravalos]

Hey @estahn sorry for the late response.

secrets-manager will re-login with its own appRole credentials:

https://github.com/tuenti/secrets-manager/blob/master/backend/vault.go#L153

Let me know if this answers your question

[estahn]

@fcgravalos, apologies for the late response. I actually meant the workloads, e.g. pods. Assuming credentials have been compromised or changed based on ttl, how are the pods notified/rotated?

[fcgravalos]

@estahn my apologies too, since I closed this never got to read your message.

Please let me know if this is your scenario: You have some sort of a secret, let's say user/pass kv stored in Vault. And you get that secret updated, because you want to change it or got compromised. So you go ahead and push your new version to Vault. secrets-manager will update the secret in kubernetes, that's all. From this point onwards it's application developer responsibility to decide how to behave when pod's secrets change. The same way you would do it if you create your secret manually in kubernetes.

There's a similar use case for configmaps, you want your application dinamically reload the configuration when a configmap gets updated, so you provide a way of doing so by sending a SIGHUP signal or with an HTTP endpoint. confimap-reload will watch for configmap changes and reload your app using the mechanism you provide with.

secrets-manager does trigger any kind of reload to your application. Though it's something I've been considering.

Does this answer your question?

[estahn]

Thanks, it does answer my question. No auto-magic :)

On Mon, 18 Nov 2019 at 3:42 am, Fernando notifications@github.com wrote:

@estahn https://github.com/estahn my apologies too, since I closed this never got to read your message.

Please let me know if this is your scenario: You have some sort of a secret, let's say user/pass kv stored in Vault. And you get that secret updated, because you want to change it or got compromised. So you go ahead and push your new version to Vault. secrets-manager will update the secret in kubernetes, that's all. From this point onwards it's application developer responsibility to decide how to behave when pod's secrets change. The same way you would do it if you create your secret manually in kubernetes.

There's a similar use case for configmaps, you want your application dinamically reload the configuration when a configmap gets updated, so you provide a way of doing so by sending a SIGHUP signal or with an HTTP endpoint. confimap-reload https://github.com/jimmidyson/configmap-reload will watch for configmap changes and reload your app using the mechanism you provide with.

secrets-manager does trigger any kind of reload to your application. Though it's something I've been considering.

Does this answer your question?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tuenti/secrets-manager/issues/46?email_source=notifications&email_token=AACYNPUAV47P6U3LRQVNHP3QUFX5PA5CNFSM4I6XPLQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEIQLVA#issuecomment-554763732, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACYNPRS5YE32WWSKNZD6TTQUFX5PANCNFSM4I6XPLQQ .