Enhancement of Authentication and Authorization Filters to Allow Custom Configurations and Stability Improvements

[camilamacedo86]

Enhancement Proposal: Authentication and Authorization Filters

Context: Following the implementation introduced in PR #2407, several issues regarding configurability and robustness were identified.

Issues Identified

• Configurability: Current settings such as cache TTL, timeouts, and anonymous access are hardcoded and cannot be adjusted.

• Certificate Authentication: The implementation disrupts normal certificate authentication processes. See that it shows like to have the same security issue identified by auth-sig which is a breaking change in kube-rbac-proxy over The ability to run kube-rbac-proxy without TLS certificates will be removed. shows be applied here. Users should provide their certificates and/or use solutions as cert-manager to manage them accordingly. It seems that is not a good practice to manage them. More info.

• Authorization Flexibility: Lack of support for alwaysAllow configurations for critical paths like /healthz and alwaysAllowGroups like system:masters.

• Network Resilience: Heavy dependency on stable connectivity to kube-apiserver can lead to metrics outages under network instability.

Proposed Changes

Enhance the filters by introducing configurations for previously hardcoded settings, and by allowing the injection of custom authorizers, similar to the approach in kube-rbac-proxy PR #43 and the see the PR: https://github.com/brancz/kube-rbac-proxy/pull/125/files

Impact

These changes would enhance the flexibility and reliability of the authentication and authorization processes in controller-runtime, aligning with the needs of robust Kubernetes deployments.

c/c @deads2k @sbueringer

[camilamacedo86]

HI @deads2k,

First of all, thank you very much for your assistance with this issue. Your expertise and deep knowledge are invaluable here, and I/and the community for sure greatly appreciate your involvement. Please feel free to add any additional insights or correct any points I might have missed or misunderstood.

[sbueringer]

Thx for opening this issue and the feedback. In general makes sense to improve the feature where necessary.

One question. Are the issues identified above from the kube-rbac-proxy audit or from an audit of the current implementation in controller-runtime? I'm not sure if they all apply in CR, as we only implement a subset of the kube-rbac-features and we only use them specifically for the metrics endpoint (e.g. /healthz is entirely out of scope today)

[camilamacedo86]

Hi @sbueringer,

IHMO all seems to apply because the feedback here in my understand is mainly keep the things configurable for properly inform the certs. Regards the Lack of support for alwaysAllow configurations for critical paths like /healthz and alwaysAllowGroups like system:masters. it seems that it could appear to work, but then cause metrics outages when networking to the kube-apiserver is flaky, which is one of the most important times to have metrics.

[sbueringer]

We don't even have a /healthz endpoint on the metrics server. But I get the point for metrics

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[camilamacedo86]

/remove-lifecycle stale

[camilamacedo86]

hi @sbueringer

Could we frozen this one?
Until someone be able to look on it and see if can address the enhancements?

[sbueringer]

/lifecycle frozen