0

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!

J. Tarasov
  • 79
  • 1
  • 7

1 Answers1

1

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

mdaniel
  • 31,240
  • 5
  • 55
  • 58
  • Could you please expand your answer a bit - why is this design decision better than to allow the actual human user to transparently manage `User` manifest files? – J. Tarasov Mar 21 '22 at 19:50
  • I'm merely a consumer of k8s, not one of the original authors. Perhaps [the borg paper](https://research.google/pubs/pub43438/) can speak to your concerns – mdaniel Mar 22 '22 at 00:42