Can they be friends --ignore-path and --allow-path?

[raptorsun]

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:

• If a path exists in allow list and ignore list: pass without authentication or authorization
• If a path exists in allow list but not in ignore list: pass with authentication and authorization
• If a path exists not in allow list but in ignore list: reject
• If a path exists neither in allow list nor in ignore list: reject

allow	ignore	decision
✅	✅	pass
✅	❌	check
❌	✅	reject
❌	❌	reject

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.

[ibihim]

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.

[simonpasquier]

@ibihim I vaguely remember from when kube-rbac-proxy was maintained by the monitoring team that the misconfiguration opportunity was the top concern.

[raptorsun]

Thank you for the feedback :) A risk of misconfiguration is always there. It seems to me the logic is simple:

1. if a path is allowed, go to next step, otherwise reject.
2. if a path is ignored, grant access, otherwise go to next step.
3. if a path is not ignored, check if the user is authorized to perform the verb on the resources.