Reload authenticator and authorizer on config file change

[nabokihms]

Use case

There is no way to change authorization settings on the fly. If you are running kube-rbac-proxy as a sidecar container for an application in Kubernetes, you need to restart the pod/container on every configuration file change. This is ok for lightweight applications, but for the one which consumes a lot of time on startup, this is unwanted behavior.

Proposed solution

Add a fsnotify-based background watcher to reload authorization and authentication handlers configuration on every change.

Alternatives

It is also possible to resolve the issue by adding an entry point for the container to watch the config file and reinit the proxy process on every file change, yet, honestly, I believe that it is best to write such a thing in go.

[ibihim]

As this using k8s as its framework, is there some solution in k8s that we could reuse? E.g. while updating the k8s dep, we added dynamic CA file loading by leveraging existing functionality at k8s (https://github.com/brancz/kube-rbac-proxy/blob/762a3c451b0c848d951c9453f4044cfc9b6e6a6a/pkg/authn/oidc.go#L39=).

[nabokihms]

Actually, no. AFAIC, there is nothing like this in Kubernetes. Authenticators are configured with flags mostly, not config files.

The idea of dynamic reloading came to my mind because I am working on the feature for Kubernetes which supposed to use dynamic reloading. Here is an example of authenticator wrapper https://github.com/flant/kubernetes/blob/486b642e2c5bb59fa14800159ac4e5fbf2bb5237/pkg/kubeapiserver/authenticator/config.go#L387

If it looks ok, I can open a PR.

[s-urbaniak]

@nabokihms directly watching configfile changes using fsnotify in k8s is very tricky due to the way how k8s mounts secrets/configmaps, see #45 (comment).

I am sceptical about a way to implement this in a properly working way. Additionally, in-process hot-reloading configmaps is something that needs a lot of state keeping and good testing to work properly. Unless we need to load configmaps very very often I'd say this probably is not worth it vs. staying with CLI parameters.

[ibihim]

I hope you're doing well. I noticed that the discussion about the dynamic configuration file change feature has become stale since it was last discussed last year. I understand that the implementation of this feature is more technically challenging than initially anticipated, as @s-urbaniak has shared his own experience.

Given the current state of the discussion and the technical complexity involved, I will be closing this issue for now. However, if you or anyone else has any new insights or ideas regarding the implementation of this feature in the future, please don't hesitate to reopen the issue or create a new one. We appreciate your contribution and understanding, and we're always open to revisiting valuable ideas when circumstances change.

Thank you for your interest in improving the project, and we hope to continue collaborating with you in the future.