<p>When setting up our cluster we use kubespray which creates an <code>kubernetes-admin</code> user for me. I believe the code is <a href="https://github.com/kubernetes-sigs/kubespray/blob/044dcbaed023ace6e583e87cf160ef703181013a/roles/kubernetes/client/tasks/main.yml#L61" rel="nofollow noreferrer">here</a>.</p>

<p>For some reason now this <code>admin.conf</code> was leaked to all of our developers and I somehow need to revoke it.</p>

<p>What (I think) I understand:</p>

<p>In our kubernetes cluster we use <a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs" rel="nofollow noreferrer">x509</a> to authenticate our users. For our users we create a private key, then create a CSR with that key and sign it with the <code>client-ca-file</code> and key from our kubernetes installation. Like this:</p>

<pre><code>openssl genrsa -out $K8S_USER-key.pem 2048
openssl req -new -key $K8S_USER-key.pem -out $K8S_USER.csr -subj "/CN=$K8S_USER"
openssl x509 -req -in $K8S_USER.csr -CA $cert_dir/ca.pem -CAkey $cert_dir/ca-key.pem -set_serial $SERIAL -out $K8S_USER.pem -days $DAYS
</code></pre>

<p>I assume the same was done for the <code>kubernetes-admin</code> user and I assume that when I change the <code>client-ca-file</code> the <code>admin.conf</code> cannot be used anymore to use the kubernetes API.</p>

<p>Is this correct? That changing the <code>client-ca-file</code> will invalidate the <code>kubernetes-admin</code>?</p>

<p>I also assume I need to recreate all my service accounts as they also will be invalidated.</p>

<p>EDIT: So, I spent some time creating a new CA cert, then issuing new certs for my user and the kube-apiserver. Not sure a restart of the apiserver pods was enough though. My user is being rejected as <code>Unable to connect to the server: x509: issuer name does not match subject from issuing certificate</code>. This doesn't make too much sense to me though. When I connect to the apiserver pod via exec and inspect the apiserver cert it has the same issuer as my kubeconfig user cert.</p>

Moritz Schmitz v. Hülst
<p>Changing the <code>client-ca-file</code> will not invalidate the <code>kubernetes-admin</code>.</p>

<p>Referring to your case:</p>

<p>During creating a config file for generating a Certificate Signing Request you need to (CSR substitute the values marked with angle brackets (e.g. &lt;<strong>MASTER_IP</strong>>) with real values before saving this to a file (e.g. csr.conf). Value for <strong>MASTER_CLUSTER_IP</strong> is the service cluster IP for the API server. I assume that you are using cluster.local as the default DNS domain name.</p>

<p>Did you add the same parameters into the API server start parameters ?</p>

<p>Submit the CSR to the CA, just like you would with any CSR, but with the  <code>-selfsign</code>  option. This requires your CA directory structure to be prepared first, which you will have to do anyway if you want to set up your own CA. You can find an tutorial on that  <a href="https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html" rel="nofollow noreferrer">here</a>, for example. Submitting the request can be done as follows:</p>

<pre><code>ca -selfsign -keyfile dist/ca_key.pem -in ca_csr.pem -out dist/ca_cert.pem \
    -outdir root-ca/cert -config openssl/ca.cnf
</code></pre>

<p>A client node may refuse to recognize a self-signed CA certificate as valid. For a non-production deployment, or for a deployment that runs behind a company firewall, you can distribute a self-signed CA certificate to all clients and refresh the local list for valid certificates.</p>

<p>On each client, perform the following operations:</p>

<p><code>$ sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt</code></p>

<p><code>$ sudo update-ca-certificates</code></p>

<pre><code>Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....
done.
</code></pre>

<p>To make the leaked certificate useless is to replace the CA in the cluster. This would require a restart of the cluster, though. And it would require to re-issue all the certificates. You will have to recreate service account again.</p>

<p>To invalidate leaked tokens just delete the secret that corresponds to the user's token.
Remember of certificate expiration date you have added.</p>

<p>I hope it helps.</p>
