<p>How to secure <code>.kube/config</code>, so that even if our computer containing that file is compromised, our cluster is still secure? </p>

<p>e.g. It's not as straightforward as running <code>kubectl delete deployment</code> to delete our deployment (assuming we are the super admin in RBAC)</p>

<p>There are multiple ways of doing this, in case your machine gets compromised and you want to disable access to the cluster. Note that no solution will prevent a small window where a hacker can gain access and do some damage.</p>

<ul>
<li><p><a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication/#option-1-oidc-authenticator" rel="nofollow noreferrer">OIDC</a> authentication (OpenID Connect). Mitigation -> Disable the OIDC user on the OIDC provider and enable a lifetime for the session in the OIDC provider.</p></li>
<li><p><a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication" rel="nofollow noreferrer">Webhook</a> authentication. Mitigation -> disable client certs on the webhook service and the token lifetime is controlled by <code>--authentication-token-webhook-cache-ttl</code> which defaults to 2 minutes. In this case, the webhook service manages the tokens on your K8s cluster.</p></li>
<li><p><a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication/#authenticating-proxy" rel="nofollow noreferrer">Authenticating Proxy</a>. Mitigation -> disable users on the proxy.</p></li>
<li><p><a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins" rel="nofollow noreferrer">Client Go credential plugins</a>. Mitigation -> Disable user in the provider where the plugin is authenticating with. For example, the <a href="https://github.com/kubernetes-sigs/aws-iam-authenticator" rel="nofollow noreferrer">AWS IAM Authenticator</a> uses this, so you would delete or disable the IAM user on AWS.</p></li>
</ul>
