5

kube-apiserver does not seem to provide an option to use a certification revocation list (CRL).

Is there a way to revoke a client certificate if it's lost or not used anymore?

11181
  • 292
  • 1
  • 4
  • 9
Yang
  • 759
  • 2
  • 9
  • 30

1 Answers1

4

As far as I know there isn't a way to directly revoke certificates via a CRL. However, what does work, and what we are currently using, is ABAC policies to identify users (set via the Common Name of a certificate), and whether they have access to a given resource on Kubernetes.

As an example, say you have a user called "random". You would generate a Client Certificate for them from your given Certificate Authority, with a Common Name of "random".

From there, you can have an ABAC policy file (a csv file with each line being a bit of JSON), with permissions set for user "random" that would provide them with a certain level of access to the Kubernetes API. You can have them have access to everything or certain namespaces or other API parameters. If you need to revoke permissions, you simply delete that user from the ABAC policy file. We've tested this, and it works well. The unfortunate thing, I will say, is you have to restart the Kubernetes API service for those changes to take effect, so there may be a few seconds of downtime for this change to occur. Obviously in a development environment this isn't a big deal, but on production you may need to schedule time for users to be added.

Hopefully in the future a simple "kube-apiserver reload" will allow for a re-read of that ABAC policy file.

One final thing to note: when using Client Certificates for ABAC authentication, you will need to set permissions for users INDIVIDUALLY. Unlike with auth tokens with ABAC, you cannot set Client Certificate users in "groups." Something that caused us headaches, so figured it was worth passing on. :)

Hope this helps!

Bryant Rockoff
  • 91
  • 3
  • Thanks for the solution, explanation, and advice. Currently, there's 4 set of keys and crts in my k8s cluster, for `apiserver`, `other master component`, `minions`, and the last, for the `kubectl`. At first, I'm wondering a way to solve the problems like crt-lost by one of them. Now it seems that the ABAC policiy is the best choice. A stupid question, which kinds of perms are appropriate for the kubectl, which can only create pods? – Yang May 20 '16 at 08:48
  • 1
    @Yang Loss of a certificate is definitely unfortunate in this case, but unfortunately I think the answer is to still fall back to removing that user from ABAC, and having a new user created. For example, if "random" lost their certificate, you would likely have to create a "random2" user with a new certificate for that user. I know that the community has been talking about adding CRL support to a later version of Kubernetes, but for now revoking a certificate isn't possible. One possible work around might be to have HAProxy/NGINX in front of Kube API checking for revoked certificates though. – Bryant Rockoff May 20 '16 at 17:18
  • 1
    Thanks for so many detailed implmentation, I'm very appreciated, especially the HAProxy/NGINX idea, it turns me on XD – Yang May 22 '16 at 12:54