<p>I have a Kubernetes v1.14 on-prem cluster deployed using kubeadm and my kubernetes-admin user login has been compromised.</p>
<p>I want to revoke its certificate but the Kubernetes API server does not have a mechanism to lookup a CRL file. I already created another admin user using a new ClusterRoleBinding. The only solution I see is to de-authorize the user by removing it's associated ClusterRoleBinding: cluster-admin.</p>
<p>However, this ClusterRoleBinding's Subject is the &quot;system:masters&quot; group.
Even though I couldn't find any other system user that belongs to the &quot;system:masters&quot; group I'm afraid it will break some things if I delete it. I don't have any experience with this kind of situation.</p>
<p>I googled a lot but I couldn't find relevant information on this topic for open-source Kubernetes.</p>
<p>Is it safe to delete the &quot;cluster-admin&quot; ClusterRoleBinding?</p>
<pre><code>% openssl x509 -noout  -subject -in  &lt;(kubectl config view --raw  -o jsonpath='{.users[?(@.name == &quot;kubernetes-admin&quot;)].user.client-certificate-data}'  | base64 -d)
subject= /O=system:masters/CN=kubernetes-admin
% 

% kubectl describe clusterrolebindings.rbac.authorization.k8s.io cluster-admin 
Name:         cluster-admin
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
Role:
  Kind:  ClusterRole
  Name:  cluster-admin
Subjects:
  Kind   Name            Namespace
  ----   ----            ---------
  Group  system:masters  
% 
</code></pre>

Iulian M
<p>It's not safe to delete because <code>system:masters</code> is used as <code>Subject</code> in the client certificate used by Kubernetes API Server to interact with ETCD and kubelet.</p>
<p>To deal with the breach I would suggest below approach</p>
<ol>
<li>Take backup of ETCD</li>
<li>Regenerate all certificates</li>
<li>Restart all control plane components with newly generated certificates</li>
<li>If any issue use the ETCD backup to restore.</li>
</ol>
