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

@deads2k

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

@deads2k

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.

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)

@sbueringer

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.

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

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

/remove-lifecycle stale

@sbueringer

hi @sbueringer

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

/lifecycle frozen

It would be nice if we could have also resource-attribute based authorization in the filter, similar to: https://github.com/brancz/kube-rbac-proxy/tree/master/examples/resource-attributes

I believe this would allow more fine grained access than the non-resource URL approach

If I'm not mistaken filters.WithAuthenticationAndAuthorization is only used to protect the metrics endpoint.

Can you please give an example how that feature would improve the authentication/authorization of the metrics endpoint?

As far as I know, NonResourceURL's are not namespaced, so using a NRU means I give access to all /metrics endpoints int he cluster.

I was hoping that SubResources are namespacable, so we could do:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: metrics-reader
  namespace: application-namespace
rules:
- apiGroups: [""]
  resources: ["services/proxy"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: metrics-reader
  namespace: application-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: kube-rbac-proxy-client
subjects:
- kind: ServiceAccount
  name: metrics-fetcher
  namespace: default

I see. But this would allow to proxy to the service via the apiserver as well, right? (In this specific example to all services in the namespace)

Not just allow the /metrics endpoint

In the Role we could also set resourceNames, I don't know enough yet to answer if this would help limiting it to the service that exposes metrics.

I think it would. But it think it also allows access to all endpoints of the controller, not just metrics.

If we define a role like that it will also be used by the kube-apiserver, not just controller-runtime

Navigation Menu

Repository navigation

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

Enhancement Proposal: Authentication and Authorization Filters

Issues Identified

Proposed Changes

Impact

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Enhancement Proposal: Authentication and Authorization Filters

Issues Identified

Proposed Changes

Impact

Activity

camilamacedo86 commented on Apr 16, 2024

sbueringer commented on Apr 16, 2024

camilamacedo86 commented on Apr 25, 2024

sbueringer commented on Apr 25, 2024

k8s-triage-robot commented on Jul 24, 2024

camilamacedo86 commented on Jul 24, 2024

camilamacedo86 commented on Jul 24, 2024

sbueringer commented on Jul 24, 2024

mrueg commented on Sep 5, 2025

sbueringer commented on Sep 5, 2025

mrueg commented on Sep 8, 2025

sbueringer commented on Sep 8, 2025

mrueg commented on Sep 8, 2025

sbueringer commented on Sep 9, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions