You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: