Endpoint for health checks

[astorath]

What would you like to be added

1. Either serve both secure and insecure endpoints simultaneously
2. Or create a separate endpoint for health checks (on separate port)

Why is this needed

In order to protect Dashboard from unauthorised access I want to use a sidecar auth proxy. But with current options I have to either bind to 127.0.0.1 address (liveness probe can't be invoked in this case) or expose unauthorised endpoint on 0.0.0.0 (making it possible to bypass proxy).

Comments

Maybe there's another way to make port reachable for health checks only?

[floreks]

Kubernetes uses default API port as liveness probe. See https://github.com/kubernetes/dashboard/blob/master/aio/deploy/recommended.yaml#L209

I don't really understand your use case. Simple check if API is alive should be enough.

[astorath]

@floreks
Use case is as follows:

1. I have dashboard serving on http port without any authentication
2. Dashboard is bound to 127.0.0.1 (so that noone except for sidecar can connect)
3. Auth proxy (as a sidecar) performs auth and proxies user requests

This way I'm unable to use liveness probe:

• Dashboard do not accept connections from kube
• I have no option to enable second interface (with authentication) to support liveness probe
• Container is built from scratch - no option to run some exec curl there also

[floreks]

I think you are using some custom Dashboard deployment with your own sidecar container. If you choose not to expose Dashboard on 0.0.0.0 inside the pod then you have to make sure that your auth proxy will do necessary health checks as it is the only part that can access Dashboard. We don't want to run another API inside the container just for health checks.

Personally, I'd prefer to use network policies to allow only certain services access to Dashboard and expose it normally on 0.0.0.0.

[astorath]

I see, thanks for reply