kubebuilder: kube-rbac-proxy warn about deprecation and future breaking changes
What do you want to happen?
Since kube-rbac-proxy 0.14.1, it warn that some of the flags that kubebuilder scaffolds are deprecated :
Flag --logtostderr has been deprecated, will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components
W0807 14:58:44.167326 1 kube-rbac-proxy.go:152]
==== Deprecation Warning ======================
Insecure listen address will be removed.
Using --insecure-listen-address won't be possible!
The ability to run kube-rbac-proxy without TLS certificates will be removed.
Not using --tls-cert-file and --tls-private-key-file won't be possible!
For more information, please go to https://github.com/brancz/kube-rbac-proxy/issues/187
===============================================
I0807 14:58:44.167366 1 kube-rbac-proxy.go:272] Valid token audiences:
I0807 14:58:44.167421 1 kube-rbac-proxy.go:363] Generating self signed cert as no cert is provided
I0807 14:58:44.947435 1 kube-rbac-proxy.go:414] Starting TCP socket on 0.0.0.0:8443
I0807 14:58:44.947768 1 kube-rbac-proxy.go:421] Listening securely on 0.0.0.0:8443
We could easily remove the --logtostderr=true but I don’t know what would be the best solution for --tls-cert-file and --tls-private-key-file that will become mandatory.
I think we could use certificates from cert-manager, but it would make cert-manager required (maybe kube-rbac-proxy could be disabled by default to not force that requirement).
About this issue
- Original URL
- State: open
- Created a year ago
- Comments: 21 (18 by maintainers)
@Sajiyah-Salat You can work on this, once we know what flags need to be replaced. Since you are interested in code contributions, this would be a good issue to get started with. It would involve changing the flags in the templates which we have in these plugins and replace them with the new ones, after which you can generate the testdata and update the documentation.
TLS Certs
To maintain the exact same current behavior, you can generate a self-signed TLS certificate and provide it to the kube-rbac-proxy either within the container image or using an initContainer. It’s worth noting that there’s no need for a cert manager if you are fine to keep this behavior.
In the previous version of kube-rbac-proxy, this certificate was generated automatically. With the recent changes, we’ve shifted this responsibility to the user to ensure they are fully aware of the implications of using self-signed certificates.
I’ll look deeper into this topic. It might take me until next week.
Sig-Auth
The transition to sig-auth is progressing, but it will likely take a few more months to complete. Currently, we are in what we hope to be the second and final review phase, addressing the issues that have been raised.
As a result, our users can expect several changes in the near future. Our aim is to meet the requirements set by the sig-auth community while also catering to the needs of our users. Constructive feedback and active discussions would be greatly appreciated to help us achieve this balance.
For context, this process was initiated in April 2022.
@Sajiyah-Salat, I am one of the maintainers. @brancz is not involved in its development. He was kind enough to let us migrate the project to sig-auth.
You can reach out to me through kubernetes slack or kube-rbac-proxy issue.
Hi everyone,
Apologies for my delayed response. Summer vacations are in full swing here in Europe!
Regarding the logging flags: they’ve been deprecated by k8s upstream. As a result, they’re now deprecated in kube-rbac-proxy too, given our reliance on the k8s logging framework. We’re actively working on kube-rbac-proxy to make it a sig-auth owned project. This means incorporating more Kubernetes-native solutions and reducing our custom implementations.
I’ll delve into the upstream recommendations regarding these deprecations as our migration guide hasn’t addressed this yet, if time is short, you might consider exploring upstream resources directly in the interim.
From a security perspective, our decision to mandate TLS certificates comes in alignment with recommendations from the sig-auth reviewers, a stance we agree with. Running a server with self-signed certificates or without TLS may be a deliberate choice, but it doesn’t offer robust security. Given the security-critical nature of kube-rbac-proxy, it’s essential. To this end, we’ve addressed concerns raised over the use of self-signed certificates (see comment) and the insecure listen address (see comment).
If you have certain expectations about our project, it is NOW the time to file issues or comment on the “review issues” (like this issue) and discuss with us the future outcome of the project! The current development branch is called sig-auth-acceptance.
Due to the high volume of notifications on GitHub, I occasionally miss a few. For a more direct line of communication, feel free to reach out to me on the Kubernetes Slack. I check it at least once a week.
@Sajiyah-Salat,
We need the information from the project maintainers first to know how we should update those flags, see: https://github.com/brancz/kube-rbac-proxy/issues/196#issuecomment-1682004716
Please, feel free to reach out them to gathering this info.