When managing entities semantically connected with Kubernetes, it makes sense to let Kubernetes manage them. Kubernetes manages ServiceAccount as a resource kind, but does not have similar kinds for human users or groups.
I'm wondering what is the design decision behind this. I know that ServiceAccount 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.
It seems inconsistent, why not create similar resource kinds, say, HumanAccount or Account 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?
I know that Certificate Signing Requests need to be approved by the administrator. Maybe that is the reason?
Any hints or insights appreciated!
There actually are User entities in RBAC, but kubernetes delegates the instantiation of those to either the CN field of mTLS authentication, or the sub claim of OIDC, or in a very customized situation one can provide that via HTTP headers