Open raptorsun opened 10 months ago
We are currently very busy. I will try to discuss this with other maintainers and do my research, why it was made the way it is.
Most probably (beware, I am in assumption space): the combination of both logical features could introduce a complicated logic that could be misconfigured.
@ibihim I vaguely remember from when kube-rbac-proxy was maintained by the monitoring team that the misconfiguration opportunity was the top concern.
Thank you for the feedback :) A risk of misconfiguration is always there. It seems to me the logic is simple:
For now kube-rbac-proxy sees the 2 arguments
--ignore-path
and--allow-path
mutually exclusive. It is not so practical when we add liveness probe and readiness probes in Kubernetes. We may want the proxy to have a whitelist of the allowed pathes, while omitting the security check on certain paths such as/healthy
,/ready
. The current implementation of handler should work if we remove the option check. The decision logic looks like:What was the consideration behind why the 2 arguments are exclusive? If the new logic looks good, I can submit a PR with the proposed logic.