-
Notifications
You must be signed in to change notification settings - Fork 39.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for managing revoked certs #18982
Comments
cc @liggitt |
Somewhat related, a better story around managing the lifecycle of TLS certs/keys in general. See https://github.com/kubernetes/kubernetes/issues/25379. |
+1 |
Issues go stale after 90d of inactivity. Prevent issues from auto-closing with an If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or |
+1 |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle rotten |
+1 |
Couple of examples I can think of immediately: |
A few thoughts.
Overall it sounds possible and even worthwhile, but also quite a lot of work. |
Would it be super hacky to have a flag on the api server that allows us to reject certs created BEFORE a certain date? That would be a way to quickly "revoke" all certs and start over when you have a feeling something went wrong. |
So that means any time I want to revoke a cert I have to revoke all of them and sign another bunch? Doesn't sound sane for me. |
My use case is indeed to revoke all certs and start over, without having to change the CA or revoke an intermediate certificate, since that is a lot more work, or not directly in people's control. |
Alternative to revoking certificates, one could implement Webhook access control in a higher priority than Node or RBAC which would enable immediate denial of access as well as denial of later certificate renewal. So in affect one can disable authorization but not authentication. Are there any security concerns with having a valid certificate but no privileges? |
The is a potential concern with valid certificate and no explicit grants in RBAC, which is that the user will still get any rights assigned to the Also there is one case (membership of |
@deads2k are you planning on a KEP related to this in the v1.23 release? |
v1.23 has come and past and is well on its way to retirement (targeted for End of Life:2023-02-28); does anyone have any plans to address this or propose a change that could be reviewed? |
As far as I can see, this can be done the same way etcd did it, by overriding the TLS Listener with one that checks against a revocation list. etcd's check: https://github.com/heyitsanthony/etcd/blob/41e26f741b26cc6f3faa39151ef74cfee3b6eace/pkg/transport/listener_tls.go#L62-L74 apiserver listener creation: https://github.com/kubernetes/apiserver/blob/10c70bebf96a41cfc1fb721c80a668d648cfeb0c/pkg/server/secure_serving.go#L250 Being able to pass a revocation list via an apiserver command-line option would already go a long way. |
Is there any chance to get even basic "Here is my CRL, use my CRL" included ? There appears to be half a dozen PR about exact same issue since 2016 all closed by indecisiveness. "Here is CRL file" and "here is a signal for API server to re-read CRL" at least allows to have a solution for problem existing. "Here is CRL file URL, just download it every X minutes or every crl.NextUpdate" would probably solve 99% of the problem as then we can just point it at whatever cert management solution the cluster is using |
This issue is open; pull requests are welcome. |
I sent a pull request, would love feedback: #122203 |
This isn't an issue that one can just make a PR to fix. It requires agreement on the path forward. The code itself was never the limiting factor. |
@enj do you know is there any documentation around previous discussions on options for looking at this that have been considered and decided against? I could see a challenge here for people coming at this fresh, that they won't have the perspective of the past 8 years to look back on. I can recall some discussions in SIG-Auth slack, but I'm not sure if there's other docs. |
This is an important feature, it’s too bad the maintainers aren’t interested in continuing the discussion so that we can actually get a PR landed for this issue after almost 10 years of waiting. |
Yeah, we were making bot to ship the certs out to our cluster user then realized "wait, if someone gets their device stolen or hacked into there is literally no way to revoke their certs". At this point using cert auth is worse than plain passwords. Hell, with just normal login it could be driven off corporate LDAP... |
Authenticating users via x509 certs is important, but the project seems to be missing a mechanism to revoke certs (without throwing the entire chain away and regenerating ALL certs for all users).
It would be great to be able to declare which certs are invalid, and have the kube-apiserver, kubelets, and all other cert-dependent services deny service for requests with the now-invalid cert.
https://en.wikipedia.org/wiki/OCSP_stapling appears to be one way to solve this.
FYI - this is the same idea as the issue with CoreOS: etcd-io/etcd#4034
The text was updated successfully, but these errors were encountered: