Kubernetes does not facilitate certificate revocation

[blperez01]

Overview

In its current state, Kubernetes does not support certificate revocation. Therefore, users must regenerate the entire cert chain to remove a certificate from the system. This has been documented in open issue and addressed elsewhere here.

Attack Scenario

Eve successfully gains access to a node in Bob's Kubernetes cluster. Bob wants to revoke that node's certificate so that is not viewed as valid by the rest of the system, while also not having to incur the cost of re-generating the certificate tree. This is not possible, and Eve is able to maliciously control the node until Bob updates the entire cluster.

Recommendations

There are two options for supporting certificate revocation. One involves all nodes maintain a certificate revocation list (CRL) that must be checked whenever they are presented with a certificate.

Another option is using OCSP stapling. Here, the CLR is held by an OCSP server, which the owner of the cluster can use to revoke certificates. Each certificate holder periodically queries the OCSP server to get timestamped evidence that its certificate is still valid.

We believe using OCSP stapling, where the apiserver functions as the OCSP and the CLR is stored in etcd, is the best solution to this problem. This way, users can simply update the CLR and all nodes will periodically ask the apiserver for an updated timestamp proving their cert is still valid. Our approach incurs minimal overhead and uses tools readily available in the Go ecosystem.

[lojikil]

TOA-K8S-028