<p>When managing entities semantically connected with Kubernetes, it makes sense to let Kubernetes manage them. Kubernetes manages <code>ServiceAccount</code> as a resource kind, but does not have similar kinds for human users or groups.</p>
<p>I'm wondering what is the design decision behind this. I know that <code>ServiceAccount</code> gets a token generated on creation that is used for further access, and for accessing a cluster as a human user, you need a config file with a public key signed with Kubernetes's CA.</p>
<p>It seems inconsistent, why not create similar resource kinds, say, <code>HumanAccount</code> or <code>Account</code> and supply a public key on creation (public key is kind of safe to store even in plain test in a yaml manifest), so that Kubernetes signs it and from that point on, accepts connections from the user?</p>
<p>I know that Certificate Signing Requests need to be approved by the administrator. Maybe that is the reason?</p>
<p>Any hints or insights appreciated!</p>

J. Tarasov
<p>There actually are <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-example" rel="nofollow noreferrer"><code>User</code></a> entities in RBAC, but kubernetes delegates the instantiation of those to either <a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs" rel="nofollow noreferrer">the <code>CN</code> field of mTLS authentication</a>, or <a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens" rel="nofollow noreferrer">the <code>sub</code> claim of OIDC</a>, or in a very customized situation <a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication/#authenticating-proxy" rel="nofollow noreferrer">one can provide that via HTTP headers</a></p>
