[FEATURE] Polling secrets in injection mode

[hoangtoni]

Is your feature request related to a problem? Please describe. When using injection mode updated secrets are not reflected as the secrets are not polled regularly - or it is not documented, but was half confimed in slack chat

Describe the solution you'd like There should be an additional parameter to resync and then restart mutated pods, if a secret is updated in the background

Describe alternatives you've considered Trigger Eventgrid and use a function to recreate the pod, therefore retriggering the mutation.

[ilya-scale]

I think the authors would like to keep akv2k8s straightforward without additional functionality like restarting the pods. I have already done a bit of a research and there is this project that might help you with that: https://github.com/stakater/Reloader

If you do a secret update regularly then you can use Reloader to restart pods when it changes (I have never tried it myself though).

[hoangtoni]

in the non injection mode, secrets are being polled regularly, and then I can use this event to rester based on the updated secrets, but in injection mode, this does not seem to be the case.

[tspearconquest]

Unfortunately, I think it's not possible (or at least, not in-scope) for the env-injector.

The env-injector works a bit differently from the controller. It adds a binary to a volume in the pod and that binary runs at startup to pre-configure the environment with the secrets before starting the workload binary from the image entrypoint or the pod's command block.

Since it's running on startup, it's only retrieving the secret once, and then it runs the binary for the image's entrypoint. I believe it would be out of scope to have this binary polling keyvaults constantly, because each pod in a deployment would be independently polling the secrets in Keyvault and if you have 100 pods polling, even with a delay of a few minutes in between polls from each pod, it would still add up to a lot of additional unnecessary requests.

Conversely, the controller pod is more of a centralized service and only does the polling for itself. It's not running in each of your workload pods, unlike the env-injector binary which does.