<p><code>kube-apiserver</code> does not seem to provide an option to use a certification revocation list (CRL).</p>

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

<p>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 <strong><a href="http://kubernetes.io/docs/admin/authorization/" rel="nofollow">ABAC policies</a></strong> to identify users (set via the Common Name of a certificate), and whether they have access to a given resource on Kubernetes.</p>

<p>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".</p>

<p>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 <strong>have to restart</strong> 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.</p>

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

<p>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. :)</p>

<p>Hope this helps!</p>
