Based on the Kubernetes security reviews I’ve done, one of the most problematic areas for clusters is user authentication. Whilst Kubernetes provides a wide range of options, it lacks the “traditional” user database that you might expect to see with a multi-user networked system. Using external OIDC or webhook providers is often complex, so many clusters make use of the in-built authentication options which are :-
- Basic Authentication
- Token Authentication
- Certificate Authentication
The first two get marked down as they involve storing credentials in the clear on the Kubernetes master nodes and require an API server re-start to update (not the best).
That leaves quite a few operators of Kubernetes clusters making use of certificate authentication, however this also has some security problems. The lack of certificate revocation means that if one of your users loses their certificate (or leaves the organization) your only choice is to recreate the entire Certificate Authority (not a great experience)! Also as new client certificates can be created outside of the Kubernetes API, there’s no effective tracking of user accounts, so you could (for example) have multiple users with the same username, making it tricky to accurately audit user actions. Lastly the Kubernetes Controller Manager expects to have the Certificate Authority root online and accessible to be able to create new certificates, so it’s exposed to attackers who can get access to that directory on the Kubernetes API server. This can be problematic as once they’ve got the root key, attackers can issue their own certificates providing persistent access to the cluster (for the lifetime of that key).
It was with this backdrop that I was interested to see on a recent review an install making a creative use of service account tokens. Whilst these are intended for use by pod to communicate with the API server there’s nothing to stop you putting a service account token into your Kubeconfig files and using it for user authentication, giving you (effectively) a user database!
There are obvious advantages over certificate authentication in that you can revoke the secrets associated with a service account whenever you like and you can also provide individual tokens to individual users allowing for user auditing.
I’ll caveat this with a note of caution, which is that Kubernetes service accounts and tokens aren’t really designed to be a user database, and if your secrets are exposed then you risk attackers being able to impersonate your users! Ideally in production clusters you should make use of external authentication options, which allow for better control of user accounts…
