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

Open
stensonb opened this Issue Dec 21, 2015 · 19 comments

Comments

@stensonb
Contributor

stensonb commented Dec 21, 2015

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

@roberthbailey

This comment has been minimized.

Member

roberthbailey commented Jan 4, 2016

@stensonb That is a good observation.

/cc @ncdc @stephenR

@ncdc

This comment has been minimized.

Member

ncdc commented Jan 4, 2016

@jimmycuadra

This comment has been minimized.

Member

jimmycuadra commented May 26, 2016

Somewhat related, a better story around managing the lifecycle of TLS certs/keys in general. See #25379.

@rikatz

This comment has been minimized.

rikatz commented Apr 6, 2017

+1

1 similar comment
@tmegow

This comment has been minimized.

tmegow commented Sep 20, 2017

+1

@fejta-bot

This comment has been minimized.

fejta-bot commented Jan 6, 2018

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

@livelyRyan

This comment has been minimized.

livelyRyan commented Jan 20, 2018

+1

@fejta-bot

This comment has been minimized.

fejta-bot commented Feb 19, 2018

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

@kron4eg

This comment has been minimized.

kron4eg commented Feb 19, 2018

/remove-lifecycle rotten

@kaazoo

This comment has been minimized.

kaazoo commented May 8, 2018

+1

@mattmoyer

This comment has been minimized.

Member

mattmoyer commented Jul 2, 2018

As a start, we could add a new flag --client-ca-revocation-list-file=/path/to/crl.pem to point at a local CRL file. This would allow for manual revocation of certs which would meet many use cases and matches the solution that ended up in etcd (etcd-io/etcd#8124).

To revoke a certificate, a user would:

  1. Sign a CRL using the CA (or a dedicated CRL issuer).
  2. Get the CRL file onto the control plane node where the apiserver is running.
  3. Update the apiserver flag to point at the file and restart the apiserver process.

These steps could be automated in kubeadm and other tools.

This would cover, for example, the case where my installer generated a long-lived kubernetes-admin certificate that I want to replace with individual admin user identities.

@mikedanese

This comment has been minimized.

Member

mikedanese commented Jul 2, 2018

  • Who keeps track of serial numbers? The local signer doesn't. How do you reasonably construct CRLs with the kubeadm setup?
  • How long is the CRL valid for? What regenerates the CRL when it is close to expiring? Kubeadm is a main, not a daemon. Do we fail open or closed when CRLs become invalid?
  • What about kubelet handlers? How do we distribute CRLs to nodes?
@mikedanese

This comment has been minimized.

Member

mikedanese commented Jul 2, 2018

I would prefer OCSP stapling with a validation authority that had some plugable policy engine, e.g. OPA.

@simo5

This comment has been minimized.

Contributor

simo5 commented Jul 16, 2018

OCSP works great for serving certs, not so great for client certs though ...

@mikedanese

This comment has been minimized.

Member

mikedanese commented Jul 16, 2018

OCSP stapling, not OCSP. Why doesn't it work for client certs?

@simo5

This comment has been minimized.

Contributor

simo5 commented Jul 17, 2018

Smart cards are often not smart enough :-)
Besides that I am not a aware of an RFC that defines how to do OCSP stapling for client certs, both RFC6066 and RFC6961 only describe how to ask stapled responses from a server, I see no mechanism to ask for a stapled response from a client.

@simo5

This comment has been minimized.

Contributor

simo5 commented Jul 17, 2018

Unless you meant that servers will do OCSP stapling, while client certs are validated via OCSP, that is possible I guess, but error prone as it relies on the OCSP responder to be highly available again.

In general it seems like the best scenario is to use OCSP stapling for server certs and CRLs for client certs, as that keeps all the work on the server side, and can all be done ahead of time.

@droberin

This comment has been minimized.

droberin commented Sep 17, 2018

I think thi is a very important matter, yet it is almost a 3 years old issue at GitHub and it doesn't seem to be addressed/assign. I'm just curious about if it is not really that important or it is too big to take care of.
Thanks and sorry for the noise. :)

@joewilliams

This comment has been minimized.

joewilliams commented Nov 2, 2018

As with the other commenters I am also very interested in the status on this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment